I installed W7 Prof. today on my PC and tested several programs. Lazarus basically works though it cannot compile but this could be also to my lazarus installation. Nevertheless, some buttons are too small and text is clipped. Shall I create bug reports for this?

Can you show a screenshot. I have not noticed that. Maybe you ocasionally installed 0.9.26.x?

Best regards,
Paul Ishenin.

Lazarus cannot be recompiled in "Program Files" directory, because Windows 7 forbids writing and or other modifications of .exe,.bat files in this folder.

thanks,
dmitry

No, I suspect German localization, see e.g. attachment. -------------- next part --------------
A non-text attachment was scrubbed...
Name: Zwischenablage02.png
Type: image/png
Size: 25123 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20090815/422144ab/attachment-0001.png>

Florian Klaempfl wrote

No, I suspect German localization, see e.g. attachment.

Indeed. We are mostly testing with english version. There captions fits fine into designed width.

Best regards,
Paul Ishenin.

Hello Florian,

on my windows xp it looks the same.
So it's as you suspected something with german localization and not a problem in relation with windows 7.

Regards,

Sam

--- Florian Klaempfl schrieb am Sa, 15.8.2009:

Von: Florian Klaempfl
Betreff: Re: [Lazarus] Lazarus and Windows 7
An: "Lazarus mailing list"
Datum: Samstag, 15. August 2009, 9:52

No, I suspect German localization, see e.g. attachment.

-----Integrierter Anhang folgt-----

Paul Ishenin wrote

> Indeed. We are mostly testing with english version. There captions fits fine into designed width.

And the same issue appears for Afrikaans language as well. I've said it before and I'll say it again. All modern GUI toolkits support layout managers. These layout managers query each component and asks for the preferred size and minimum size. Minimum size from all components will dictate the minimum size of the dialog or form, so no clipping ever occurs.

VCL is very outdated in this regard. LCL is slightly better with more advanced alignment and sizing options, but a full layout manager support is still missing. Even with the English language I often see captions or groupboxes or labels being clipped, because those dialogs might have been designed under Windows, but because GTK2 components are normally larger, things don't fit.

Regards,
- Graeme -

________________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

The problem is deeper.

Except for the outer window (and you can check the wiki, there is an article that explains why autosizing is limted for the outer window), except for that all the buttons etc are autosizing.

But even if the window was autosizing, that would make the problem worse.

I have some boxes that run a VGA resolution (either 800*600 or even 640*400) and the dialogs just fit, some even are to big, and it's painfull to impossible to get to the ok button (know where it is, and count tabs untill you believe it has focus).

So make the window/dialog bigger and thinks will be even harder.

Martin

If you are using Gnome you can press the left Alt key and then click anywhere on a window. You can now drag that window around (no need to click on the title bar).

So make the window/dialog bigger and thinks will be even harder.

All programs usually define a minimum screen resolution. I can remember when last I saw an IDE that said min. resolution is 640x480. All developer tools (IDE's) usually require larger screen resolutions than standard desktop applications. This is known, but maybe Lazarus should make it clear that minimum resolution is 1024x768. I can't remember when last I saw anybody run there desktop , the dialogs need to be redesigned to fit 640x480 or a more sane 800x600. But I still feel, layout manager are a must with todays applications that get translated to many languages. Hopefully my port of MiG Layout Manager will be sufficiently abstracted, so that it can easily be applied to LCL as well - currently I'm porting MiG to fpGUI Toolkit.

Regards,
- Graeme -

________________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

The results only look nice when the forms have according flexible layouts. In many cases it's not sufficient to only increase the size of a single control, and to move following controls to the right. Such a change should be reflected in *all* controls of the same "table". This requires that all related controls are grouped properly, by placing them into (kind of) VBox/HBox containers, or by anchoring.

In this context I really dislike the Lazarus anchored layout, because it does not enforce a systematic "regular" layout. When controls are added to a VBox/HBox, they are automatically alligned according to their container. Anchors instead have to be set individually for every control, with good chances for omissions, and without any chance of a quick (visual) verification of the existing dependencies.

VCL is very outdated in this regard.

I dare to disagree. Using the appropriate containers (panels, probably invisible) and anchors allows for the construction of very "elastic" layouts, which can be verified by changing the form's size at design time.

LCL is slightly better with more advanced alignment and sizing options, but a full layout manager support is still missing.

The LCL anchors *allow* for more flexibility, but their use is a mess, both in visual design (anchor editor) and in code (see anchor docking). IMO they are nothing but a misfeature, violating the rule "keep it simple" :-(

Even with the English language I often see captions or groupboxes or labels being clipped, because those dialogs might have been designed under Windows, but because GTK2 components are normally larger, things don't fit.

For international development it were desireable to change the language in the GUI at design time, in order to verify a constructed.

We should consider a major update of the layout handling in one of the next versions, taking into account docking managers. As already mentioned, a docking manager is more a layout manager, the issues with dragging and docking are almost handled in the drag manager. The only difference between an dock tree and other tree-style layout managers is the distribution of the available or required space to the layout zones or containers.

DoDi

Only when the restrictions are not properly considered.

I have some boxes that run a VGA resolution (either 800*600 or even 640*400) and the dialogs just fit, some even are to big, and it's painfull to impossible to get to the ok button (know where it is, and count tabs untill you believe it has focus).

Right. I found it impossible to configure Windows itself, with settings dialogs hiding essential settings and buttoms below the screen, on the system of a disabled person with low graphics resolution on a big screen.

So make the window/dialog bigger and thinks will be even harder.

When the minimum size of the contents exceed the screen size, even a dialog should have automatic scroll bars. The exit etc. buttons should reside in the non-scolling part of the dialog, everthing else in the scrollable part.

DoDi

I don't think that a completetly dynamic layouted dialog is possible. IMO buttons should have a reasonable width for all languages, if a buttons needs a deeper explanation, use a tooltip.

En/na Florian Klaempfl ha escrit:

I don't think that a completetly dynamic layouted dialog is possible. IMO buttons should have a reasonable width for all languages, if a buttons needs a deeper explanation, use a tooltip.

You could also shrink/enlarge the font size to fit the available space. Labels already have an OptimalFill property, this could be extended to buttons and other controls.

Bye