Re: help needed: window focus bugs

[Lubos Lunak <l lunak suse cz>]

On Thursday 12 of August 2004 06:09, Elijah Newren wrote:
> On Wed, 11 Aug 2004, Havoc Pennington wrote:
> > A new feature in 2.7 is "focus stealing prevention," an implementation
> > of part of the extended window manager hints. KDE already implements
> > this feature.
> >
> > Those of you running 2.7 have no doubt noticed there are some bugs left
> > ;-) many of these require modifications to applications. It would be
> > very helpful if maintainers of applications that aren't getting focused
> > appropriately could help fix their applications.

 It'd be nice of you could test it a bit with KDE apps too. I think I've got 
it finally working quite nicely for KDE3.3, and there even haven't been 
complaints about 3.2.3, so I think having something like a flawless (ehm ;) ) 
reference implementation could help you. Moreover you can indeed test latest 
GNOME easier than I can.

 Some more complicated usage cases are e.g. running kcontrol if it has already 
an instance running or opening another URL with konqueror already running.

> > Apps may also explicitly set the timestamp to 0, which means to never
> > focus that new window. e.g. an IM client might use this.
>
> In this paragraph, I may be providing unnecessary info, but... there may
> be no need for an IM client to do so.  The _NET_WM_USER_TIME timestamp
> needs to be set for all new windows beyond the first by the application
> (for the very first window, the TIMESTAMP from startup notification is
> used).  gtk+ provides a sane default by setting it to the timestamp of
> the last user interaction with any window of the app.  Thus new IM
> windows would only take focus if the IM app was the last app interacted
> with.  This can happen, for example, if the user launches the IM app and
> then just sits and waits for an IM.  If the user happens to interact with
> any other app, IM windows don't take focus.  So, by default, IM apps
> should work.

 Yes, this is right. The very original proposal on the wm-list@ was only about 
_NET_WM_DONT_GIVE_FOCUS (or whatever was the name), and since I already had 
the plan for focus stealing prevention, I proposed the _NET_WM_USER_TIME 
stuff and left 0 timestamp for those who wouldn't want to have the full 
functionality.

> (Well...unless the user is using chatting in one IM window 
> and gets an IM from someone else, opening a new window.  So maybe there
> is a reason for the IM client to set the timestamp to 0 after all.  :-)

 Actually one place I know where this is used is when one does Shift+MMB on a 
link in Konqueror - it opens the new window in background this way (plus a 
not-that-well working fallback if the WM has no support).

> > When does it break: the most common problem right now is launching new
> > windows for existing apps
>
> A clarification: the most common problem right now is launching a new
> window from app B for an already running app A.  Opening a new window for
> app A from app A works just fine.

 Yes, that's the only remaining problem I still have. So far the best solution 
I have is fixing the apps that can be fixed and being able to turn focus 
stealing prevention off completely for apps that can't be fixed.

> > Even if that fix goes in, the truly correct change is for epiphany to
> > forward the timestamp (and the startup notification ID) to the new
> > window from the launch sequence. gnome-terminal has an example of doing
> > this for startup notification ID.
> >
> > The bug is: http://bugzilla.gnome.org/show_bug.cgi?id=149028
>
> Unfortunately, that bug contains a lot of superfluous stuff too (in
> particular, about half the comments were to determine that someone had
> a different bug which just sounded similar.)  I think the relevant
> comments are: 4 (the a-f stuff and below), 24, and 32.  Of course, the
> same info is basically in Havoc's last email and this one.

 Actually I was about to propose a change to the spec about this, specifically 
obsoleting TIMESTAMP and saying that the startup ID itself would include the 
timestamp. This makes it possible for the newly started app to find out the 
timestamp, which is not possible with the current way (since TIMESTAMP is 
sent before the app is started).

 I recently had to hack this in the KDE implementation in order to solve some 
corner cases where this is needed, after all my attempts to solve this failed 
(I actually don't remember what exactly was the case where I finally gave up, 
it'd again need a pen, paper and a lot of thinking :-/ ). You'd have the same 
problem in the fifth paragraph ("Of course, this...") of comment #32 in the 
bugreport.

 Moreover this actually makes more sense, since this only makes things better. 
The WM etc. can still get the timestamp, from the ID. Since the timestamp is 
set right when creating the ID, it's more precise, and the app can use its 
user timestamp instead of fetching the X timestamp, to solve the case when 
some background app suddenly launches something. This additionally requires 
another small change in the spec, since now 'change:' messages need to be 
remembered and applied if later a matching 'new:' message comes (since this 
way the startup ID may be created even before you actually know if there 
really will be any startup notification).

 Would that be ok with you? I'd post an update proposal on the xdg@ list about 
this if you don't have a problem with that.

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