Re: [gtk-list] Re: Suggestion for Perl/GTk packing

[Tim Janik <timj gtk org>]

On Sun, 19 Apr 1998, Dov Grobgeld wrote:

> In your message, Tim Janik, from 1998-04-19, you wrote:
> > On Sun, 19 Apr 1998, Andreas Kostyrka wrote:
> > 
> > > On Sun, 19 Apr 1998 dov@Orbotech.Co.IL wrote:
> > > > Reading through the tutorial I really had a feeling that it is a shame
> > > > that the underlying C-Code wasn't build around varargs and named 
> > > > parameters. There are lots of strange functions like
> > > If you want this, go for Tcl/Tk. Gtk was ALSO designed to be lowlevel and
> > > fast. With your proposal, every function call would start by comparing
> > > strings. Not a very fast approach.
> > 
> > not really, one simple hash lookup would do the trick ;)
> 
> Either that, or even faster, using enums or #define's as keys. I think
> that Tk (not tcl!) has a lot of very good design that could/can be
> incorporated in gtk . It also has lots of interface problems that gtk
> has the potential to solve. There is nothing wrong with borrowing good
> design ideas.

using strings compared to enums has the advantage, that the varargs list
can be extended by derived containers.

> > actually "dov" (is that a name?) is kind of right with his idea/proposal.
>            ^Yep :-)
> 	   
> > the reason for not having a generic mechanism to specify linkage upon
> > adding a child to a container is that this hasn't been an issue when
> > gtk+ was initially designed. e.g. the object::any-argument mechanism
> > has been added to gtk+ quite latly as well (actually, this was done when
> > the issue of a GUI builder was raised) and isn't still consequently
> > implemented (though, i'm working on it as soon as i have a free second).
> 
> I'm don't understand the details of the above paragraph, but so much
> is clear to me that a varargs mechanism has the advantage of being
> open for future extension. 

that's what i'm proposing below.

> > > > gtk_table_attach() vs. gtk_table_attach_with_defaults(),
> > > > gtk_box_pack_start() vs. gtk_box_pack_end() that would be unnecessary
> > > > had this be done. Not to speak about the consequences of adding a new
> > > > parameter in the future to the latter pack functions... E.g. an 
> > > > -anchor parameter. There is no room for it without changing all the 
> > > > existing code. But this critique obviously doesn't belong to the 
> > > Nope, just add a new method, and emulate the older ones internally with
> > > the new one. No code change.
> > 
> > yep, it shouldn't be too hard to add two new members/signals to the
> > GtkContainer class,
> 
> Without named args you still suffer the need to remember what
> .....,TRUE, FALSE, 3, 0) stands for.

well, your "varargs" is what i meant by the below "named arguments", i.e.
a string identifiying a value of a certain type, similar to the
gtk_widget_set(,...,NULL) mechanism.

> > 1. to query the named arguments featured at linkage time
> >    (as well as free child slots e.g. GtkBin has 0 or 1, whereas a GtkBox
> >     always has infinite slots) and
> 
> What are slots? Where can I read about them?

well "slot" here actually means a "free place to put a new child in".
so a GtkBin or GtkButton can only have one child at maximum (none if
there already is one), a GtkPaned can have 2, 1 or 0 free slots and
GtkBoxes can always take new children.

> > 2. a new add_child member to feature named linkage arguments.
> > 
> > and it can peacfully coexist besides the normal gtk_container_add()
> > fucntionality.
> > i'll probably do this once i get more time to work on GLE.
> > 
> > > 
> > > Andreas
> > > 
> > > 
> > 
> > ---
> > ciaoTJ
> > 
>                                                                     ___
> Dov Grobgeld                        | Email: dov@orbotech.co.il    /+  \  PCB
> 

---
ciaoTJ