Re: embedded perl/Gtk dialog

[muppet <scott asofyet org>]

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