embedded perl/Gtk dialog

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

embedded perl/Gtk dialog

Carl Nygard

I've got an app that uses Perl as the embedded scripting environment.
I'm trying to write some scripts that pop up a dialog to query the user
for some simple things, and I'm running into problems.

I have a wrapper class which manages widget creation via glade and I'm
using Gtk2::GladeXML to load and run the dialog.  The wrapper class also
manages lifetime and destroys the dialog at appropriate times.

a) the first time I run the dialog, it pops up over my app.  The second
and subsequent times, it stays under the app, and the little panel icon
button for the dialog window flashes attention.  Why doesn't it popup
over my app anymore?

b) When I hit the cancel button, the dialog stays open.  Well, the
contents won't get refreshed if obscured, but the container window
doesn't go away, even though I destroy() the dialog from a DESTROY sub
in the wrapper class.

Any clues?

Regards,
Carl

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: embedded perl/Gtk dialog

Aristotle Pagaltzis
* Carl Nygard <[hidden email]> [2005-07-01 05:25]:
> a) the first time I run the dialog, it pops up over my app.
> The second and subsequent times, it stays under the app
>
> b) When I hit the cancel button, the dialog stays open.

Those two are obviously related, no? The first time you run it,
it is instantiated and pops up. So far so good, but then it is
never actually destroyed, as far as I understand Glade, only
hidden (and I seem to remember that Glade instantiates widgets
only once, if you destroy them afterwards, they are gone).
Apparently it remembers where it was when it is unhidden, just
like it was there all the time, but invisible.

I’m not sure how to make it pop over the app window – there’s
possibly a method to make it go to the front, though. And I’d say
the solution to your cancel problem is to not destroy the popup,
only hide it.

In any case, I’m only making educated guesses, but what I know
for sure is that you need a better understanding of how Glade
manages its widgets. I could tell you more if I had ever used it
myself, but so far that’s not been the case.

Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: embedded perl/Gtk dialog

Carl Nygard
On Fri, 2005-07-01 at 10:21 +0200, A. Pagaltzis wrote:

> * Carl Nygard <[hidden email]> [2005-07-01 05:25]:
> > a) the first time I run the dialog, it pops up over my app.
> > The second and subsequent times, it stays under the app
> >
> > b) When I hit the cancel button, the dialog stays open.
>
> Those two are obviously related, no? The first time you run it,
> it is instantiated and pops up. So far so good, but then it is
> never actually destroyed, as far as I understand Glade, only
> hidden (and I seem to remember that Glade instantiates widgets
> only once, if you destroy them afterwards, they are gone).
> Apparently it remembers where it was when it is unhidden, just
> like it was there all the time, but invisible.

Well, I'm destroy()'ing it directly myself, regardless of what glade may
or may not be doing.  

I had a few more thoughts this morning after a good sleep.  The widget
is a dialog, and I had seen some wierd behavior when setting the
'Center' or 'Center on Parent' behavior, which gave me and idea.
Perhaps the dialog doesn't have a proper parent, so uses RootWindow or
some such.  First time through it can pop to the top, but once I use my
app again, it's brought to the top.  If I run the script again, which
reloads the glade widgets, whatever it's choosing as the dialog parent
is no longer 'on top' so neither is the dialog.  

Perhaps?

>
> I’m not sure how to make it pop over the app window – there’s
> possibly a method to make it go to the front, though. And I’d say
> the solution to your cancel problem is to not destroy the popup,
> only hide it.

I looked for a 'raise' type function, couldn't find anything related.
Anyone know how to bring a window to the front?

Thanks,
Carl

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: embedded perl/Gtk dialog

muppet-6
In reply to this post by Aristotle Pagaltzis

A. Pagaltzis said:
> I'm not sure how to make it pop over the app window - there's
> possibly a method to make it go to the front, though.

$window->present;

http://developer.gnome.org/doc/API/2.0/gtk/GtkWindow.html#id2856265




--
muppet <scott at asofyet dot org>

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: embedded perl/Gtk dialog

Carl Nygard
In reply to this post by Aristotle Pagaltzis
On Fri, 2005-07-01 at 10:21 +0200, A. Pagaltzis wrote:

> * Carl Nygard <[hidden email]> [2005-07-01 05:25]:
> > a) the first time I run the dialog, it pops up over my app.
> > The second and subsequent times, it stays under the app
> >
> > b) When I hit the cancel button, the dialog stays open.
>
> Those two are obviously related, no? The first time you run it,
> it is instantiated and pops up. So far so good, but then it is
> never actually destroyed, as far as I understand Glade, only
> hidden (and I seem to remember that Glade instantiates widgets
> only once, if you destroy them afterwards, they are gone).
> Apparently it remembers where it was when it is unhidden, just
> like it was there all the time, but invisible.

