Before I comment specifically, I'll introduce myself. I am (at least
one) of the other gaim folk Ethan referred to. I also understand the
problems with the EWMH for window managers that don't exactly fit into
the standard paradigm, I'm an ion3 user. I am also quite interested in
getting this (and other similar issues) worked out appropriately. So
with all that in mind, read on.
On Fri, 24 Mar 2006, Olivier Chapuis wrote:
Ethan Blanton a écrit :
Olivier Chapuis spake unto us the following wisdom:
Now a note on _NET_CURRENT_DESKTOP (and _NET_DESKTOP_VIEW PORT), the
EWMH spec says that this property (as a client msg) is for a pager. Thus
if gtk_window_present() uses this property (and one may understand that
it uses it in the *view of the doc*), you may understand that you go
beyond what an application is espected to do at startup: is gaim a
Pager?
After some discussion with the Gaim folk who grok Gtk+, we have some
questions ... are you actually _seeing_ _NET_CURRENT_DESKTOP or
_NET_DESKTOP_VIEWPORT?
I do not know I do not use gaim (I use psi). But I read the
discussion on the forum and Dominik conclude that such msg was send by gaim.
Moreover, my gtk_window_present() doc says:
"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."
So the doc says that gtk_window_present() may send a _NET_CURRENT_DESKTOP
client msg. Maybe this depends on the version of gtk ...
Not exactly, the documentation says that calling that function might
cause the window to move to the current desktop. It doesn't say that it
might switch the current desktop to the one the window is on. And as
_NET_CURRENT_DESKTOP is the property indicating the current desktop I
wouldn't assume sending that is what gtk_window_present does at all.
Furthermore, I have looked at the gtk code for gtk_window_present and,
at least in the cvs checkout I am looking at, all it does is call
gdk_window_show and gdk_window_focus. gdk_window_show does a bunch of
things, but the only part of note (as fas as I can tell) is call
XMapWindow. gdk_window_focus checks that the wm lists support for
_NET_ACTIVE_WINDOW and then it sends a _NET_ACTIVE_WINDOW message using
XSendEvent.
So if someone is seeing gtk do something else I would very much like to
know what and which gtk version they are using.
As best we can tell, gtk_window_present()
calls gtk_window_show() when the window is not visible, and
gtk_window_focus() when it is. We suspect that the gtk_window_focus
is the problem, as it raises _NET_ACTIVE_WINDOW. Is it possible that
fvwm is actually seeing _NET_ACTIVE_WINDOW, this causes it to switch
desktops/pages? If so, is this an inappropriate client message (I
don't believe it is.) It is clearly causing a behavior that at least
some users are not pleased with.
I think that Dominik ask the user with the gaim problem to disable
_NET_ACTIVE_WINDOW msg for fvwm and the switching was still there. Dominik?
I am also quite interested in the response to this.
I do not think that _NET_ACTIVE_WINDOW is an inappropriate msg if the source
indication is set to 2 (indicating a normal application msg). gtk does that
with gtk_window_show() I think. I will add: a normal application can set the
source indication to 1 (taskbar/pager) or send a _NET_CURRENT_DESKTOP msg if
and only if this depends on a direct user action or if this is a (non
default) option of the app (e.g., maybe some user like to have focus problems
and want that an IM msg force the focus to the discussion window :o).
The source indication for a pager is 2, for application is 1. Which gtk
does correctly for gdk_window_focus (which as I explained is what
gtk_window_present calls). gdk_window_focus doesn't set data.l[2] (since
that would require more information than they have), nor do I really
know how much help that would be here (or even in general).
I do not think that an application that is not a pager should ever set
source indication to 2, if any does I would claim that application is
broken. I also think that (ab)using _NET_ACTIVE_WINDOW is a problem.
Using it to present any existing (and even some new) windows is not the
problem, the problem is when this is unavoidable and is used for no
reason.
All that being said, I agree that using gtk_window_present to show the
buddy list at startup is not the right thing to do and I will make sure
it gets fixed.
Olivier
-Etan
