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

[Dov Grobgeld <dov Orbotech Co IL>]

In your message, Kenneth Albanowski, from 1998-04-19, you wrote:
> On Sun, 19 Apr 1998 dov@Orbotech.Co.IL wrote:
> 
> > Hello,
> > 
> > I have had a long weekend and have read the gtk tutorial. It gave me
> > some ideas of how to merge some of the ideas from Tk together with
> > the Perl/Gtk.
> 
> Bear in mind that I don't think this is necessarily a very good idea: Tk
> just happened to be first, that doesn't make it good, or even useful. I've
> no dislike for Tk, I just don't want to duplicate it for no particular
> reason.

Good ideas are around to borrow. :-) 

> > 2. Gtk::Widget should be given a new method called pack() which 
> >   encapsulates the the three functions gtk_box_pack_start(),
> >   gtk_box_pack_end() and questionably gtk_container_add() . As each
> >   widget knows who its parent is (a consequence of 1 above) it can
> >   check if it is hbox, a vbox, or a frame and do the relevent function
> >   call.
> 
> I'm also hesitant to do this sort of thing, for another reason: once the
> Perl module starts adding all sorts of intelligence over the C code, it's
> more work to keep everything in sync.
> 
> Besides: the trivial implementation of new_child doesn't make this simple.
> Even if it can decide which function to call, there'd be no way to supply
> the arguments to pack_start.
> 
> Note that this idea can be added just as simply to the C code itself, in
> the ::parent argument set routine.

As I said later in my post, I think it is a shame that this
intelligence wasn't put into the C-code from the beginning. But the
C-code has to go into lots of contortions because of its interface
that the script users shouldn't have to be concerned with. Perhaps the
solution in to add even more C-code that are cleaner to connect to from
script languages.

My main concern is not as much with the overloading as with the use
of named parameters. Imho gtk_box_pack_start() and gtk_box_pack_end() 
shouldn't definitely be merged into one routine with their three 
parameters being named parameters that have reasonable defaults. I
think it is reasonable to make this merged routine into a member
function of the widget, but if there is any resistance to this, either
make the parent a parameter of the method, or make it into plain function:

   $child->box_pack($parent, -end=>1, -fill=>1, -pad=>3)
or   
   box_pack($child, $parent, -end=>1, -fill=>1, -pad=>3)

What I do not want to remember is that there are three arguments that
come in the order fill, expand, pad,  or was it the other way
around. ;-)

What is the ::parent argument set routine?
> 
> This is C code: you don't add new parameters. I suppose much of these are
> separate functions to optimize the usual execution path. And they don't
> use varargs and named parameters because that sort of thing is _very_ rare
> in C code, murder to work with, completely breaks the compilers error
> checking, and can make invocation from interpreters nearly impossible. The
> interpreter interface to the varags signal stuff still isn't quite
> working. 

As an example look at the table widget packing routine. The full
version has 9 parameters. The designers realized this is too much and
created the gtk_table_attach_defaults() as a shortcut. But let's 
say that we would like to add the functionality of anchoring or
gravity, i.e. to which side a widget that doesn't fill up all the 
space is moved to. The defaults version won't use this, fine. Changing
the full version will break lots of existing code. The possible solutions,
are either to create yet a new table_attach routine with a new name,
or to create an attribute modification function . In the latter case
you have an unsymmetric solution where some parameters are given in 
the interface, and others given in attribute modification functions.
Named parameters/varargs would have got around these problems.

I agree that it is a pain for script languages to connect to a varargs
routine. But this can be solved with making all the varargs routines
just build up a va_list (from stdarg.h) and then call the "real"
routine which has the single parameter (va_list params). The script
language then interfaces to the va_list routine, and there is no
problem anymore.  But of course the compiler error checking problem
remains.

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