Re: Is this list alive?

[Sasha_Vasko osca state mo us]

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

I must say, that I like this original idea much better, and if it is really
intended to
be this way - then specs should be updated to explicitly state that. Right now
it says
somthing completely opposite - that :
"...The property is a 4-tupel of cardinals, one for each border of the
screen..."
which is something uncomprehendable.

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

That won't be a problem if this property is intended the way you say it is.
Otherwise non-sticky window would have to update it every  WM moves it around,
and that will result in double the culculations performed, as you will
recalculate evrything
once you done moving stuff, and then you'll recalculate evrything again when
property
gets updated, and as the result of this second recalculation you may need to
move stuff
around again, as newly requested avoid cover rectangle is covered.

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

cool
I withdraw this idea if specs are to be updated the way you say it should be.

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

You see it poses a considerable difficulties - to grow and shrink a list of used
desktops.
How can I know that desk is unused and I should remove it from list ? That there
are no windows in it ? That would be incorrect. For example I may have more used
desks,
and lesser used desks, and those lesser used desks may have no windows on them
for
some time, but I still want to see them on my pager, and be able to switch to
them using
Pager, whenever I have a whim to do so.
On the other hand user may erroneously hit the wrong key ( repeatedly ) and
create
bunch of unneeded desks, and clatter Pager in this way, if desk list is to grow
dynamically.

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

It exists in the sense that if user tells me as a WM to go and put some
particular window
on desk #256, I would humbly go and create virtual root for this desk, internal
data structure and
everything else, and place this window on this desk. Again if Pager would ask me
to switch
to this desk - I would go there without questioning Pager's autority.
Before that happen - desktop existed only as a possibility - without occupying
any resources,
after - it exists as implementation.
That also leads us to another problem - desks may not be numbered in order - you
may use desks
0, 10, 100 - in which cases I, as a window manager will have to maintain some
sort of crossreferece
betwenn Pager's desk numbers and my internal desk numbers, and also user might
be dissatisfyed
with the fact that Pager is showing those desks as numbered 0,1,2 instead of
wanted 0, 10, 100.

All said boils down to the fact that WM may desire to provide better flexibility
and freedom, by
exporting decision making process out of self and into Pager, and placing
such an ungrounded restriction as to force a limited fixed number of desks is
something that can be
done out of lazyness only.  Another good reason to add this is that any sane
Pager implementation
would want to do some range checking on number of desktops any way, and fallback
on some
predefined behavior it it exceeds some reasonable value. By adding this
provision to the
specs you simply mandate this fallback behavior to be standard among Pagers.

>> 4) Just wanted to cast my vote for inclusion of _NET_VIRTUAL_ROOT property
...
>> 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.

I agree with that

>
>(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?

Yep, it is quite complicated matter, as it involves fact that window manager/
background drawing app may not support some graphical formats, and where
those image files are to be stored and other things. For now, I think,
_NET_ROOT_PIXMAP  should do fine.

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

ParentRelative does not really gets broken, since virtual root must either use
ParentRelative itself , or have same background as root. So mostly it's for
things like
shading/tinting and to allow apps, external to WM, set desktop background.

>
>Michael

Cheers
Sasha