Re: Gtk containers

[Nils Philippsen <nils wombat dialup fht-esslingen de>]

On Fri, 16 Jul 1999, Sergio A. Kessler wrote:

> >Because gtk pretty much seems to have a top down concept when it comes to
> >layout positions. With dimensions it's the exact opposite.
> 
> don't you see a "little" inconsistency here ... ?

Not really. The containers are responsible for what's in them, thus they
decide where to place each individual child. As in gtk, each child is a
container by itself, it's responsible for its contents, asks its children
(if it has) about their dimensions, then calculates its dimensions, and
tells its parent about them. I can't see an inconsistency here. It's a
simple hierarchy: Each parent is responsible for itself and its children,
it gives orders to its children (their position) and receives reports from
them (how much space they need). Yes, it sound a bit like the military.

> are you saying me that the position (x, y) of the button doesn't
> belong to the button ?

No and yes. No, it's a property of the child and yes, the parent is
responsible for it. Like the General who commands where each unit shall
be. 

> if this is the case, I think this broke all my years behind
> OOP...
> 
> >> I'm begining to understand why there are dozens of containers
> >> in Gtk ...
> >
> >The other way would be to program constraints *vomit*.
> 
> I don't understand you on this

Constraints are a (rather awkward) way to program a GUI where the children
are responsible for their position. Since not the parent (which has the
complete overview) is responsible, you have to tell each child, how much
distance shall be between it and its neighbor, that its half the size of
the neighbor, and so on. This leads to confusion if you give both children
"commands" that disagree, e.g. A shall be half the size of B and B shall
be the same size as A. I had some very frustrating experiences with
constraints and will avoid them if possible from now on.

> >> What about having a minimalist container, then for example
> >> add a button inside and do gtk_widget_set_uposition() or
> >> gtk_widget_set_alignment( my_btn, my_gtk_alignment) and
> >> then the button positiones or align itself inside the parent ??
> >
> >For example: How would you make a horizontal/vertical box or a table with
> >all cells of an equal size (since size and position would be properties of
> >the widgets)? Should they talk to each other? What if they disagree ("I
> >want to be the same size as you -- No. I want to be half in width and
> >double in height as you.")?
> 
> this can be worked out with positions, alignment and anchors properties
> on the button and talking with the parent.

And you'd have bleeding fingers afterwards. It's much shorter to program
this in a top-down manner.

> >> (btw, this is how the libraries I work behave, from Borland wich
> >> have a long experience on GUI libraries)
> >
> >As you cann easily see at the price tag and the source code you may read,
> >this is NOT Borland.
> 
> what's bad on taking good ideas from outside ?

People can be of different opinion on what's good. Taking this idea now
into gtk, would -- be it good or not -- break almost the whole layout
concept of gtk and would and piss off a lot of people who developed
programs with gtk, as they now had to rewrite almost the whole program
(with regards to layout, that is).

> (btw, I can read /all/ the source code from the Visual Component Library)

But you cannot write it, otherwise you would violate copyright laws.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Nils Philippsen                  @college: nils@fht-esslingen.de
Vogelsangstrasse 115             @home:    nils@wombat.dialup.fht-esslingen.de
D 70197 Stuttgart                phone:    +49-711-6599405
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offence.                          -- Edsger W. Dijkstra