late 1.9d comments

[Sasha_Vasko osca state mo us]

Hi

I'm new to this list, and I regret the fact that I've missed all the fun of
discussions,
which would without doubt be interesting to me as AfterStep developer.
Anyway, better later then never.

I presume that 1.9d is the latest available version of specs, even thou I've
seen
some e-mails in archive regarding post-1.9d TODO list.

I've read 1.9d, and I can say that I like it - it is covering most important
things, without
overloading it with unneccessary stuff. I feel that most of it will be supported
by AfterStep,
as underlying code already exists for it.

At the same time I have few suggestions/thoughts that, I hope, are not too late
to
be considered.

Please excuse me if I mention something that was discussed before. In this case
friendly
information on the proceedings that took place, and consensus reached, would be
most
helpfull and appreciated :)

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.

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 ?

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.

3)  _NET_DESKTOP_NAMES

Window Manager may not really care as to what are names of virtual desktops.
Therefore saying that it MUST update this property is not entirely correct. It
may fool
ppl into thinking that this is the mandatory property.

Perhaps more precise formulation " MUST update this list if property is
supported."
would be better?

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

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.

6) any better clarification as to why _NET_WM_NAME should be used instead of
WM_NAME ???
7) same question about _NET_WM_ICON  - what was wrong with  WM_HINTS ???

I hope I made you tired enough :)

Thanks for the attention (or lack of it :)

Sasha Vasko
AfterStep developer.