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

[Kenneth Albanowski <kjahds kjahds com>]

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.

> 1. First of all I think that the idea of creating a method of Widget 
>   called new_child("widget name") like in
>   
>       $window->new_child( Gtk::Button, -label => "the label");
>       
>   is a very good one. With such a function it should be easy to create
>   some AUTOLOAD magic so that:
>   
>       $window->Button(-label=>"the label")
>   
>   will work as well.

Indeed, this one is trivial, and will be in the next release.

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

>   becomes
>   
>        $hbox = $widget->HBox();
>        $button = $hbox->Button(-label=>"a box");
>        $button->pack(-fill=>1, -end => 1)->show();
>        
>   which imho is much cleaner. The -end=>1 may be -side=>'end' or
>   something similar. It really doesn't matter.

Ouch, Tcl syntax. I was hoping to avoid that. And pack() wouldn't really
be Tcl pack, so making it look the same seems a bit dangerous.

Let's put it this way: if something like this does go into the code, it'll
be written in Perl, not C. :-)

> 3. Similarly a method attach() is used to place a widget inside a
>    table(). Actually pack() could be overloaded to do this as it
>    is always known what the parent widget is.

Sounds like it really should invoke _pack in the parent, so normal
inheritance takes care of working out what should be done.

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

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. 

-- 
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)