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

[Dov Grobgeld <dov Orbotech Co IL>]

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.

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

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

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

> 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
Algorithms Department, Orbotech     | Phone: +972-8-9423882        \  +/  AOI
Yavne 70651, Israel                 | Fax:   +972-8-9423775       __| |
               Disclaimer: All views above are mine alone.        ____|