Re: embedded perl/Gtk dialog

[Carl Nygard <cjnygard verizon net>]

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