Putzing around with it, I've got it working to my satisfaction --almost.
I need to figure out how to get Glade to stop cacheing the widgets.  For
example, if I run the script, then edit the glade file, then run the
script again, the second iteration doesn't see the changes I've made.

Anyone know how to turn off the caching in GladeXML?  If I suck in the
file as a buffer, then pass the buffer to GladeXML, will that defeat the
caching (ie. is the cache filename based?)

Alternatively, a method to make the widget popup over the main app would
be good, and $window->present doesn't seem to work in this case.


>
> I’m not sure how to make it pop over the app window – there’s
> possibly a method to make it go to the front, though. And I’d say
> the solution to your cancel problem is to not destroy the popup,
> only hide it.
>
> In any case, I’m only making educated guesses, but what I know
> for sure is that you need a better understanding of how Glade
> manages its widgets. I could tell you more if I had ever used it
> myself, but so far that’s not been the case.
>
> Regards,

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: embedded perl/Gtk dialog

Carl Nygard
On Fri, 2005-07-01 at 21:01 -0400, Carl Nygard wrote:

> On Fri, 2005-07-01 at 10:21 +0200, A. Pagaltzis wrote:
> > * Carl Nygard <[hidden email]> [2005-07-01 05:25]:
> > > a) the first time I run the dialog, it pops up over my app.
> > > The second and subsequent times, it stays under the app
> > >
> > > b) When I hit the cancel button, the dialog stays open.
> >
> > Those two are obviously related, no? The first time you run it,
> > it is instantiated and pops up. So far so good, but then it is
> > never actually destroyed, as far as I understand Glade, only
> > hidden (and I seem to remember that Glade instantiates widgets
> > only once, if you destroy them afterwards, they are gone).
> > Apparently it remembers where it was when it is unhidden, just
> > like it was there all the time, but invisible.
>
> Putzing around with it, I've got it working to my satisfaction --almost.
> I need to figure out how to get Glade to stop cacheing the widgets.  For
> example, if I run the script, then edit the glade file, then run the
> script again, the second iteration doesn't see the changes I've made.
>
> Anyone know how to turn off the caching in GladeXML?  If I suck in the
> file as a buffer, then pass the buffer to GladeXML, will that defeat the
> caching (ie. is the cache filename based?)

Reading the file myself and using GladeXML::new_from_buffer() doesn't
cache the widget per-se, I can see changes to the xml file when I re-run
the script.  But it still pops up under the main app, and
$window->present() does nothing to help.

Any clues?

>
> Alternatively, a method to make the widget popup over the main app would
> be good, and $window->present doesn't seem to work in this case.
>
>
> >
> > I’m not sure how to make it pop over the app window – there’s
> > possibly a method to make it go to the front, though. And I’d say
> > the solution to your cancel problem is to not destroy the popup,
> > only hide it.
> >
> > In any case, I’m only making educated guesses, but what I know
> > for sure is that you need a better understanding of how Glade
> > manages its widgets. I could tell you more if I had ever used it
> > myself, but so far that’s not been the case.
> >
> > Regards,
>
> _______________________________________________
> gtk-perl-list mailing list
> [hidden email]
> http://mail.gnome.org/mailman/listinfo/gtk-perl-list

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: embedded perl/Gtk dialog

muppet-6

On Jul 1, 2005, at 9:43 PM, Carl Nygard wrote:

> Reading the file myself and using GladeXML::new_from_buffer() doesn't
> cache the widget per-se, I can see changes to the xml file when I  
> re-run
> the script.  But it still pops up under the main app, and
> $window->present() does nothing to help.
>
> Any clues?

At this point, i think you need to post code, because the  
descriptions don't match up with what should be happening, and the  
possibilities of what you might be doing differently than expected  
are too numerous.




--
Without treatment, a common cold will last about seven days.
With treatment, it will last about a week.
   -- conventional wisdom

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: embedded perl/Gtk dialog

Carl Nygard
On Sat, 2005-07-02 at 10:00 -0400, muppet wrote:

