Lubos Lunak ([EMAIL PROTECTED]): > On Wednesday 27 of July 2005 18:34, Elijah Newren wrote: > > On 7/27/05, Lubos Lunak <[EMAIL PROTECTED]> wrote: > > > On Tuesday 26 of July 2005 18:54, Elijah Newren wrote: > > [Offtopic: Now that I think about it, I think I can fix Billy's > > problem by patching gdk_window_focus() to use the most recent user > > interaction timestamp whenever 0 is passed. That'll simplify > > gtk_window_present() as well...] > > I personally think Billy's primary problem is the fact that they use > _NET_ACTIVE_WINDOW too much. When an application shows a new dialog > window it shouldn't do _NET_ACTIVE_WINDOW on it just in case or for > the fun of it. AFAIK all modern toolkits keep the X focus only on the > toplevel window and maintain their own internal focus, for good > reasons. So there should be rarely a reason to mess with the X focus.
If the app asks for focus to be given to a button, and we don't think the window with the button has focus, we call gdk_window_focus(). This is what happens when a new dialog is opened: we haven't yet got the event from GTK+ to tell us that the dialog has focus. To fix it, I'd have to store in the toolkit something that says "I just opened this dialog, focus will be going over there, so optimize this case". This code is tricky. When is the flag cleared? Consider an app that opens two dialogs, one a main wizard, and one a context sensitive help window, and it wants focus to be in the main wizard. It's clearly easier and safer from my point of view to always call gdk_window_focus() whenever the app is asking focus to go to a widget and I haven't yet got the events to tell me that it's likely already there. -Billy _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list
