Subject: Re: behaviour of window.present() on different WM - msg#00046

List: gnome.gtk+.python

Date: Prev Next Index Thread: Prev Next Index

On Thu, 9 Dec 2004 22:18:18 +0100, Gian Mario Tagliaretti
<g.tagliaretti@xxxxxxxxxxxxxxxx> wrote:

<snip>

> def newTree(self, widget, event):
> self.win2 = gtk.Window(gtk.WINDOW_TOPLEVEL)
> self.win2.set_default_size(300, 300)
> self.tree = gtk.TreeView()
> self.win2.add(self.tree)
> self.win2.show_all()
> self.win.grab_focus()
> self.win.present()

Short answer: I belive that you should use
self.win2.set_focus_on_map(gtk.FALSE) before showing it and remove the
calls you used to focus self.win.

Problem with short answer: This is the correct way for X window
managers, but not all support the _NET_WM_USER_TIME property in the
EWMH spec of freedesktop.org yet. (Metacity has support in the 2.8.x
releases with x>=5, but it was disabled because some libraries and
apps don't have sufficient support--so you'll actually have to wait
for Gnome 2.10 for Metacity support...). So, this probably still
won't work today for you, but other than some hack to force self.win2
to be mapped (and not just queued for mapping) before calling
self.win.present() I don't see any way to currently get the behavior
you want consistently.

Long answer:
This looks like a race condition to me. I don't know how Windows
works, so let me just assume you're on an X server.
self.win2.show_all() tells gtk to show the window, which then has gtk+
do a bunch of stuff to tell X to map the window. But, of course, X is
asynchronous and it gets around to mapping it when it wants to...

You then call self.win.present, to try to make sure self.win is
focused instead of self.win2. This also ends up in a gtk+ call that
results in an X client message to the window manager.

Now, the window manager is (probably) going to focus self.win when it
gets the Xclient message generated from your self.win.present() call,
and is (probably) going to focus self.win2 when it receives the
mapping notification for that window. However, the order in which
those two events are received is non-deterministic. (I say probably
in both cases because the window manager is free to do just about
whatever it wants in most circumstances, even without violating the
EWMH spec)

Those events are sent from gtk+ with a timestamp (assuming a
sufficiently recent version of gtk+) but unfortunately they'll both be
sent with the timestamp of gtk_get_current_event_time so the window
manager will be unable to distinguish the present() call as having
come later.

> self.win2.set_keep_above(gtk.TRUE)

Why are you setting the ABOVE state? I believe what you want to do is
to self.win2.set_transient_for(self.win) -- that doesn't have the
nasty side-effects of keep_above (which, the gtk+ documentation aptly
states that app authors should avoid).

> After I spoke with xordoquy (thanks again) in IRC he proposed this:
>
> def newTree(self, widget, event):
> self.win2 = gtk.Window(gtk.WINDOW_TOPLEVEL)
> self.win2.set_default_size(300, 300)
> self.tree = gtk.TreeView()
> self.win2.add(self.tree)
> self.win2.show_all()
> gtk.idle_add(self.delay)
>
> def delay(self):
> self.win.present()
> self.win.grab_focus()
> self.win2.set_keep_above(gtk.TRUE)

This is basically an attempt to avoid the race condition by adding a
timing separation between the self.win2.show_all() and the
self.win.present(). It doesn't look very failproof...

> It does work only once (the first time you press a button but then not
> anymore) on gnome (metacity), with fluxbox it doesn't work at all.

Another question is whether fluxbox supports _NET_ACTIVE_WINDOW (since
gtk_window_present is implemented by sending that X client message...)

Hope that helps,
Elijah
_______________________________________________
pygtk mailing list pygtk@xxxxxxxxxx
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/

Was this page helpful?

Thread at a glance:

Previous Message by Date: click to view message preview

behaviour of window.present() on different WM

