Now I've got an own docking manager work, with D7. The implementation addresses the zone management and sizes, which are flawed in LDockTree (TLazDockTree, TLazDockZone).

The question is, how to proceed. Should I provide a new Lazarus unit, as an alternative for LDockTree, or should I update LDockTree and Controls and submit an patch? Be warned: my implementation changes fields, methods and properties of TDockZone, and also parts of TDockTree, so that other docking managers will have to be updated. That's why a new unit might be a better introduction for this changed base classes.

Still missing is the anchoring, as done in TLazDockTree, and the handling of messages and the display of the zone headers. It would be nice to have a true TDockHeader component, derived from a TCustomSplitter, so that only one additional component has to be managed (anchored...), instead of separate zone header and splitter components. Is this feasable?

The header part and message processing can be taken from LDockTree, but I'd suggest more changes to the anchoring of the docked components. IMO the anchors are affected only by InsertControl and RemoveControl, not by other changes like a resize of the docking site, so that the required changes to the anchors could be reduced to just the insertion and removal (docking and undocking) of a control.

For required size adjustments, after un/docking or a resize of the dock site, multiple algorithms are applicable. In the simplest case the space is distributed equally onto the docked controls. But the space also can be distributed proportionally, according to the current or undocked size of the controls. It might be a good idea to leave the choice to the user, by means of an OnResize handler, or by a dedicated virtual method. I'd like similar adjustments/selections for layout managers in general, so that a coder can use the simple Delphi or the complicated Lazarus anchors, or any other (Java like...) layout managers. Then a docking manager can be reduced to just the handling of un/docking controls, whereas the layout of the dock site could be delegated to an appropriate layout manager.

I'm just asking for opinions from insiders, which are more familiar with the current model and capabilities of the LCL and IDE, before I proceed with the integration of the refurbished docking manager.

DoDi

Lets start with a new unit. Then we will see if we need our own LazDockTree or we will replace it with yours.

Nice idea. Really dock header can be a splitter and a header at one moment. If we use 2 controls they will be anyway placed one by one.

ok

Yes, options are possible. But I have no idea how Java or any others layout manager works. Maybe Mattias will help you here.

Best regards,
Paul Ishenin.

Lets start with a new unit. Then we will see if we need our own LazDockTree or we will replace it with yours.

ok

Nice idea. Really dock header can be a splitter and a header at one moment. If we use 2 controls they will be anyway placed one by one.

At the moment I cannot provide such a component, perhaps somebody else can?

Yes, options are possible. But I have no idea how Java or any others layout manager works. Maybe Mattias will help you here.

The question is: what interface will be required? The TDockManager class was given by Delphi, for layout managers we may have to look at the widgetsets...

DoDi

Why at the widgetsets?

Mattias

Java has layout managers, and the "modern" widgetsets also have layout managers, which might be usable even with Lazarus.

DoDi

How?
The LCL needs an widgetset independent layout manager.

Mattias

Hans-Peter Diettrich wrote

Java has layout managers, and the "modern" widgetsets also have layout managers, which might be usable even with Lazarus.

I am working on a port of the Java MiG Layout Manager. Initially it is for fpGUI alone, but MiG Layout was designed to support other toolkits as well. So I will stick to that design and try and support both fpGUI and LCL in the ported MiG Layout. I will post a note here as soon as I have something to show.

Google MiG Layout and try the Swing demo. It's a truly amazing layout manager!

Regards,
- Graeme -

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

Mattias Gaertner wrote

How? The LCL needs an widgetset independent layout manager.

Exactly, and I am already working on that. I'm attempting to port MiG Layout to Free Pascal and include support for both fpGUI and LCL.

Regards,
- Graeme -

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

Lets start with a new unit. Then we will see if we need our own LazDockTree or we will replace it with yours.

The codename is EasyDockSite, and I could make it compile and run with Lazarus :-)

There exist some fundamental differences between the Delphi and Lazarus declaration and runtime environment of an docking manager - see comments in the EasyDockSite unit. The first version has problems with resize and undocking, where the display is not refreshed; I'll have to look deeper into these issues.

The exe is very fat (13 MB), compared with the Delphi version (0.5 MB). Is this normal? A matter of debug info?

