Focus fixes (was Re: [Portland] Issues with 1.0beta2 and KDE)

[Lubos Lunak]

On Thursday 03 August 2006 22:01, Bastian, Waldo wrote:
> >- There are problems with focus stealing prevention if kfmclient opens a
> >window for an application that has already some windows open - the new
> >window is then open in background. Most visible when using xdg-email with
> > the mailer already open. It looks like nobody has ever run into this
> > scenario or nobody has ever used kfmclient at all (KDE apps use the
> > functionality directly and there the activation is handled properly).
> >
> > I'm unsure what to do with this. I'll fix kfmclient for KDE3.5.5 but I
> >don't
> >know about the scripts. Just ignoring this problem doesn't seem to be that
> >good solution, I can probably add a hack for KMail but I have no idea how
> >to
> >handle the case when the user has some other mailer configured for use in
> >KDE :-/.
>
> Can't help you with that one.

 Ok, I did the mistake of considering xdg-utils as scripts here - they may be 
scripts, but designed to be used by apps. So the solution should be like in 
DAPI, there should be some association with the application, window handle 
most probably. And I guess you're not going to be very happy about this, 
because it'll probably need a small binary.

 In a nutshell, e.g. opening another composer window in KMail this way looks 
like KMail, running in background, tries to open another window -> the window 
manager sees that as an attempt to interrupt the user's work and prevents 
activation of such window. In order to know it should allow that it would 
have to know either that the new window is related to the currently active 
application or that the new window is a result of a recent user activity. 
Which it cannot know on its own and needs to get this info from the 
application, either the handle of the app's window or the app's user activity 
timestamp.

 Now, the options are roughly like this:

- not doing anything. Users of KDE and GNOME (and whoever decides to implement 
focus stealing prevention as well) will occassionally have this problem.

- Always allowing activation of such windows. Then the question would be why 
there'd be such feature in the first place indeed. And even if you could 
argue that xdg-utils are just simple scripts then a later solution like DAPI 
would need some of the solutions like below anyway, so there'd be a problem 
either now or later when switching from xdg-utils to the next generation 
solution.

- All affected scripts would need mandatory option --parentwindow (or whatever 
you call it, I'm bad at names) which would apps set to the X handle of their 
active window. A binary would be needed to somehow hackishly create a 
matching user activity timestamp related to the window. Very simple binary, 
nevertheless a binary, no idea how to do that just with a script. Apps would 
also be required to do XFlush() before any calls to the scripts (although 
that's a good idea in general).

- All affected scripts would need mandatory --usertimestamp (or 
maybe --parentwindow in some cases) and would have to support 
_NET_WM_USER_TIME [1] if their toolkit doesn't support it already. Actually 
rather trivial to add, like 10-20 lines of code, but anyway. Hopefully no 
binary shipped with xdg-utils should be needed now though. Technically the 
right solution I believe.

 Preferences?


[1] http://standards.freedesktop.org/wm-spec/wm-spec-1.4.html#id2511909

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