Hi,

Just updated Lazarus to r35276 on Linux GTK2 / Fpc 2.6.0.

The IDE's main window (the one with the component palette) now has lost some pixels in its height (appr. 15), and half of the component pallette has become invisible.
The main IDE window isn't resizable anymore, only minimize and close buttons are available.

Anyone else seen this?
Can it be fixed?
(I tried Tools -> Options -> Environment -> Windows, but that will not let me set position/height for main IDE window).

FWIW:
Linux 2.6.13-15-default #1 GNU/Linux
gtk2-2.8.3-4

Bart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Lazarus-Main-Window.png
Type: image/png
Size: 30155 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120209/5487db60/attachment-0001.png>

Citiram Bart :

Yes, by creating patch which will dynamically count needed height. btw. it looks ok here Lazarus 0.9.31 r35277 FPC 2.6.1 i386-linux-gtk 2 (gtk2-2.24 on fedora 16).
It could be gtk2 theme related ...

zeljko

Op 9 februari 2012 21:55 heeft het volgende geschreven:

Maybe we should revert the change made by Juha, until there is a proper fix?

Vincent

Vincent Snijders wrote

Op 9 februari 2012 21:55 heeft het volgende

geschreven:

@Bart, can you try to change it from 85 to 100 ? 100 should be better then 110 (I think it was value before change).

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120210/02218a79/attachment.html>

@Bart, can you try to change it from 85 to 100 ? 100 should be better then 110 (I think it was value before change).

The MainBar should not have a Height restriction at all, when used as a dock site.

It also should allow for a configurable width, currently the user settings (Options|Windows) are ignored.

DoDi

2012/2/9, Bart :

Bart, see : http://bugs.freepascal.org/view.php?id=1020 Can you please attach a screenshot there so that me and others can see the effect.
I tested on Windows, Linux GTK2 and QT and there was always some "safety margin".
The main window should still be resizable just as before. I only changed the Height constraint.

Juha

The main window should still be resizable just as before.

You cannot make it bigger, right. I wrote it too quickly. If someone creates a patch for calculating the height dynamically, I would be happy to apply it.

Juha

2012/2/10, Juha Manninen :

"calculating the height dynamically" (+1)

2012/2/10 Juha Manninen

Juha Manninen wrote

Bart, see : http://bugs.freepascal.org/view.php?id=1020 Can you please attach a screenshot there so that me and others can see the effect.

There is a screenshot aatached to my original post here.

The main window should still be resizable just as before. I only changed the Height constraint.

And that seems to be the problem exactly.

My original report wasn't totally accurate, I can resize width in all directions, but I cannot resize height > 85 pixels (I can make it smaller).

(B.t.w. the options menu for this entry is called "Main menu", which to me suggest a TMainMeu on the main IDE window)

Bart

zeljko wrote

@Bart, can you try to change it from 85 to 100 ? 100 should be better then 110

I tried that via Options menu (and by manually altering environmentoptions.xml), and it does not work.

If I should change it in the Lazarus code, where is this defined?

Bart

Hi all,

sorry, but this issue was brought up by me.

I tried to solve http://bugs.freepascal.org/view.php?id=1020 which is almost 7 years old. (reported in 2005)

And I must say, on windows plattform the? Lazarus IDE MainBar really looks uggly.

The MainBar Height was set to 110. On windows 75pixel looks perfect. So we had 35pixels of just gray colored nothing.

So we need a flexibel, OS-dependent patch for this issue. Otherwise it might look uggly for another 7 years ;-)

I tried yesterday to make a new dynamic patch, but I was not able to determ the height of the mainmenu. Will continue tonight.

Regards,

Sam

