Re: embedded perl/Gtk dialog

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

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

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