On Mon, 2005-07-04 at 12:37 -0400, muppet wrote:
> On Jul 4, 2005, at 10:46 AM, Carl Nygard wrote:
[snip]
>
> Is there any particular reason for the "main iteration while result
> hasn't been set by the button callback" setup instead of the more
> idiomatic "run a main loop and wait for the button callbacks to kill
> it" (a la Gtk2::Dialog::run) ?
Hackery and inertia is the reason. Nothing more. It'll probably get
ripped back out in favor of something more kosher when I figure out
what's happening with the hidden window.
>
>
> >> [esoteric stuff about how to get a parent window].
> >
> > Ugh. Well, I could probably pass the XID to the MEL() script function
> > and let it do the magic Gdk stuff, that's not a big deal. Hopefully I
> > don't have to mess with XS. But thanks, this is exactly what I needed
> > to know for my next experiment.
>
> Heh, if you're messing with an embedded interpreter, you're already
> off into deeper magic than XS. :-)
Yeah, but that doesn't mean I *enjoy* it;)
>
>
>
> > Here's the Dialog.pm class which provides a simple interface for
> > popping
> > up and populating dialog boxes. The MEL() script would create a
> > Dialog,
> > run it, then deal with the results from the user. Some
> > explanation, you
> > probably only need to deal with Create() and DESTROY(). Most of the
> > other stuff is either cruft from the Glade methods, or infrastructure
> > for a derivation framework that makes the Perl modules seem like C++
> > objects (i.e. ctor, copy-ctor, operator=, MI, etc)
>
> > <Dialog.pm>
>
> Incidentally, you can replace your hand-maintained "$PackageName"
> with the built-in "__PACKAGE__".
Thanks.
>
> In Create(), you're creating a plain Gtk2::Window and filling it with
> widgets, including the action buttons. You may find it a little
> easier to use Gtk2::Dialog. In fact, when you were talking about a
> dialog, i thought you meant it was a Gtk2::Dialog. It has an action
> area and response system built in, which will handle some of the work
> you're doing by hand. Also, Gtk2::Dialog::run() will emit the
> "response" signal when the user attempts to close the window via the
> window manager ("delete-event"), whereas with a plain Gtk2::Window,
> the window will just be destroyed (as you have no delete-event
> handler) without doing anything to stop your dialog loop.
Originally, I used Gtk2::Dialog -- you might see hints of it in
commented-out code. I switched to a Gtk2::Window to try to see if a
regular window had any different effect on the main app. Once I figure
this out, I'm hoping I can switch back to Gtk2::Dialog, since it's the
proper widget to use.
>
> In fact, i don't see where you're hooking up most of the signals; i
> see where you connect to the buttons in Create(), but i don't see and
> autoconnect call in CreateGlade(), nor any connections to the
> window's signals.
Originally, running via Create() used a Gtk2::Dialog. CreateGlade()
[which is an alternative interface, not necessarily in-addition-to
Create()] also used a Gtk2::Dialog. So Gtk2::Dialog::run was sufficient
to catch the ok/cancel. The input widgets are attached to the desired
variables via Gtk2::Ex::BindScalar (easy, isn't it?).
>
> Are you sure that Dialog::DESTROY is running? I presume that's why
> you have the print() in there...
Yeah, I've seen the print fire. For a while I thought there was
something wrong with the copying, which is the sole reason for the $id
bit.
Regards,
Carl
_______________________________________________
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
