Re: help needed: window focus bugs

[Elijah Newren <newren math utah edu>]

On Thu, 12 Aug 2004, Lubos Lunak wrote:

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

Very good point.  I tested the initial gtk+ & startup-notification
implementation in February under KDE 3.2.  But I neglected to test KDE
apps inside Gnome (uh, oops).  And things have clearly changed--at
least slightly--since February.

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

Unless those apps are forwarding startup notification information, we'll
fail as badly in those cases as we are now with gnome-terminal, epiphany,
nautilus, etc.

<snip>

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

Interesting.  I hadn't thought about giving users the ability to request a
window appear in the background.  But I can see how it'd be useful and how
it's now made pretty easy.

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

Ah, so you special case for various apps?  I was wondering if you did
that.  I think testing gnome apps under KDE as well would be good (or
even using Kwin within Gnome as some users are known to do), but this may
make it more difficult.  Is there any chance you could provide a list of
gnome apps that you have turned off focus stealing prevention for?  Is
there any easy way to turn it back on?

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

Apps can't obtain TIMESTAMP?  Crap.  Yeah, a change to the spec sounds
good to me.  The sooner, the better.  :-)

>  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

This doesn't make sense to me.  (Of course, lots of other things go over
my head too since I've only learned part of the startup-notification
details so far).  If app A (say, kicker or gnome-panel) is launching
other apps, isn't it the responsibility of app A to get the timestamp of
the user-interaction that caused the app to be launched and use that
timestamp in the startup notification message?  I don't see how using
that timestamp for the startup ID makes it any more accurate than using
that timestamp for the TIMESTAMP property.  Am I missing something?

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

I don't follow all the details (and I gotta run right now so I'll have
to re-read this later).  Maybe Rob or Havoc can comment since they
understand that stuff much better.  However, if the proposal allows
apps to get the timestamp used in startup-notification that they were
launched with, then definitely send the proposal.  We need that.


Thanks Lubos,
Elijah