After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 150668 - _NET_ACTIVE_WINDOW window support is outdated
_NET_ACTIVE_WINDOW window support is outdated
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: X11
2.4.x
Other Linux
: High normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks: 149028
 
 
Reported: 2004-08-20 21:02 UTC by Elijah Newren
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: 2.8.0
GNOME version: 2.7/2.8


Attachments
Update _NET_ACTIVE_WINDOW to current spec (891 bytes, patch)
2004-08-20 21:05 UTC, Elijah Newren
none Details | Review

Description Elijah Newren 2004-08-20 21:02:19 UTC
The EWMH spec for _NET_ACTIVE_WINDOW has changed to include 
  1) Whether the request is coming from an app or a pager
  2) The timestamp of the event causing the request
  3) the ID of the currently active window making the request (only used by
     KWin, and only if certain options are set, if I understand correctly)

I'll attach a patch momentarily that does this, except that it gets item (3)
wrong.  If someone can point me to the location to obtain the info for that
item, I'll update.

Without this patch, whether to focus that window in Metacity can be buggy due to
_NET_WM_USER_TIME (which is updated using that timestamp) being set wrong.
Comment 1 Elijah Newren 2004-08-20 21:05:15 UTC
Created attachment 30794 [details] [review]
Update _NET_ACTIVE_WINDOW to current spec

This patch is against the gtk-2-4 branch, but appears to apply cleanly to HEAD
which also needs to be fixed.
Comment 2 Matthias Clasen 2004-08-22 04:38:06 UTC
I think just using GDK_WINDOW_XID (window) for the currently active window is
worse than just using None; I don't think we have a concept of "currently active
toplevel" on the gdk layer. We do have it in gtk, though. Does KWin behave
acceptably if we just use None for the window ?
Comment 3 Owen Taylor 2004-08-22 13:21:43 UTC
It shouldn't be hard to iterate the through the current toplevels to
find one we think is active, but it sounds really strange, I'd like
to know why that got added to the wm-spec ... generally the currently
active toplevel is something that the window manager knows and GTK+
simply monitors. (Poorly as it turns out :-(, there are still bugs in
that code)
Comment 4 Elijah Newren 2004-08-23 02:36:26 UTC
The spec states that none is allowed ("data.l[2] = requestor's currently active
window, 0 if none") although it is possibly misleading.

The reasoning stated in the wm-spec for this feature is "the currently active
window is the Client's active toplevel window, if any (the Window Manager may
be e.g. more likely to obey the request if it will mean transferring
focus from one active window to another)."

From what I remember of reading Lubos' emails on the subject, he was worried
about apps trying to make a certain window take focus without any kind of user
interaction occurring to make that happen, i.e. he wanted to catch areas where
an application without focus tried to focus some window and then prevent it.

As far as I know, we aren't planning to do anything of the sort with Metacity
and we will just ignore that field.  In fact, we recently added a patch to
libwnck (see comments 101 through 109 of bug 118372) similar to this gtk+ one
which just sets data.l[2] to 0.  But then again, I'm not sure if Havoc allowed
that on purpose, or if he just forgot about it and my question about it when he
approved the patch.
Comment 5 Matthias Clasen 2004-08-23 04:46:36 UTC
The EWMH addition seems a bit dubious in any case. Owen, are you ok with just
setting the window to None ?
Comment 6 Matthias Clasen 2004-08-23 15:13:35 UTC
 
2004-08-23  Matthias Clasen  <mclasen@redhat.com>

	* gdk/x11/gdkwindow-x11.c (gdk_window_focus): Support the latest
	EWMH additions to the _NET_ACTIVE_WINDOW client message 
	format.  (#150668, Elijah Newren)