Re: Gtk containers

["Sergio A. Kessler" <ser perio unlp edu ar>]

Nils Philippsen wrote:
> 
> 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 :-(

I think you have problems with constraints because you do the 
interfaces by hand (ie. you do not want to /code/ the constraints)
I'm rigth ?
For me the interfaces doesn't need to be coded by hand and must stay
far away from the real code.
In an _ideal_ case, the interface should be changeable without impacting
the real code.

> 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).

and then you have thousands of containers and not a general solution ...

> > > 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).

maybe a GtkFreeBox ?  :)

> > 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.

it's not that easy ...

> > 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

this is a flaw on the toolkit then, not of the interface builder.

> generated. But who am I to say that -- I code everything manually.

you have the time and inclination, not everyone like to do this,
I just want to write the interesting code, not spend two days 
doing the interface.

> > 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<-----------------------------

where do you reorder ? to the left ? to the rigth ? to the top ?
How Glade can read my mind and use gtk_box_pack_end instead of
gtk_box_pack_start in some cases ?

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

there are two ways of doing an interface builder:

- brute-force (special cases everywhere): an aproach that Glade is using
  to solve some deficiences in Gtk. I think is no surprise for everyone
  that Gtk wasn't being made with interface builders in mind.
  You support widgets on a case by case basis in this approach, every 
  new widget can have potential problems.

- generalized (querying the RTTI and so on): this is the aproach that
  Gle is trying to follow, and is the rigth thing to do, all widgets
  are simply widgets, no need for "if widget is an HBox then ...".
  Of course, this need support of the underlaying toolkit, something
  that Gtk doesn't bring completely (and is not only the containers 
  problem).
  With this approach every new widget is supported automatically.

If I submit the kind of code you say, it would be a _horrible_ hack.

> 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):

you mean gtk_box_get_child_position, rigth ?  ;)

> --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).

ok, just let suppose for a second that the information reside in the
children, isn't this simpler and more object-oriented-alike ?
(working with an interface builder, that's it)

> > 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.

you are saying where !  you say children's positions/layout !
so the natural thing is to put it in the children.
(I've said the natural thing, not the easy thing)

> Since it can (and will) be many different forms you simply
> can't store it inside the widget.

why not ?  (if others libraries have done it ..)

> > 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.

That's was Gubi, I've found that Tim is working now in Gle and it is in 
Gnome cvs, and guess what ?  It have problems with containers !
Check it out.

Sergio
-- 
  |    Sergio A. Kessler  http://sak.org.ar
-O_O-  You can have it Soon, Cheap, and Working; choose *two*.