Hi list, I'm trying to popup a window_toplevel (win2) when a key is pressed in a first window_toplevel (win) but I also want to keep the first one (win) the active window with the focus on the textview inside (win), at the end the second (win2) have to stay on top anyway... To achieve this goal I'm using window.present() on (win) after the second is popped-up (win2) then textview.grab_focus and window.set_keep_above(gtk.TRUE) on the second window (win2).... Because probably my english sucks...let's post some code: This is the first version, it works perfectly on the following DE or WM: kde, openbox, waimea, fvwm2, xfce4 and also Microsoft Windows. When a key is pressed on win1, win2 is shown, win1 gets active and the focus is into the textview. but it does not work on: gnome (metacity) and fluxbox. import pygtk pygtk.require('2.0') import gtk class SecondWin: def __init__(self): self.win = gtk.Window(gtk.WINDOW_TOPLEVEL) self.win.connect("delete_event", self.delete_event) self.win.connect("destroy", self.destroy) self.win.connect("key-press-event", self.newTree) self.win.set_default_size(500, 500) self.text = gtk.TextView() self.win.add(self.text) self.win.show_all() def newTree(self, widget, event): self.win2 = gtk.Window(gtk.WINDOW_TOPLEVEL) self.win2.set_default_size(300, 300) self.tree = gtk.TreeView() self.win2.add(self.tree) self.win2.show_all() self.win.grab_focus() self.win.present() self.win2.set_keep_above(gtk.TRUE) def delete_event(self, widget, event, data=None): return gtk.FALSE def destroy(self, widget, data=None): return gtk.main_quit() def main(self): gtk.main() if __name__ == "__main__": second = SecondWin() second.main() After I spoke with xordoquy (thanks again) in IRC he proposed this: def newTree(self, widget, event): self.win2 = gtk.Window(gtk.WINDOW_TOPLEVEL) self.win2.set_default_size(300, 300) self.tree = gtk.TreeView() self.win2.add(self.tree) self.win2.show_all() gtk.idle_add(self.delay) def delay(self): self.win.present() self.win.grab_focus() self.win2.set_keep_above(gtk.TRUE) It does work only once (the first time you press a button but then not anymore) on gnome (metacity), with fluxbox it doesn't work at all. Sorry for the long post but I would like to understand why this happen and maybe what I can do to have my code running as I would like on all the DE / WM. Thanks a lot to everybody for the patience. Have a nice day, evening or whatever in the world now :) GMario _______________________________________________ pygtk mailing list pygtk@xxxxxxxxxx http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/

Next Message by Date: click to view message preview

drag-and-drop signal propagation

Do drag-and-drop signals not propagate to parent widgets like other signals? Nested widgets can attach signal handlers to a signal, and then return gtk.FALSE if they want the signal to be propagated to their ancestors But returning gtk.FALSE from a signal handler attached to a drag-and-drop signal (specifically, 'drag_motion') does not seem to propagate the signal to parent widgets. Is there some way to force DND signals to propagate to parent widgets? Perhaps I am really stupid and just missing something important. I'm including some sample code with a series of nested widgets that demonstrates this. Clicking anywhere propagates the click signal to all parent widgets. But dragging "middle" over anything only raises the signal on the current widget. matt ps. I assume that there is no built-in way to have a scrolled window containing drag targets automatically scroll as you drag a drag-source over it... propagate-test.py Description: Text Data _______________________________________________ pygtk mailing list pygtk@xxxxxxxxxx http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/

Previous Message by Thread: click to view message preview

Next Message by Thread: click to view message preview

Re: behaviour of window.present() on different WM

On Thursday 09 December 2004 23:16, Elijah Newren wrote: First of all I would like to thank you really a lot for your answer. > Short answer: I belive that you should use > self.win2.set_focus_on_map(gtk.FALSE) before showing it and remove the > calls you used to focus self.win. This method is available only for pygtk 2.6, at the moment I thought that mine was the best way to do it. > I don't see any way to currently get the behavior you want consistently. Then I have to try to understand how scintilla works... They could do something like this with the autocompletion widget, used for instance into Anjuta, but maybe they did something completely different. > Problem with short answer: This is the correct way for X window > managers, but not all support the _NET_WM_USER_TIME property in the > EWMH spec of freedesktop.org yet. <snip> I will have a look to the EWMH of freedeskotp.org, another thing to learn. <snip> > > self.win2.set_keep_above(gtk.TRUE) > > Why are you setting the ABOVE state? I believe what you want to do is > to self.win2.set_transient_for(self.win) -- that doesn't have the > nasty side-effects of keep_above (which, the gtk+ documentation aptly > states that app authors should avoid). I didn't know about the nasty side-effects, I will have a look also to this. > > It does work only once (the first time you press a button but then not > > anymore) on gnome (metacity), with fluxbox it doesn't work at all. > > Another question is whether fluxbox supports _NET_ACTIVE_WINDOW (since > gtk_window_present is implemented by sending that X client message...) I think I will "disturb" fluxbox author and ask :-) > Hope that helps, > Elijah Again many many thanks Elijah cheers GMario _______________________________________________ pygtk mailing list pygtk@xxxxxxxxxx http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/

Loading Comments...