On Wed, 7 Apr 2010, Mattias Gaertner wrote:
On Tue, 6 Apr 2010 15:33:54 +0200 (CEST)
Michael Van Canneyt <[email protected]> wrote:
[...]
How can a designer tool find out what layout a control uses?
Why does it need to know ?
If it needs to know what layout a control uses, the designer is flawed by
design:
There may be layouters that the designer has no knowledge of, and
hence if such a layouter is dropped on the form, the designer will
be lost.
I can't follow you here.
For example: I dropped several layouters on my form. Now I want to know
what layouter my Panel1 uses. But I can't find out because that would be
flawed by design?
Nono, I misunderstood your question. I thought that you wanted to know
whether the designer can find out if the panel uses THBoxLayout or
TTableLayout or whatever.
Maybe you can give some more details how you want to setup the
layouts in the designer.
See below.
[...]
How would you do that?
For example you want a group of TEdits to position/resize according to
a policy, so you set for all your edits a layouter.
I don't see what is to store in the TEdits ?
The 'policy' is a property of the layouter, not of the TEdits.
The reference to the layouter should be stored in the TEdits.
For example: the layouter of Edit1 is Layout1. It does not matter what
specific type Layout1 is.
Aha. Agreed.
I see that for easy use in the IDE, the reference to the layouter
should be stored in the control itself, so the user can quickly
find out what the layouter is.
[...]
No problem when using layouters: just create/adapt a new layouter class.
The simplicity and clarity is the following:
Layouter: Layouter manages everything. Each layouter has a few simple
properties that determine it's (and only it's) behaviour, and no more.
Now the TControl/TWinControl classes have a set of properties that is the
union of all properties of a large set of layouters (because it must mimic
the behaviour of all these layouters put together):
* AutoSize
* Anchors
* Align
* Constraints
* BorderSpacing
* ChildSizing
Only Align, Anchors and ChildSizing.Layout are layouts. The rest are
details that apply to all layouts. See the layouters of gtk.
In my view, this is not correct. Borderspacing, Constraints and AutoSize
are also properties used in layouting. I see no reason why a control would
have these properties (assuming we were to move all layouting to a separate
component).
In difference, each layouter would have only the properties that it
needs to implement it's behaviour. That is simple to understand.
Yes, but not as simple to use.
For example I know many students using the java layouter. They are
seldom happy with the result and often use a fixed layout and program
anchors.
Maybe the Java layouter is simply no good ?
Layouters are easy to program and easy to explain but awkward to create
nice designs.
If one of the layouters provides the behaviour we have now, I see no problem ?
Currently, the layouting is simply a mess, with added ad-hoc properties
and no clear rules that determine which property has precedence over
other properties.
See here:
http://wiki.lazarus.freepascal.org/Autosize_/_Layout
I find the concept of a layouter with 1 or 2 properties more clear
than all these properties thrown together.
Of course.
But in the end the important part is a simple GUI to use the layouts.
This, I agree on, and that is why we are discussing it so long :-)
Michael.
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
