[Lazarus] Autosize behaviour

[Michael Van Canneyt]

On Wed, 7 Apr 2010, Mattias Gaertner wrote:

> On Tue, 6 Apr 2010 15:33:54 +0200 (CEST)
> Michael Van Canneyt <michael at freepascal.org> 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.