Re: Gtk containers

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

On Sun, 18 Jul 1999, Sergio A. Kessler wrote:

> Nils Philippsen wrote:
> > No and yes. No, it's a property of the child and yes, the parent is
> > responsible for it.
> 
> sorry, but this is confusing...  an object has a property he can't
> control..

I woudn't describe this exactly as confusing. Since the child can't know
about the nature of how it can be positioned (fixed position, horizontal
or vertical ordering, some kind of a table, or anything someone may come
up with in the future) you simply can't store this information in the
child itself. You may have the idea to store this in some kind of a layout
manager or constraints thing, which is associted to the widget then, but
here we'd have constraints again :-(

It simply isn't feasible to store this info in a child. It's perfectly
feasible to store it in the container, since it does exactly know how the
children are to be layouted and what information makes sense with its
layout. E.g. a table widget has some two-dimensional (x,y) layout
information, a horizontal stores the position number of the child, a (yet
to come) border layout would store a gravity (north, east, south,west,
center, ...), etc. (ok I simplified this a bit).

> 
> > Like the General who commands where each unit shall
> > be.
> 
> what if the button doesn't want to be in a military unit ?
> there should be a place for freedom and free speech, 
> don't you believe?

I'm of the opinion that the programmer should have total control. But you
might grow a beard and found the Free Widget Foundation (FWF) :-)
(Sorry, RMS, no pun intended).

> > > >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.
> 
> well, this is another issue, I agree with you that with the current 
> aproach is more easy to create an interface by coding it by hand,
> but when you come with an interface builder, this complicate all..

With some kind of rearranging functions, this would be a non-issue.

> And I still have to find a good reason to not use a interface
> builder and code the interface by hand.

Last time I checked, interface builders couldn't cope with symbolic
values, e.g. a #define BORDER_SIZE 5 which could later be changed to 10.
Last time I checked colors and fonts were hardcoded inside the widgets
generated. But who am I to say that -- I code everything manually.

> 
> For example, take glade, put a hbox and then put button A to the
> left and then put a button B next to A, now you realize that btn
> B must be to the left of A. What you do ?
> With the current approach you have to delete both buttons and 
> start again (an horrible solution, let me say).

I agree with you that there must be the possibility to rearrange the
widgets in a container after they have been placed, and there
is:

--8<--/usr/include/gtk/gtkbox.h--
void       gtk_box_reorder_child       (GtkBox       *box,
                                        GtkWidget    *child,
                                        gint          position);
--8<-----------------------------

If Glade doesn't use this, it's Glade's problem -- I think you're free to
submit code to make it possible.

Finding the current position of a child is a no-brainer (maybe someone
can verify this and put it as a convenience function in gtkbox.c.
Convenience functions are yummy):

--8<-----------------------------
gint gtk_box_child_position (GtkBox *box, GtkWidget *child)
{
  GList *node;
  gint pos = 0;

  g_return_val_if_fail (box != NULL, -1);
  g_return_val_if_fail (GTK_IS_BOX (box), -1);
  g_return_val_if_fail (child != NULL, -1);
  g_return_val_if_fail (GTK_IS_CHILD (child), -1);

  for (node = g_list_first (children);
       node;
       node = g_list_next (node)) {
    GtkBoxChild *bchild = node->data;

    if (bchild->widget == child)
      return pos;

    pos++;
  }

  /* box is not the parent of child */
  return -1;
}
--8<-----------------------------

> With the property aproach I'm pushing, you just change two properties,
> isn't this simpler and more object-oriented-alike ?

Tha fact is that the child needn't know about its position. It can exist
perfectly without this knowledge (module the position on the screen, but
it gets told about it by the container in which it lives).

> I'm not saying to remove all current containers, only to add a JAC 
> (Just Another Container)(and maybe add GTK_RESIZE_NONE as a new 
> GtkResizeMode enum), but this one realy does *nothing* more 
> than hold the childrens, this childrens behave like they want inside
> the new container (one aligned, another fixed, etc).

Anf again I ask you were you want to store the children's positions/layout
information. Since it can (and will) be many different forms you simply
can't store it inside the widget.

> btw, I've heard that Tim Janik is doing an interface builder, is this
> true ?

I think I recall him doing one a long time ago, but it was superseded by
glade.

Bye,
Nils
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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