I'm OK with changing this in metacity, I can't think of a reason why
not really. We need to fix the tasklist at the same time.

We really need to get this fixed.  I'll look into it soon; bumping up the
priority so it doesn't get lost...

Created attachment 37532 [details] [review]
Metacity patch to fix the problem

I'm going to attach the libwnck portion of the patch to bug 161361 because I
have combined it with patches for two other things (the three libwnck patches
would have conflicted because they are modifying the same parts of the code and
are doing fairly similar things so it made sense to not separate them).

Comment on attachment 37532 [details] [review]
Metacity patch to fix the problem

thanks!

committed:

2005-02-20  Elijah Newren  <newren@gmail.com>

	* src/window.c: (meta_window_activate): when receiving a
	_NET_ACTIVE_WINDOW message, switch to the desktop where the window
	is located before activating instead of moving the window to the
	current desktop.  Thanks to Lubos Lunak for catching this issue.
	Fixes #128380.

*** Bug 168201 has been marked as a duplicate of this bug. ***

This change really badly breaks Tomboy and Nautilus.  How do I work around this?

If you _need_ the window to be moved to the current workspace instead of
changing the current workspace to the one where the window is, then you need to
use a _NET_WM_DESKTOP message instead of a _NET_ACTIVE_WINDOW message.  This is
either an application bug or a gtk+ bug (depending on your view of what
gtk_window_present should do).  See also bug 166379.

Either way, this metacity change was correct so I'm reclosing.

From docs on gtk_window_present:

 * This function should be used when the user tries to open a window
 * that's already open. Say for example the preferences dialog is
 * currently open, and the user chooses Preferences from the menu
 * a second time; use gtk_window_present() to move the already-open dialog
 * where the user can see it.

And an inline comment:

      /* note that gdk_window_focus() will also move the window to
       * the current desktop, for WM spec compliant window managers.
       */

Congrats, you broke ABI.

gdk_window_present is the api for sending _NET_ACTIVE_WINDOW for the window.  It
still does that; nothing has changed.

Its up to the window manager to decide what to do with this information. 
Previously, metacity handled it differently from other window managers.  Now, it
handles it similarly to other window managers.

I do not see _NET_ACTIVE_WINDOW mentioned in gtk_window_present doco anywhere.

The documentation is wrong and should probably be updated, though you'll need a
new bug for that.  Of course, if your application is broken now because of the
change, it means that it was previously broken under every window manager that
isn't metacity.  Now, at least, you can fix it so it'll work for every window
manager.

FWIW, the (weird) metacity behaviour was already causing problems for some
applications (https://bugs.eclipse.org/bugs/show_bug.cgi?id=82387).

(mid-air collision, but I'll send it anyway...)

Hi Alex,

You have spent an awful lot of time in email and bugzilla today.  You could have
put a lot of that time into actually fixing stuff.  At very least you could have
avoided demotivating others from helping with your tone.  Anyway, your claims
are based on misconstruing the comments and are not accurate.  In particular,
the start of the comment defining the functionality of gtk_window_present()
which you neglected to mention is the following:

 * Presents a window to the user. This may mean raising the window
 * in the stacking order, deiconifying it, moving it to the current
 * desktop, and/or giving it the keyboard focus, possibly dependent
 * on the user's platform, window manager, and preferences.

This makes it absolutely clear that the behavior depends on the window manager.
 You tried to base your claim about functionality off only the last half of the
comments (which doesn't say what you need) along with an inline comment from the
middle of the code.  Yes, it is unfortunate that the comment from the middle of
the code was wrong, but it is not part of the definition of the function or part
of the API/ABI guarantee.  (If it was, gtk+ was buggy because past versions
would have been broken on most window managers; it would have only worked for
people using Metacity by relying on this bug existing).

In summary, this change was correct, it was needed, and it didn't break ABI.  As
I said before, we may want to change gtk_window_present to use _NET_WM_DESKTOP
(bug 166379).  But that's a different bug.

I shouldn't respond when frustrated, especially when lots of that frustration
was due to other stuff.   Sorry for being so excessively harsh, Alex.  You're
probably just frustrated too from trying to debug stuff.  Anyway, if you need a
temporary workaround to call (while waiting for gtk_window_present to change, if
it does), I can help you write a modified version that makes use of _NET_WM_DESKTOP.

*** Bug 171543 has been marked as a duplicate of this bug. ***

This patch is being reverted.  This has been discussed at 
http://mail.gnome.org/archives/wm-spec-list/2005-July/msg00028.html; since Lubos
drop his objection about possible breakage of taskbars after my explanation,
there seems to be no problems with reverting.  So, I'm doing it now.

The basic reasoning for the reverting of this patch was because keeping it would
mean introducing policy to the _NET_ACTIVE_WINDOW message (one which we don't
like and which others might not either), resulting in some apps (e.g. all gtk+
ones that use gtk_window_present() for activation) trying to send additional
messages to enforce the policy they like while others just use the
_NET_ACTIVE_WINDOW message.  In other words, the patch induced inconsistency
among apps from different toolkits.

If anyone has issues they believe are related to this, please open a new bug. 
This note is mostly for completeness.

Reverted on both the gnome-2-10 branch and HEAD.  New 2.10.x release (2.10.3)
just sent out.