Re: _WIN_WORKSPACE and _WIN_AREA behaviour

[Marko Macek <Marko Macek gmx net>]

Tim Janik wrote:
> 
> 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 don't know much about WIN_AREA, and WIN_STATE_FIXED_POSITION, because
icewm doesn't implement them.

> 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:

Application can set the default desktop before mapping the window.
Afterwards, the WM will update the property as it receives the below
message.
 
>    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).

Yes, that should work.
 
> 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).

WIN_STATE_STICKY means that window will be visible on all
desktops/workspaces.

WIN_STATE_FIXED_POSITION means that window will not change position as
virtual desktop is scrolled.

They should be independent.

> 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.

They are not supposed to be.

> 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.

Why? This is not necessary. The pager can check the WIN_STATE_STICKY
flag and assume that window is visible on all workspaces/desktops.
 
> 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).

That's obsolete. Gone. Not needed and also a performance penalty. They
were icewm internal flags that I mistakenly exported.

Mark
-- 
... GUI: WPS.
------------------------------------------------------------------------
Marko.Macek@gmx.net                 http://www.kiss.uni-lj.si/~k4fr0235/