_WIN_WORKSPACE and _WIN_AREA behaviour

[Tim Janik <timj gtk org>]

hi everyone,

i'm not exactly sure how the _WIN_WORKSPACE and _WIN_AREA properties
should behave (especially with respect to WIN_STATE_STICKY and
WIN_STATE_FIXED_POSITION windows).
i would have expected the window manager to update WORKSPACE and AREA upon
desktop and/or area switches for all sticky/fixed position windows
automatically, but aparently (at least with enlightement) this is not the
case. the current documentation says:

   _WIN_WORKSPACE is a CARDINAL that is the Desktop number the app would
   like to be on. This desktop number is updated by the Window Manager
   after the window is mapped and until the window is unmapped by the
   application. The value for this property is simply the numeric for the
   desktop 0, being the first desktop available.

this doesn't actually make much sense to me, especially after looking at
the gnomepager_applet implementation (written by raster), gnome-winhints.c
(the current _WIN_* stuff implementation in gnome-libs) and the documentation
on how to change the current desktop, which says:

   If an application wishes to change the current active desktop it will
   send a client message to the root window as follows:

  xev.type = ClientMessage;
  xev.window = client_window;
  xev.message_type = XInternAtom(disp, XA_WIN_WORKSPACE, False);
  xev.format = 32;
  xev.data.l[0] = new_desktop_number;
  XSendEvent(disp, root, False, SubstructureNotifyMask, (XEvent *) );

   If the Window Manager picks up any of these ClientMessage events it
   should honor them.
                        
so i'd actually expect _WIN_WORKSPACE to work the this way:
the app sets this property for unmapped windows, and while the window is
mapped, the window manager updates this property (according to e.g. client
messages sent by the app).

if that's the case, the above mentioned docu should probably be corrected.
also, how does this related to WIN_STATE_FIXED_POSITION and WIN_STATE_STICKY
windows? experimenting a bit with a recent CVS version of enlightment showed
that sticky windows will actually always stay on the current desktop and
within the current area, while fixed position windows will only stay
within the current area but never change desktops (so they kinda "stick" on
one desktop only).
during any of these area and desktop changes, neither the _WIN_WORKSPACE nor
the _WIN_AREA properties got updated on the fixed position or sticky windows,
to actually reflect the current desktop/current area.

if this is intended behaviour, i'd suggest to change the _WIN_WORKSPACE and
_WIN_AREA semantics to actually get updated with any desktop/area switches
on sticky (fixed position etc..) windows, otherwise applications (e.g. a
pager) have a hard time to figure what windows are actually on the current
area/desktop.

i'd also be glad if someone could provide more information on the

  #define WIN_STATE_FIXED_POSITION  (1<<8) /*window is fixed in position even*/

flag, especially on how that's actually different from WIN_STATE_STICKY, i.e.
does it really mean be-sticky-on-one-desktop-only?

on a related topic, i'm kinda lost with regards to the

  #define WIN_STATE_HID_WORKSPACE   (1<<6) /*not on current desktop*/

flag, what is this meant to indicate?
if it should flag all windows that are not on the current desktop, the window
manager would have to update *all* client window's _WIN_STATE properties on
the old and the new desktop upon switches, which would probably impose an
unneccessary performance impact? (not that i've seen a window manager/
application actually making use of this flag yet).

---
ciaoTJ