DoDi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: EasyLDock.7z
Type: application/octet-stream
Size: 15497 bytes
Desc: not available
Url : http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20090122/ffacf759/attachment-0001.obj

Right. But since we have to define an interface, we could look at existing layout manager models. Perhaps we can use some of the widgetset managers without much extra coding? Also Lazarus ports of such managers will be easier, when existing managers will not deserve much modifications.

DoDi

Google MiG Layout and try the Swing demo. It's a truly amazing layout manager!

Looks as I'm too stupid to make the demo work :-(
I'm not experienced with installing Java...

DoDi

I doubt that. At least for the gtk I don't see how that should work. For example how should a TControl work with that?

Also Lazarus ports of such managers will be easier, when existing managers will not deserve much modifications.

Mattias

Here comes V0.2, with docking, undocking, re-docking and resize working as expected :-)

The implementation of headers and splitters can be copied from LDockTree
- I'm waiting for the implementation of a combined splitter/header control.

Some strange behaviour of Lazarus/LCL IMO should be considered design flaws, to be fixed (see comments in EasyDockSite).

Please check the attached demo project for undetected bugs.

DoDi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EasyLDock.zip
Type: application/zip
Size: 16998 bytes
Desc: not available
Url : http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20090122/d3380972/attachment-0001.zip

Okay, if TControls are unknown to the widgetsets, we have to implement our own layout managers.

DoDi

Hans-Peter Diettrich wrote

Looks as I'm too stupid to make the demo work :-( I'm not experienced with installing Java...

I have the Java SE Runtime Environment (build 1.6.0_03-b05) installed. Using Ubuntu Linux, I installed it via apt-get.

I then downloaded the swingdemoapp.jar file and ran it via the command line.

$> java -jar swingdemoapp.jar

:-)

Regards,
- Graeme -

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

An error appeare building last SVN (18393) into the IDE on Windows XP Pro (service pack 2) with FPC 2.2.2

The error is:
C:\lazarus\examples\edittest.pp(83,12) Error: identifier idents no member "GutterPartVisibleByClass"
C:\lazarus\examples\edittest.pp(111) Fatal: There were 1 errors compiling module, stopping

Note: no error if I use MAKE CLEAN ALL into DOS prompt

David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sw_dept.vcf
Type: text/x-vcard
Size: 257 bytes
Desc: not available
Url : http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20090123/55574d1a/attachment-0001.vcf

I've had build 1.5.0_17-b04 first, now 1.6.0_11-b03, but this makes no difference (execpt for a longer error log).

I then downloaded the swingdemoapp.jar file and ran it via the command line.

I got a swingdemoapp.jnlp, and a swtdemoappbase.jar.

The .jnlp is a "invalid or corrup jarfile", the .jar throws an exception NoClassDefFoundError :-(

DoDi

Hans-Peter Diettrich wrote

> I then downloaded the swingdemoapp.jar file and ran it via the command line. I got a swingdemoapp.jnlp, and a swtdemoappbase.jar.

Here is a direct link to the .jar file.

http://www.miglayout.com/swingdemoapp.jar

I just tried this on a different machine. Downloaded the latest .jar file as show above and launched the demo using:
java -jar swingdemoapp.jar

Regards,
- Graeme -

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

The exe is very fat (13 MB), compared with the Delphi version (0.5 MB). Is this normal? A matter of debug info?

I believe so. The default compiler settings include debug info, which usually yields an exe of about that size.

Set it to not include the debug info, and select the strip option (is that still working?).

2009/1/22 Hans-Peter Diettrich

I played around with this demo; Looked at the code.

What's the big fuss all about ?

The same things you see there can be easily done in Lazarus ? Whether I write - rather obscure - layouting code for the start as displayed there, or I write a 'OnResize' event handler and do some minor adjustments myself (the improved anchoring of lazarus gets you a long way), the fact remains that I must take care of the layouting by writing code manually ?

If you had a nice property editor, maybe then it would be better. Even so, creating a usable property editor for such a complicated matter is not going to be easy, I think.

Michael.

For me, all I really want that's not supported via Lazarus at the moment is the % of parent statement...

So
child1.top := 0%  (1%?)
child1.bottom := 33%
child2.top := 34%;
child2.bottom := 100%;

Otherwise, I'm pretty happy at the moment.

Regards,
-Reenen

On Sat, Jan 24, 2009 at 1:40 PM, Michael Van Canneyt <

These kind of calculations are easy in the OnResize event of the parent. A OnResize is also much more flexible, because you can keep some childs fixed and others proportional etc. Also the in between child space is preferred to be fixed e.g. 6 pixels or so. I think there are many variations on the 'proportional theme' to be liked that they cannot be put into a 'choose pull-down' property editor.

Micha

Or (as I recently discovered) you can set the align to alCustom and handle all your custon stuff in OnCustomAlignPosition / OnCustomAlignInsertBefore

Marc

Yes they can be, but *I* am not able to get them to work without them flickering 10x a second during resizing.

Do I put it in the parent's OnResize? Or the child's?

Also, for each of my panels I must write a new "onresize" code.

BUT the anchoring system can be modified to do this...

Select (for each anchor) 2 points, and a %. So:

Panel1 contains 2 listboxes...

Listbox1 Topanchor = Panel1.Top, Panel1.Height, 1% Listbox1.BottomAnchor = Panel1.Top, Panel1.Height, 33%

This is probably not the most eliquent, but shouldbe able to work?

Here is a direct link to the .jar file. http://www.miglayout.com/swingdemoapp.jar

Thanks, this one worked off the shelf :-)

