[GUI] Dynamic sizing.

[Wolfgang Thaller]

Axel Simon wrote:

> [...] I think Wolfgang's list is quite ambitious:
>
>> So we could have several different types of containers:
>>
>> HBoxes, VBoxes for simple dynamic layout
>> GridBoxes for complex dynamic layout
>> FixedPlacementBox for crazy people, for strange situations and for
>> implementing dynamic layout schemes on top of it.
>
> What do you mean when you say HBoxes and VBoxes? In Gtk even HBoxes and
> VBoxes are not as simple as putting things next to each other. You 
> still
> have to specify which and how widgets grow and shrink when the 
> surrounding
> container changes size.

I put them in the list because David Sankel stated that he is
"used to using HBox's and VBox's", and I don't care whether we put them 
in or not. They probably aren't much effort to implement on top of a 
"grid" geometry manager. We could leave them out and put them in at the 
last moment if we really want them.

> Actually the only way a grid layout is more
> powerful seems to be the ability to put things into a matrix (e.g. a
> tic-tac-toe playfield with 9 buttons with their borders all aligned).

No, that's not the only way, because widgets can span more than one row 
and/or column.

I don't think you can achieve the following layout with H/VBoxes:

AAB
DEB
DCC

(where AA is just _one_ widget; There are 5 widgets here, A,B,C,D and 
E).


> I don't really know about grid layouts, Gtk has one, but I think every
> cell is of the same size, so it's not nearly as universial (and
> complicated) as Motiv's.

No, Gtk's "table" does everything I want for a grid. The cells aren't 
necessarily
the same size (unless you set the grid to be "homogeneous").

>  As such, Gtk's grid is more like Window's dialog
> units, albeit not fixed in its cell size. (I looked up dialog units: 
> they
> are horizontally 1/4 of the average character's width and vertically 
> 1/8
> of the font size.)

I remember being able to use pixels for placing controls (widgets) in 
normal windows. If we correctly query the "recommended" sizes for 
widgets, we can safely ignore dialog units and do our calculations in 
pixels.

> It is possible to change the font and size of a specific label in a
> specific dialog box in Gtk by means of a resource file. If this 
> feature is
> combined with fixed layout (or one dynamic layout created in Haskell) 
> it
> will destroy Gtk's native look. Maybe I am missing something, but I 
> don't
> see a way to start with a fixed layout specification and then but 
> dynamic
> layout on top of it.

On MacOS, there is of course no other way (because the toolkit itself 
provides only fixed layout), which is why fixed layout _has to be 
there_ (as a base for implementing other things).
Same for Fltk, which is used in the sample implementation that was 
posted here.
However, I don't see why there should be a problem with implementing 
layout managers on top of fixed layout. The layout manager would just 
have to query the (platform- and font-specific) minimum, preferred and 
maximum sizes of the widgets. If the font settings are changed, the 
layout manager has to be notified, and it has to redo the layout.

For Gtk, we might as well map the Grid layout manager to the native 
table widget (as long as we don't want to add any features that Gtk's 
table doesn't have). This would save us some coding effort (but it 
wouldn't get us a more native look).

> Maybe we should be
> content with one portable way of creating window contents on the fly 
> (i.e.
> dynamically).

Well, the only way of creating window contents on the fly that exists 
on all platforms is _fixed placement_ (yes, I know that it is 
impossible to use this portably with hard-coded coordinates). I need 
fixed placement before I can implement anything else for Mac OS.

Cheers,

Wolfgang