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

[Lubos Lunak <l lunak suse cz>]

On Wednesday 27 of July 2005 20:12, Billy Biggs wrote:
>   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.

 Qt has actually two independent focuses - it has QWidget::setFocus() and 
QWidget::activateWindow(), first one just setting the internal focus inside 
one toplevel window, the other one causing window activation and changing the 
X focus. If you want to focus something in a dialog, just setFocus() does the 
job, assuming the window also has or will get the X focus. 
QWidget::activateWindow() is rarely used, as it means fighting the window 
manager policy.

 No idea how Gtk handles this, but I'd expect something similar.

>
>   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.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/