> On Jul 1, 2005, at 9:43 PM, Carl Nygard wrote:
>
> > Reading the file myself and using GladeXML::new_from_buffer() doesn't
> > cache the widget per-se, I can see changes to the xml file when I  
> > re-run
> > the script.  But it still pops up under the main app, and
> > $window->present() does nothing to help.
> >
> > Any clues?
>
> At this point, i think you need to post code, because the  
> descriptions don't match up with what should be happening, and the  
> possibilities of what you might be doing differently than expected  
> are too numerous.

Unfortunately, it's not really possible/practical to post code, since
the main app is a C++/Zaf/OpenMotif/Gdk::Pixbuf happy bastardization of
an app that's running an embedded perl interpreter to provide script
facilities.

What I do know is that it has nothing to do with GladeXML, since I
rewrote the Dialog wrapper to generate the Gtk::Dialog on the fly from
scratch, and it exhibits the same problem.  And I know the dialog is
getting destroy'd after every embedded script run...

My current guess revolves around the possibility that Gtk::Dialog->new()
does something special to finagle a parent widget, and that parent
widget doesn't have anything to do with the app parent widget (which
would be Xlib/Motif window).  So the window manager gets confused about
what constitutes "front".  Although I have to wonder, if the window
manager thinks its in front after the $window->present() function call,
why does it blink the panel-icon-button-thingy to show that the window
is hidden?

Whatever, I still have some ideas for experiments, so I'll pursue those
in the absence of any other smart ideas from y'all.

Regards,
Carl

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: embedded perl/Gtk dialog

muppet-6

On Jul 2, 2005, at 9:28 PM, Carl Nygard wrote:

> On Sat, 2005-07-02 at 10:00 -0400, muppet wrote:

>> At this point, i think you need to post code, because the
>> descriptions don't match up with what should be happening, and the
>> possibilities of what you might be doing differently than expected
>> are too numerous.
>
> Unfortunately, it's not really possible/practical to post code, since
> the main app is a C++/Zaf/OpenMotif/Gdk::Pixbuf happy  
> bastardization of
> an app that's running an embedded perl interpreter to provide script
> facilities.

Er, sorry, i forgot you'd said it was embedded.

Does your embedded interpreter persist, or do you create a new  
interpreter for each script?  Is the interpreter in the main process  
or do you launch a child process for the interpreter?  The gtk2-perl  
bindings don't unregister their types from glib at shutdown, so you  
may have bizarre problems with new in-process interpreters.


> What I do know is that it has nothing to do with GladeXML, since I
> rewrote the Dialog wrapper to generate the Gtk::Dialog on the fly from
> scratch, and it exhibits the same problem.  And I know the dialog is
> getting destroy'd after every embedded script run...

I just noticed that in an earlier post you said you were overriding  
DESTROY to call ->destroy on the window...  are you overriding  
DESTROY on a Glib::Object derivative?  (E.g., the GladeXML object?)  
Glib::Object::DESTROY is one of those special "never override this,  
and if you do, do not fail to chain up" methods.  This is where lives  
the magic that breaks the association between the C GObject and the  
perl wrapper.  If DESTROY doesn't run properly, the object could be  
kept artificially alive in a zombie state, and would likely keep all  
its children alive, as well.

Another possibility, which seems likely since you said there are  
multiple toolkits in the app, is that you're not letting the glib  
main loop run after the call to $window->destroy, and the destruction  
can't finalize itself (e.g., remove the X window from the screen).



> My current guess revolves around the possibility that Gtk::Dialog-
> >new()
> does something special to finagle a parent widget,

Well, no, it doesn't.  Unless you specifically tell a GtkDialog what  
parent window to use, it considers the root window to be its parent.


> and that parent
> widget doesn't have anything to do with the app parent widget (which
> would be Xlib/Motif window).

You'll have to set the parent explicitly.  With glade, that would be

    $glade->get_widget ('the-window')->set_transient_for ($parent);

and when creating the dialog by hand, you can pass $parent to the  
full constructor.

Since your app is a mixed bag, you will have to do extra work to get  
the parent.  gtk_window_set_transient_for() wants a GtkWindow, but if  
your parent window is a motif or Xlib window, you don't have a  
GtkWidget for it.  If you can get the XID of the window, you can use  
a gdk call, $gdkwindow = Gtk2::Gdk::Window->foreign_new ($xid), to  
get a GdkWindow for that XID.  Then, you can call

    $dialog->window->set_transient_for ($foreign_gdkwindow);

after $dialog is realized.

As for how to get the XID...  if you're embedding the interpreter,  
you can write some XS.  Don't forget that you can hide some of this  
stuff in XS by using Glib and Gtk2's extension support.


