Sorry for not responding sooner; I saw the IM at some point but had a bunch of things to do and then somehow lost it (did mozilla crash on me or was that when I was restarting to test tarball installations and such?) and then forgot it.

Short version: metacity (and pygtk & gtk) are all providing correct behavior.  It looks like the app is buggy to me.

Long version:

window_activate() is correct.  It was done that way precisely to avoid apps thinking windows should be raised at random or as side effects to other actions.  The key was originally named orthogonal_raise (though with inverted meaning, i.e. orthogonal_raise == !raise_on_click) to make its meaning clearer that windows should not be raised as a side-effect of anything _other than pager actions_ (user explicitly clicking on the tasklist, etc.), but was renamed because it seems everyone was trained to think in terms of "raise on click".

The _other than pager actions_ bit is important.  The reporter of that downstream bug says
  "It's a Jabber client, and when there are unread messages, clicking in the
  tray icon..."
Sounds to me from the "tray icon" description that they're trying to describe something that is attempting to be a pager (in EWMH speak), i.e. something like a window list, window selector, or workspace switcher applets on the panel.  Yet they are sending the WM hints saying that they are not a pager but are rather a normal application.  That is the bug.  Instead of using gtk_window_present() (which assumes normal applications always), they should use libwnck's wnck_window_activate() after calling wnck_set_client_type() to specify that their app really is a pager (libwnck can be used by apps too, so the default is to assume it's a normal app and it's relatively easy to get the few pagers out their to make this function call).

Thanks for your help and the explanation. I've let him know.

I am the reporter of the downstream bug.

Do I understand correctly that there is no way for a normal application to request that their window be brought to the front (when raise_on_click is on), other than the wnck calls you describe?

Alex: More or less.  The point of raise_on_click (which is slightly misnamed) is to make sure windows don't get raised unless the user either does a special click on them (click on frame or alt-click) or the user clicks on some pager applet (tasklist, window selector, etc.).  gtk+ provides no functionality specific to writing pager applets, whereas libwnck does.  I'm guessing from your description that you were writing something meant to be like a pager applet.  Thus, I suggest using libwnck or writing your own function which sends the appropriate _NET_ACTIVE_WINDOW message.

It's not really meant to be a pager applet, in that it shouldn't be working with windows other than its own.  It's an instant messaging client, which should be able to bring its windows to the front when the notification area icon is clicked, or when entries in the roster are clicked.

It surprises me that an app should have to register as a pager in order to work with its own windows.

The key is as you mention, that raise_on_click is misnamed.  Would a better solution perhaps be to have orthogonal_raise as a distinct gconf key from raise_on_click, and then have window_activate check for that?  I assume there's a good reason to retain the orthogonal_raise behavior...

Using libwnck would be pretty screwy; remember that *any* usage of libwnck is pretty expensive because libwnck will always keep a synchronized, updated copy of all X-server-side state. The right thing to set the "raise from pager" flag would be to just write a small custom Xlib function.

/me notes that this kind of overcomplicated fiasco is why I resisted raise_on_click and other such stuff for so long

Why not just simplify raise_on_click then? Make it affect only what happens when someone clicks in a window (but do always raise when a frame/border is left-clicked please) and not let it get in the way of other types of activation. ISTM that would keep more people happier.

Elijah said, "It's relatively easy to get the few pagers out their (sic) to make this function call [wnck_set_client_type()]." Unfortunately though, it seems to be missing from the python bindings (reported as bug 483529).

Tony:

> Why not just simplify raise_on_click then?

As I stated in bug 326156, you're misusing this setting to try to workaround a bug.  I don't want to break this feature just to make it function as a better workaround for you.  The correct thing to do is to fix your bug (which is bug 152952/bug 154260), and to leave this option alone.

No, I'm not trying to work around those bugs. I just want to be able to use windows (and sometimes that means clicking in them) without them jumping to the front, and I want to be able to configure that with a simple option, not a complicated one with side effects its name doesn't imply.

Consider, say, gimp. It often makes sense to have the main canvas window take up most of the screen with the tools dialog box overlapping part of the canvas you're not working on. With raise_on_click=true you can't really work like that. Maybe it's because I used RISC OS far more than MS Windows, but I just got used to working that way and to me it seems obvious that Windows' window management isn't much good, and unwanted raising is a major reason for that.

Luckily I like sloppy focus so this bug doesn't affect me much, but I'm sure lots of people would like raise_on_click=false to work when focus_mode=click. Ex RISC OS users would find it much easier to get acclimatised to.

(In reply to comment #1)
> The _other than pager actions_ bit is important.  The reporter of that
> downstream bug says
>   "It's a Jabber client, and when there are unread messages, clicking in the
>   tray icon..."
> Sounds to me from the "tray icon" description that they're trying to describe
> something that is attempting to be a pager (in EWMH speak), i.e. something like
> a window list, window selector, or workspace switcher applets on the panel. 
> Yet they are sending the WM hints saying that they are not a pager but are
> rather a normal application.  That is the bug.  Instead of using
> gtk_window_present() (which assumes normal applications always), they should
> use libwnck's wnck_window_activate() after calling wnck_set_client_type() to
> specify that their app really is a pager (libwnck can be used by apps too, so
> the default is to assume it's a normal app and it's relatively easy to get the
> few pagers out their to make this function call).

So, I just noticed this again, and I'd like to take back what I said before.  It sounds like gajim is trying to "launch" a window, but using gtk_window_present() as a hack to achieve this effect with an existing window.  Correct behavior would be to use API to "launch" the app instead of trying to hack in equivalent behavior using something else.  Sadly, _we_ kind of forced this bug ourselves by never providing a GUniqueApp library in the platform (or whatever the library is called these days; Emmanuele has been shepherding it and trying to help move it towards gtk+) for apps to call.

Basically, I'm saying _NET_ACTIVE_WINDOW is being misused as a workaround to no convenient API existing for apps to do what they really want.  (And this isn't the only bad side effect apps are subject to by doing so; see also bug 482354 comment 18.)

Elijah: doesn't this mean that http://pygtk.org/pygtk2reference/class-gtkwindow.html#method-gtkwindow--present is doing the wrong thing?  It seems to me that gajim is using what pygtk says it should in order to achieve the effect it wants to.

so no way really present window to user to current desktop? window.present() works (window is shown to current desktop) with XFWM4, but not with metacity.