DoDi

I got the same error, both on win xp and ubuntu 8.04. fpc 2.2.2 lazarus svn. Lazarus rebuilds properly if example are excluded from rebuilding. andrea

Guadagnini David ha scritto:

Yes they can be, but *I* am not able to get them to work without them flickering 10x a second during resizing.

This can be reduced with DisableAlign, EnableAlign.

Do I put it in the parent's OnResize? Or the child's?

I added some hints to the help description.

For example this line

  Label1.Width:=GroupBox1.ClientWidth;

must be put into the GroupBox1.OnResize.
Using any other OnResize for the above line will create cases where your label is not resized properly.

So, normally you need to set several every OnResize event of every parent that has special childs.

Also, for each of my panels I must write a new "onresize" code.

Yes, unless the childs can be setup with the normal TControl properties.

procedure ... Panel1Resize(...);
begin
  with ListBox1 do
    SetBounds(Left,Parent.ClientWidth div 100,
              Width,Parent.ClientWidth div 3);
end;

Mattias

The same things you see there can be easily done in Lazarus ?

Maybe somehow, dunno how easily ;-)

Most widgetsets have no concept of persistence, so everything must be set up in code.

If you had a nice property editor, maybe then it would be better. Even so, creating a usable property editor for such a complicated matter is not going to be easy, I think.

You address an sensitive topic. Now I realize what I don't like with the Lazarus anchor editor - it lacks a visualization of the designed dependencies, for a quick design, overview and verification of the overall layout. It violates my primary design rule: keep it simple!

Of course people have very different meanings about "useful" layout managers, in so far the most powerful layout manager may address the needs of everybody, even if every single developer only uses his favorite subset of the offered features. Nonetheless I fear that the outcome will be "write only", with little chances that somebody will be able to update any existing complex layout, perhaps except for it's inventor :-(

I for my part would prefer a strictly structured (layered, nested) layout, where frames can be used to visualize the nesting in design mode. Just as is demonstrated in the last item of the MiG layout manager.

When structured code is the accepted "best" coding style nowadays, because it's clear, understandable, extensible, and can be verified easily - why should spaghetti style be better suited for the design of a GUI?

BTW, the layout demo doesn't include any graphics. I wonder what will be required to include graphics, in a way that produces a predictable look and behaviour in environments with different screen resolutions and text sizes. It's hard enough, with only text, to test a layout on such different environments, so that it's not acceptable to me when a GUI looks fine at the designer's site only, with an unknown appearance on other machines.

DoDi

For me, all I really want that's not supported via Lazarus at the moment is the % of parent statement...

Are you talking about the form designer or docking manager?

A percentage based scaling is unsafe, because the sum may exceed 100%. It also will be hard to add any new element, requiring a recalculation of the previous percentages. What about the required adjustment of percentages in other rows or columns of the same layout? Also required is kind of an alClient value, for an element that should fill the remaining space.

