[Lazarus] Docking manager implementation

[Mattias Gaertner]

On Sun, 25 Jan 2009 00:19:14 +0200
Graeme Geldenhuys <graemeg.lists at gmail.com> wrote:

> On Sat, Jan 24, 2009 at 1:40 PM, Michael Van Canneyt
> <michael at freepascal.org> wrote:
> >
> > What's the big fuss all about ?
> 
> * the layout manager can do complex layout without nesting panels or
> other layout managers.

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.


> * 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.

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.

 
> 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.

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