Re: Is this list alive?

["Michael Rogers" <mrogers cs ucl ac uk>]

> Since I have not seen any followups on my previous post and
> I know there has been some problems with list I repost it here :

Sorry, I meant to reply to your first post, but I thought I'd see if someone 
more informed did it first.  They didn't, so you got me.  :)
 
> 1)  _NET_WM_STRUT
> 
> I don't feel that this property has any sense at all, as client cannot be 
> aware of how much decoration WindowManager will decide to place around it, 
> as well as the exact location where it will be displayed on screen. In case 
> of virtual root window used it is not possible to obtain size of decorations 
> at all as client cannot simply traverse window hierarchy up to the Root.
> Even if client attempts to change this property after window is mapped and
> decorated, and it can safely determine decorations size  - it has no 
> garantee that it will stay put.
> It is possible that decorations may change without synthetic ConfigureNotify 
> event being sent to client.
> 
> Another concern here is that if client is not sticky and window manager 
> supports virtual viewport then client will get moved around, involving 
> additional burden of resetting this property too  often and requiring WM to 
> recalculate maximize area too many times.

I don't think the description of _NET_WM_STRUT in 1.9d describes the original 
idea, which was (IIRC) that a client should be able to specify a rectangle of 
its own window which the WM should avoid covering. The description in 1.9d 
makes it sound like an area of the screen is specified.

I think the property should describe a rectangle (x, y, w, h) within the 
window on which the property is set. Coordinates are relative to that window. 
So wherever the window is moved or however it's decorated, the same part of 
its contents is described. The client never needs to check or update the 
property.

If some windows which define struts are viewport-sticky and some are not, then 
the WM may end up recalculating the maximise area frequently during viewport 
scrolling - however, I would not expect non-viewport-sticky windows to define 
struts, because the property was concieved to stop windows like docks and 
panels being covered. I would expect docks and panels to be viewport-sticky. 

The WM could avoid recalculating the maximise area until viewport scrolling is 
complete, on the assumption that no windows will be maximised during viewport 
scrolling.

> All of this boils down to fact that this hint cannot safely be used without
> other hints, like sticky/modal status.
> 
> IMHO this would be much better to have a special attribute, that simply 
> tells WM that it should avoid covering this client's window with other 
> windows at all costs, and let WM decide how much space to reserve, and 
> where to reserve it.
> Perhaps _NET_WM_STATE_AVOID_COVER  addition to _NET_WM_STATE hints ?

The application knows best which parts of its window can be covered and which 
cannot. The WM could interpret the presence of a strut as a do-not-cover hint 
for the whole window, if you want a simple implementation.

> 2) _NET_NUMBER_OF_DESKTOPS
> 
> The spec does not cover the fact that Window Manager may have unlimited 
> number of desktops available. That overall is a valid approach as having 
> virtual desktop PER SE does not impose any resource/performance penalties, 
> untill it actually getting used, while providing user with greater freedom 
> and consistency. Such an approach is employed by fvwm and *cogh* AfterStep.
>
> Perhaps value of 0xFFFFFFFF or 0x0 should be reserved to indicate to any 
> Pager implementation that it should take care of how many desks to provide 
> access to, without any limitations imposed by Window Manager.

Maybe the list of desktops could be interpreted as a list of the desktops 
which are currently in use (ie the pager needs to be interested in them)? 
This might also include desktops which have previously been used but do not 
currently have any windows on them.

Sorry to get philospophical, but in what sense does a desktop exist before it 
has a name or has some windows placed on it? Does the pager need to care about 
it? If not, maybe it should be kept internal to the WM and only get added to 
the list of desktops when it becomes "interesting".

> 4) Just wanted to cast my vote for inclusion of _NET_VIRTUAL_ROOT property
> into specs, as that is the only way for any client  ( like xident) that 
> desires to allow user to freely select windows on screen with pointer, to be 
> able to work correctly with window manager that supports virtual roots. It 
> is also usefull for other things, like any animator, that wants to draw on 
> root window, etc..

We have to be careful with this, because people implementing virtual root 
windows (eg in a file manager) may expect to draw directly onto the virtual 
root window (eg to draw icons). If another app draws all over the virtual root 
window, it will destroy the desktop icons. The file manager, unaware of this, 
will not redraw them. The spec should clearly state whether:

(a) The virtual root window is for drawing the background *only*. No client 
(including the owner of the virtual root window) should expect its contents to 
be safe. Any drawing which needs to be kept safe from other clients should be 
done in children of the virtual root window.

(b) The virtual root window should only be drawn on by its owner. In this case 
it would be a good idea to specify another interface for drawing on the 
background or setting the background image. Ideally this would allow (eg) a 
web browser to set the background image for a particular virtual root window, 
and have it restored at the beginning of the next session by the owner of the 
virtual root window. Maybe this should be left for version 2 however, and we 
should simply say in version 1 that the virtual root window is not to be drawn 
on by other clients?

> 5) were there any plans/comments  for inclusion of something like
> _NET_ROOT_PIXMAP into specs ? This is extremely usefull thing for any 
> transparency related stuff, that cannot be acheived by usage of 
> ParentRelative background type.
> 
> This approach is used, and will always be used by E and AfterStep, and IMHO 
> it will only benefit the user if it will be supported by other apps that 
> allows setting of the root pixmap. Althou special provisions has to be made 
> for run-once imaging apps, as they should leave such a pixmap in memory 
> after finishing its work.

I second this - at the moment gnome-terminal does not update its 
pseudo-transparent background when the root window background is changed. 
Using virtual root windows will break ParentRelative transparency as well, I 
suppose, unless top-level windows are reparented into the virtual root window 
(which seems unlikely if the virtual root window is not owned the WM).


Michael