That's why I'd favor a proportional scaling, as used in the dock site resize procedure. When the undocked sizes are used for scaling, nothing new has to be added to the existing design tools and data structures. It might be possible to take into account the control alignment (including alClient, see above), but this may require a distinct DockAlign property with every control.

For general layout managers it may be necessary to add a reference size for proportional scaling, dunno whether this is related to the newer Delphi ExplicitWidth etc. properties. It may be possible to mix absolute and relative sizes, when relative sizes are given as negative values.

DoDi

Should be fixed in SVN now. Sorry the Example wasn't updated before.

I wasn't specifically talking about docking manager, though the subjects are probably linked to an extent.

I am liking what you're doing with the dock manager by the way. It looks exciting.

"proportional scaling" - could you point me to examples etc?

Sounds like what I want to do...

Regards,
-Reenen

Michael Van Canneyt wrote

What's the big fuss all about ?

* the layout manager can do complex layout without nesting panels or other layout managers.
* Auto resize of components so translation text NEVER gets clipped. I have fixed things like this a 100 times in Lazarus, until the next person edits something in that form, or somebody changes something in the widgetset code. With LCL as used in Lazarus IDE, such things are always broken.
* No over lapping components (a constant issue in Lazarus IDE)
* Automatic button order based on the platform - built into the layout manager. No extra components required like the ButtonPanel in LCL.
* Automatic border and spacing widths based on the platform - built into the layout manager. eg: Mac OS-X has bigger form borders that Windows, GTK etc..
* Totally screen resolution independent. Max / Min and Preferred components sizes are taken into account.
* DPI independent.
* Unit sizes can be specificed in %, inches, cm, pixels, mm, etc..
* The original Java MiG Layout is toolkit independent. It's very simple to add new toolkit support. I hope to make the port the same.
* Built-in debug mode, to help with layout design and debugging.

.....the list goes on! ;-)

The syntax may look strange in the beginning, but it's quite easy to learn. Also you would probably only use a handy full of syntax commands to complete most layouts. The rest of the supported syntax is for more advanced designs and features, but not required to be able to use the layout manager.

Regards,
- Graeme -

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

2009/1/24 Reenen Laurie :

For me, all I really want that's not supported via Lazarus at the moment is the % of parent statement... Otherwise, I'm pretty happy at the moment.

So how do you handle DPI changes or runtime language translation in LCL? Not all LCL components have autosize, preferred / min / max sizes. LCL still has many features missing compared to MiG Layout.

Regards,
- Graeme -

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

And this is exactly where something like MiG Layout makes the stask much easier. So no in LCL we have the following location where layout code could be placed.

Form.Create
Form.OnResize
OnCustomAlignPosition
OnCustomAlignInsertBefore
<each components>.OnResize
....etc....

MiGLayout does all the above in one location - easy to find, edit and maintain.

Regards,
- Graeme -

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

I'm sure it does, but I simply doubt it will result in me less fidgeting.

You confirm my doubts: the 'handy full' can probably be achieved with lazarus easily as well ;-)

But hey, by all means, surprise me !! I'll be glad to be proven wrong.

Anyway, we had this discussion once. It'll be interesting to see you come up with a non-text version in terms of properties, collections and whatnot. And then of course a nice intuitive property editor.

With this I mean: a drawn representation of all components in the form, (maybe scaled) click on each control, and specify it's properties. Now wouldn't that be nice ? :-)

If you make the properties, I'll make the editor :)

Michael.

Panel = group of controls
You create the groups in MiG via the properties. So, yes, you create nested groups, but you can not access the groups itself. This has pros and cons.
MiG layout is a flow/table/rule based layout manager - like gtk. You avoid fixed positions and define everything relative. This avoids overlapping and gives good adaption to various themes and fonts. Contrary to the nesting rules of gtk, MiG uses hundreds of properties and flags. The learning curve is therefore quite steep. MiG solved the complex setup with parameters in text list format. So it is great for source code (means: less typing), but it is hard to create a good graphical designer, let alone an intuitive one. I hope you have some good ideas.

1. Can you give the bug report number for the broken layouts, where the translation overlap in the IDE?
2. You can overlap in MiG too.

* No over lapping components (a constant issue in Lazarus IDE)

