Re: [gtk-list] Suggestion for Perl/GTk packing
- From: Kenneth Albanowski <kjahds kjahds com>
- To: gtk-list redhat com
- Subject: Re: [gtk-list] Suggestion for Perl/GTk packing
- Date: Sun, 19 Apr 1998 22:49:29 -0400 (EDT)
On Sun, 19 Apr 1998 dov@Orbotech.Co.IL wrote:
> 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
> 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
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.
> $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
Kenneth Albanowski (email@example.com, CIS: 70705,126)
] [Thread Prev