> So the window manager gets confused about
> what constitutes "front".  Although I have to wonder, if the window
> manager thinks its in front after the $window->present() function  
> call,
> why does it blink the panel-icon-button-thingy to show that the window
> is hidden?

This part of the interaction is something on which i can't really  
comment without something on which to experiment.


--
"the ternary operator makes it a bit less ugly."
     -- kaffee

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: embedded perl/Gtk dialog

Carl Nygard
On Sun, 2005-07-03 at 09:23 -0400, muppet wrote:

> On Jul 2, 2005, at 9:28 PM, Carl Nygard wrote:
>
> > On Sat, 2005-07-02 at 10:00 -0400, muppet wrote:
>
> >> At this point, i think you need to post code, because the
> >> descriptions don't match up with what should be happening, and the
> >> possibilities of what you might be doing differently than expected
> >> are too numerous.
> >
> > Unfortunately, it's not really possible/practical to post code, since
> > the main app is a C++/Zaf/OpenMotif/Gdk::Pixbuf happy  
> > bastardization of
> > an app that's running an embedded perl interpreter to provide script
> > facilities.
>
> Er, sorry, i forgot you'd said it was embedded.
>
> Does your embedded interpreter persist, or do you create a new  
> interpreter for each script?  Is the interpreter in the main process  
> or do you launch a child process for the interpreter?  The gtk2-perl  
> bindings don't unregister their types from glib at shutdown, so you  
> may have bizarre problems with new in-process interpreters.
>
The embedded interpreter persists, in the main process, no
forks/threads.  Each script basically defines a function called 'MEL',
and there is a loader for the script file which essentially calls 'do
$file' to load and parse the file, then calls the MEL() function to run
the script, which typically returns an XML block which the app then
interprets and acts upon.

One question, is it bad to be calling 'use Gtk2 -init' every time I try
to pop up a Dialog?

>
> > What I do know is that it has nothing to do with GladeXML, since I
> > rewrote the Dialog wrapper to generate the Gtk::Dialog on the fly from
> > scratch, and it exhibits the same problem.  And I know the dialog is
> > getting destroy'd after every embedded script run...
>
> I just noticed that in an earlier post you said you were overriding  
> DESTROY to call ->destroy on the window...  are you overriding  
> DESTROY on a Glib::Object derivative?  (E.g., the GladeXML object?)  
> Glib::Object::DESTROY is one of those special "never override this,  
> and if you do, do not fail to chain up" methods.  This is where lives  
> the magic that breaks the association between the C GObject and the  
> perl wrapper.  If DESTROY doesn't run properly, the object could be  
> kept artificially alive in a zombie state, and would likely keep all  
> its children alive, as well.
>
> Another possibility, which seems likely since you said there are  
> multiple toolkits in the app, is that you're not letting the glib  
> main loop run after the call to $window->destroy, and the destruction  
> can't finalize itself (e.g., remove the X window from the screen).
>
Ok, tried that, still didn't work.  I run the Gtk2 main loop before and
after I show/hide the dialog, so shouldn't deferred activity get done
there anyway?

>
>
> > My current guess revolves around the possibility that Gtk::Dialog-
> > >new()
> > does something special to finagle a parent widget,
>
> Well, no, it doesn't.  Unless you specifically tell a GtkDialog what  
> parent window to use, it considers the root window to be its parent.
>
>
> > and that parent
> > widget doesn't have anything to do with the app parent widget (which
> > would be Xlib/Motif window).
>
> You'll have to set the parent explicitly.  With glade, that would be
>
>     $glade->get_widget ('the-window')->set_transient_for ($parent);
>
> and when creating the dialog by hand, you can pass $parent to the  
> full constructor.
>
> Since your app is a mixed bag, you will have to do extra work to get  
> the parent.  gtk_window_set_transient_for() wants a GtkWindow, but if  
> your parent window is a motif or Xlib window, you don't have a  
> GtkWidget for it.  If you can get the XID of the window, you can use  
> a gdk call, $gdkwindow = Gtk2::Gdk::Window->foreign_new ($xid), to  
> get a GdkWindow for that XID.  Then, you can call
>
>     $dialog->window->set_transient_for ($foreign_gdkwindow);
>
> after $dialog is realized.
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.