bug report?

* Automatic button order based on the platform - built into the layout manager. No extra components required like the ButtonPanel in LCL.

... instead it needs some extra properties for that. It is semi automatic.

* Automatic border and spacing widths based on the platform - built into the layout manager. eg: Mac OS-X has bigger form borders that Windows, GTK etc..

Yes, that's an advantage of rule based layout managers.

* Totally screen resolution independent. Max / Min and Preferred components sizes are taken into account.

Well. Which layout manager does not take Min/Max/Preferred into account? ;)

* DPI independent. * Unit sizes can be specificed in %, inches, cm, pixels, mm, etc.. * The original Java MiG Layout is toolkit independent. It's very simple to add new toolkit support. I hope to make the port the same.

Great.

* Built-in debug mode, to help with layout design and debugging.

Do you mean the red and green borders?
That does not help much. IMHO a good designer should visualize the dependencies. Like the guide lines in Lazarus but MiG's hundreds of flags need much more.

.....the list goes on! ;-)

Yes, the hundreds of flags and properties is a problem.

It is like the many linux daemon config files. You can setup a server with a few lines, but you never get a good gui. The more the gui supports, the less intuitive it becomes.

Mattias

If a control does not provide good Min, Max and preferred size, then
MiG layout will fail too - it can only be as good as its input.

It's true that the current LCL properties are only pixel based and have no properties for cm, inches, percentages, .... That's a feature of MiG. OTOH I never saw an example where this was extensively required. If you only need that at a few places you could use OnResize.

Mattias

Let's stay realistic.
There will always be cases where you need methods/events to override. For example:
Changes to the content of a control. For example the columns of a TStringGrid.

Mattias

I am liking what you're doing with the dock manager by the way. It looks exciting.

Thanks for the feedback :-)

"proportional scaling" - could you point me to examples etc?

The docking manager example demonstrates this. When you set the alignment of the dock site to alClient, it will follow all resizes of the form.

DoDi

Yes. See attached image. I have a few more screenshots I can send as well.

* See the captions of "Major version", "Minor Version" and "Build"
* See the "Other info" group box.

Like I said, there are a few more. Over the years I am submitted patches, just to see the issue appear somewhere else again. So now I gave up on this issue.

2. You can overlap in MiG too.

Only if you explicitly specify (x,y) position of components! Via standard usage, it will never occur.

... instead it needs some extra properties for that. It is semi automatic.

All you need to specify is if the button is one of the common types: Help, OK, Cancel etc... MiG then automatically detects the platform and arranges the buttons correctly.

And a good layout manager would make a "visual designer" obsolete. Visual designers have lots of issues or write crappy code, which a programmer could have done much better manually. Issues with Delphi and Lazarus visual designer: Global variable for the form; All components are published and publicly available etc... The list goes on. All not great OO design principals. Most Java visual designers are even worse!

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ProjectOptions_VersionInfo.png
Type: image/png
Size: 3422 bytes
Desc: not available
Url : http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20090125/097ee241/attachment.png

Percentages is often used in designing a layout. View some websites HTML source or CSS files. So why can't that be applied to "real" GUI programming as well.

Regards,
- Graeme -

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

I'm talking about the space components take up, not the internals of a specific component. eg: A panel with three buttons in a horizontal line. You might be able to AutoSize the buttons if there captions change. But the Panel will not auto size to fit the new "larger" buttons. The buttons will simply get clipped.

Make no mistake, LCL has much better anchoring and alignment than Delphi - but there are still many areas of concern.

Regards,
- Graeme -

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

Why not?
It is done on most IDE dialogs.

Make no mistake, LCL has much better anchoring and alignment than Delphi - but there are still many areas of concern.

True.

Mattias

Percentages is often used in designing a layout. View some websites HTML source or CSS files. So why can't that be applied to "real" GUI programming as well.

Percentages are easy to implement, but hard to use. Too bad if a layout system doesn't offer some better method.

Imagine a table, where all the column widths (in percents) have to be recalculated whenever a column is inserted or removed. Who should do that calculation, the user or the system?

With proportional sizing one can have e.g. columns of width=1, double wide columns of width=2, and margins of width=0.1, and the layout manager will do the rest :-)

DoDi

Yes! Can we do that?