See TMainIDE.Create in Main.pp for the default values. The exact behaviour and size depends on many factors, mainly hidden somewhere in the FormCreator and more, see IDEWindowIntf.pas. I already started to patch this unit, in order to make an IDEDockMaster work, but could not yet make it work as it should :-(

DoDi

2012/2/10, Bart :

There is a screenshot aatached to my original post here.

Right, somehow I missed it. Now the problem is clear. You have a bigger font and its effect is doubled because both main menu and the component palette tabs have text.

You could change the value back to 110 (or something else) at main.pp, line 1404.
Now it seems we will get a proper fix and I don't want to change the value in trunk yet.

Juha

Have you tried with LCLIntf.GetSystemMetrics(SM_CYMENUSIZE) ? I guess it'll return something under win32, but it's not implemented for others yet (I guess it shouldn't be too hard to implement it)

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120211/1ac1ef11/attachment.html>

Sorry, it should be LCLIntf.GetSystemMetrics(SM_CYMENU)

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120211/52f892fb/attachment-0001.html>

Isn't this a reason for a redesign of (at least) this form, using those fine Lazarus layout features?

And reason for a revision of the IDEIntf, to cure the observed problems once-for-ever?

IMO it's not a good argument for using Lazarus, when just the IDE demonstrates layout problems. Every user will notice such problems immediately, and may trash Lazarus consequently, without any closer look at the rest :-(

DoDi

Have you tried with LCLIntf.GetSystemMetrics(SM_CYMENUSIZE) ? I guess it'll return something under win32, but it's not implemented for others yet (I guess it shouldn't be too hard to implement it)

Ah, that nasty difference between outer (form bounds) and inner (client area) sizes, which was never solved for non-Windows platforms :-(

It's hard to believe that there exist reasonable widgetsets *without* a feature to map a fixed client size into the according window size.

DoDi

for non-Windows ? Are you saying that under lclwin32 Form.Width Form.ClientWidth ?

It's hard to believe that there exist reasonable widgetsets *without* a feature to map a fixed client size into the according window size.

Believe or not under X11 such results are unpredictible while created window isn't visible (mapped) yet. Event freedesktop standards give warnings about it
- since WM handles frame extents (borders, title bar) and it's up to wm when we will get it - so you are NEVER 100% sure that eg. QWidget_frameGeometry() includes decorations from WM (title and borders) ...

zeljko

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120211/f6223a18/attachment.html>

@Samuel, I've implemented SM_CYMENU for qt and gtk2 today (under win32 it already works), so you can finish your implementation and attach patch somewhere .... LCLIntf.GetSystemMetrics(SM_CYMENU) returns complete menubar height.

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120211/484af47b/attachment-0001.html>

Quick test on Win32 using 0.9.31 (around two weeks old) using event handlers for OnShow and OnResize: No, it's not the case.

Regards,
Sven

I dont see why all this fuzz.

In my copy of Lazarus (win32) the IDE remember the position of the window.

So, if the user does not like the default height just resize to his desire and next time open will show the "correct" height

Luiz

Hi Luiz,

you are right. Almost everything can be configured/customized in lazarus IDE.

But this is really important, because "first impressions count". Recently I convinced a colleage to install lazarus. On the first start, the Lazarus IDE really looks uggly and not so professional. (on windows plattform)

Sam

________________________________
Von: Luiz Americo Pereira Camara
An:
Gesendet: 16:33 Samstag, 11.Februar 2012
Betreff: Re: [Lazarus] IDE Main Window: height is too small and cannot resize (Linux/GTK2)

I dont see why all this fuzz.

In my copy of Lazarus (win32) the IDE remember the position of the window.

So, if the user does not like the default height just resize to his desire and next time open will show the "correct" height

Luiz

This is one of the biggest and most annoying differences between Lazarus and Delphi: Delphi handles the difference between Width/Height and ClientWidth/ClientHeight properly, while Lazarus makes no such distinction :-(

DoDi

Such change is planned for post 1.0 because it can easy postpone 1.0 for one year. Feel free to provide patch which will fix that in next 2-3 weeks so we can test before branching.

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120211/73b358ff/attachment.html>

Okay, send me an Mac so that I can start my research ASAP :-)

DoDi

If you fix it for all except for Mac then I'll fix Mac :)

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120211/3eb87369/attachment.html>

Luiz Americo Pereira Camara wrote

I dont see why all this fuzz. In my copy of Lazarus (win32) the IDE remember the position of the window. So, if the user does not like the default height just resize to his desire and next time open will show the "correct" height

It's not fuzz.
As stated before: the height of the IDE main windows is limited to 85 pixels. This is too small for my OS/WM/Theme on Linux.
If I would use a larger fontsize on Windows the 85 pixels would probably also bee too small.
Currently, it is impossible to get a proper window layout for this window.

You cannot rely on the value of (client)height being correct on GTK2 until after the form is shown (after OnShow).
I have wrestled with that may times when sizing forms by code and trying to make their size just big enough.

I have some code lying aroud that tries to compensate for the clientheight/height issue, which on my system gives a rough approximation.
That code however relies on Application.QueueAsyncCall(), which isn't implemented for all widgetsets IIRC.

Bart

dude, damn! you're battiin' 1000! keep it up!

you remind me of myself in other venues before i finally gave it up because of those unable to see "this side" of the view...

i'm sorry but "what??" i'm still a very noob to the RAD/Lazarus environment but i do not catch your problem comment above and understand what it is saying or pointing to... i'm running the latest laz/fpc svn stuff that i can...

As we all have.

If I understand the issue correctly, GUI programming was originally defined in terms of a predefined form size containing vector-drawn components: there might be issues with jaggies or imprecise positioning due to numeric rounding but in general content could be scaled to fit its container.

The problem is that an increasing amount of the UI is now defined by bitmaps- icons, photos or dynamic content- and the programming model is not good at positioning this and then shrink-fitting a frame around it, taking into account any widgetset-defined "furniture".

I also observed that e.g. the initial (undocked) messages window is higher than the screen, and most of it hangs below the screen.

When I recently minimized a designer form, it lost its original size permanently, other minimized windows are restored as zero-size windows, after the IDE has been minimized and restored.

The latter effects may be related to the dockable IDE extensions, but then I miss a description of that interface, from which I could determine how to fix possible flaws in my code.

DoDi

Bart, I've fixed that (added dynamic count of height) in r35309. Can you test ?

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120213/b0baee98/attachment.html>

Scalable layouts can be handled in different ways. E.g. Java prefers layout managers, MS prefers twips (bound to text resolution), Delphi choose pixel coordinates and overall scaling of forms, and Lazarus AnchorDocking and ChildSizing goes even more different routes.

The problem in the subject is a different one: there exists *no* way to specify the extent of the *content* (client) part of a window, and let the window manager adjust the *overall* size of the window accordingly, depending on border and caption styles. No problem for Delphi, but the LCL doesn't support that yet :-(

DoDi

2012/2/11 zeljko :

Such change is planned for post 1.0 because it can easy postpone 1.0 for one year. Feel free to provide patch which will fix that in next 2-3 weeks so we can test before branching.

I think we should consider simply leaving how it is and add a new property for the outter size. Changing Form.Width / Height might be a heavy compatibility break for Lazarus users. And if we use it as the main source of stored size for a window, then it likely be unreliable across platforms and cause issues when you design a form in Windows and opens in Linux.

Hans-Peter Diettrich wrote

Okay, send me an Mac so that I can start my research ASAP :-)

As for implementing it, we already have in LCLIntf:

function GetWindowRect(Handle : hwnd; var Rect : TRect): Integer;
{$IFDEF IF_BASE_MEMBER}virtual;{$ENDIF}
function GetWindowSize(Handle : hwnd; var Width, Height: integer):
boolean; {$IFDEF IF_BASE_MEMBER}virtual;{$ENDIF}
function SetWindowPos(hWnd: HWND; hWndInsertAfter: HWND;
       X, Y, cx, cy: Integer; uFlags: UINT): Boolean;  {$IFDEF
IF_BASE_MEMBER}virtual;{$ENDIF}

So you should start trying to figure out how to implement all of those properly in Gtk2, Qt and pure X11. I just commited improved docs for GetWindowRect and GetWindowSize

You are completely wrong. Lazarus supports setting the client area of the window and this is the only way exposed in TCustomForm.Width, Height, ClientWidth, ClientHeight.

Setting/Getting the total window area including decoration is currently exposed only in LCLIntf currently.

Oops, you're right.

Setting/Getting the total window area including decoration is currently exposed only in LCLIntf currently.

Then I wonder why it doesn't work properly with the IDE main window. A fixed maximal client height is nonsense, because it disallows the user to enlarge the window when needed. According to the documenation, AutoSize would be the right choice instead.

DoDi

Hans-Peter Diettrich hat am 13. Februar 2012 um
14:47 geschrieben:

The main bar has some specials: It is the first form (the splash window does not count), it has the main menu, it has a pagecontrol with some registered items, it's height is small, it has a special behavior on maximized and all this has a slightly different meaning when docked. All this must work on a platform before autosize can be used.

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120213/2526cc23/attachment.html>

zeljko wrote

Bart, I've fixed that (added dynamic count of height) in r35309. Can you

Saw an entry in bugtracker about that.
Will test when I'm on Linux again.

Bart

zeljko wrote

Bart, I've fixed that (added dynamic count of height) in r35309. Can you test

Tested Lazarus 0.9.31 r35365 FPC 2.6.0 i386-linux-gtk 2. I can resize the manin window to my liking again.
It does, however not seem to initialize to the correct height, probably because it reads it's value form the environmentoptions.xml file.

How can I make it calculate it's own height to see if that works?

Bart

How can I make it calculate it's own height to see if that works?

Maximize the main window.

Juha

2012/2/14, Bart :

Juha Manninen wrote

> How can I make it calculate it's own height to see if that works? Maximize the main window.

In my first report I stated that only Minimize and Close border-icons are available.
So, there is no maximize option...

Bart

Resize it with mouse. It cannot be maximized since Constraints.MaxHeight = calculated max height.

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120214/34c363f8/attachment.html>

zeljko wrote

Resize it with mouse. It cannot be maximized since Constraints.MaxHeight = calculated max height.

I should have pulled it just a few more pixels down, and I would have noticed that.
The new maxHeight constraint looks OK on my GTK2 system.

Thanks evreyone.

Bart

Glad to hear that :)

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120214/27c483a5/attachment.html>