>
> As for how to get the XID...  if you're embedding the interpreter,  
> you can write some XS.  Don't forget that you can hide some of this  
> stuff in XS by using Glib and Gtk2's extension support.
>
>
> > So the window manager gets confused about
> > what constitutes "front".  Although I have to wonder, if the window
> > manager thinks its in front after the $window->present() function  
> > call,
> > why does it blink the panel-icon-button-thingy to show that the window
> > is hidden?
>
> This part of the interaction is something on which i can't really  
> comment without something on which to experiment.
>
Well, you're already the most helpful open source developer I've ever
run across, so thanks for what you've already suggested.

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)

Thanks,
Carl


_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Dialog.pm (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: embedded perl/Gtk dialog

muppet-6

On Jul 4, 2005, at 10:46 AM, Carl Nygard wrote:

> One question, is it bad to be calling 'use Gtk2 -init' every time I  
> try to pop up a Dialog?

Nope.  gtk_init() is set up to run the first time and then return  
immediately on subsequent invocations.  In fact, if you call gtk_init
() elsewhere in your app (before the Gtk2-Perl stuff), then you don't  
even need it in the script.


>> Another possibility [...] is that you're not letting the glib
>> main loop run after the call to $window->destroy [...].
>
> Ok, tried that, still didn't work.  I run the Gtk2 main loop before  
> and
> after I show/hide the dialog, so shouldn't deferred activity get done
> there anyway?

Should, yes.

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) ?


>> [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.  :-)



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

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.

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.

Are you sure that Dialog::DESTROY is running?  I presume that's why  
you have the print() in there...


--
Brian: If i recall correctly, this is the physics department.
Chris: That explains all that gravity.
     -- Family Guy, "The Story on Page One"

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: embedded perl/Gtk dialog

Carl Nygard
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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: embedded perl/Gtk dialog

Carl Nygard
In reply to this post by muppet-6
On Mon, 2005-07-04 at 12:37 -0400, muppet wrote:
> On Jul 4, 2005, at 10:46 AM, Carl Nygard wrote:
[snip]
> Are you sure that Dialog::DESTROY is running?  I presume that's why  
> you have the print() in there...

Actually,
a) DESTROY is not running, and I'm not sure why (and that's an odd
deja-vu looking at that sentence),
b) I fixed up your suggestion for set_transient_for, didn't fix the
problem
c) Even resorted to trying to pop down the app window before running the
perl script, but the app window didn't budge.  hmm.
d) thew up my hands, blamed Zaf, and I'm moving on.  One more reason to
convince the boss to ditch Zaf and move to Gtk.

Thanks for all the help.

Regards,
Carl

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: embedded perl/Gtk dialog

muppet-6

On Jul 4, 2005, at 11:11 PM, Carl Nygard wrote:

> On Mon, 2005-07-04 at 12:37 -0400, muppet wrote:
>
>> On Jul 4, 2005, at 10:46 AM, Carl Nygard wrote:
>>
> [snip]
>
>> Are you sure that Dialog::DESTROY is running?  I presume that's why
>> you have the print() in there...
>
> Actually,
> a) DESTROY is not running, and I'm not sure why (and that's an odd
> deja-vu looking at that sentence),

If DESTROY is not running, then $dialog->destroy doesn't get called,  
so the dialog won't leave the screen.  Not surprising.

You can test that hypothesis with an explicit ->destroy after you're  
finished reading the widgets.


> b) I fixed up your suggestion for set_transient_for, didn't fix the
> problem

There's a fix in there, somewhere, but once you figure out the zombie  
dialog problem, the solution here will probably present itself.  :-)


> c) Even resorted to trying to pop down the app window before  
> running the
> perl script, but the app window didn't budge.  hmm.

Try offering it a fudgesicle.  I'd move for a fudgesicle.  Mmmmm,  
fudgesicle.


> d) thew up my hands, blamed Zaf, and I'm moving on.  One more  
> reason to
> convince the boss to ditch Zaf and move to Gtk.

Good luck.  Down with excessive complexity!  Power to the people!


--
Found: Poop
Someone's dog lost some poop in front of the Studio Theatre.  
Unfortunately, this article has been slightly damaged since it was  
neglectfully left on the sidewalk. It is available to its rightful  
owner (or its owner's rightful owner) if they so desire to come and  
scrape it off my shoe.
   -- someplace on the internet

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: embedded perl/Gtk dialog

Aristotle Pagaltzis
In reply to this post by Carl Nygard
* Carl Nygard <[hidden email]> [2005-07-05 05:20]:
> d) thew up my hands, blamed Zaf, and I'm moving on.  One more
> reason to convince the boss to ditch Zaf and move to Gtk.

FWIW, in a gtk2-based, Perl-enabled build of gvim, Gtk2-Perl
scripts Just Work as advertised.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list