On Wed, 16 May 2007 20:54:34 +0200 David Nečas (Yeti) wrote:
>On Wed, May 16, 2007 at 11:28:55AM -0700, Brian J. Tarricone wrote:
>
>> This is caused by the window manager, not gtk. It thinks the
>> application isn't responding because it takes too long to return from
>> the delete-event handler.
>
>This is interesting, do you know what exactly the window
>manager is waiting for? Because it has of course no idea
>what your code does inside (namely whether it is in some
>handler or not) -- and you let Gtk+ main loop run, so it
>responds to events normally. Therefore the window manager
>expects some specific reaction from the client on delete.
>
>However, it cannot be destruction of the window as that
>would break all applications that allow one to cancel the
>closing of the window. Returning TRUE also prevents the
>default Gtk+ handler from running, so anything else Gtk+
>could do there cannot be the thing. So what is it?
My assumption here is that the WM was sending a _NET_WM_PING to the
window after trying to close it (as suggested in the WM spec[1]), but
you're right, presumably gdk/gtk should still be responding to those
events even with a modal dialog up. Unless the recursive mainloop
created by gtk_dialog_run() for a modal dialog *wouldn't* allow gdk/gtk
to respond to a ping on a different window. Not sure, but that's the
only reason I can see: otherwise I don't know why this would be
happening, as I'm pretty sure that you're right that returning TRUE or
FALSE from the gtk event handler doesn't actually send any X events.
-brian
[1]
http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2512097
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
