Re: focus stealing prevention (was Re: _NET_ACTIVE_WINDOW, revisited)

[Billy Biggs <vektor dumbterm net>]

Lubos Lunak (l lunak suse cz):

> On Wednesday 27 of July 2005 18:34, Elijah Newren wrote:
> > On 7/27/05, Lubos Lunak <l lunak suse cz> 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