Re: embedded perl/Gtk dialog

On Mon, 2005-07-04 at 12:37 -0400, muppet wrote:
On Jul 4, 2005, at 10:46 AM, Carl Nygard wrote:

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 class which provides a simple interface for  
up and populating dialog boxes.  The MEL() script would create a  
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)


Incidentally, you can replace your hand-maintained "$PackageName"  
with the built-in "__PACKAGE__".


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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]