Re: help needed: window focus bugs

[Elijah Newren <newren math utah edu>]

On Wed, 11 Aug 2004, Havoc Pennington wrote:

> If we can't get this working nicely by 2.8, disabling the feature
> totally is a 1-line metacity patch

...which patch is in bug 149276, for the curious.  (I hear some groups,
such as breakmygentoo, are already shipping Metacity 2.8.2 and using
that patch)

> (to unconditionally focus new windows). But we should keep fixing and
> trying to get the feature in until the last minute.


> Before testing/fixing, be sure you have latest startup-notification,
> metacity, libwnck, gtk+, and gnome-panel.

*and* gnome-desktop.  and nautilus, if you launch apps from it.  (Some of
these don't really need to be the latest (e.g. gtk+ >= 2.4.1 is fine), but
some do)

<snip>

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

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

<snip>

> A possible global fix is to change GTK+, but I'm not sure that's right.

Um, no.  That's not possible.  gtk+ was patched to support this spec and
handle the majority of cases for apps (bug 115650).  But it can't handle
all cases that apps are responsible for; there's just no way for it to
have the necessary information.  The problem is that apps have the
responsibility to set the _NET_WM_USER_TIME for new windows they open
to the timestamp of the user-interaction that caused the window to be
opened.  If the user interaction that caused it to be opened was in a
different application, gtk+ has no way of knowing about it.  gtk+ does
provide a function to override it's default choice for _NET_WM_USER_TIME
in these cases, namely gdk_x11_window_set_user_time.  Well...actually
gtk+ version 2.6 does (the function didn't make it in time for API freeze
of gtk+-2.4).  Apps using gtk+ 2.4 will have to cut-and-paste from the
_gdk_x11_window_set_user_time function in gdk/x11/gdkwindow-x11.c.

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


If anything is unclear, let me know.

Cheers,
Elijah