Comments on 1.0pre3/pre4

[Sasha_Vasko osca state mo us]

> Ok, one more round of comments on 1.0pre3/pre4.
>
> Matthias
>
>
>
> _NET_DESKTOP_VIEWPORT
> _NET_DESKTOP_NAMES

Not the _NET_DESKTOP_NAMES. This one can have different length then
_NET_NUMBER_OF_DESKTOPS. And I think it needs additional clarification.
Part of the rationale is mentioned in the description of
_NET_SETNUMBER_OF_DESKTOPS, but it is kinda short. Idea is that if
WORKAREA, VIRTUAL_ROOTS (if supported) and VIEWPORT are nessessary
attributes
of each desktop, and WM generates/creates those dynamically - NAMES are
not.
Virtual desktops may exist without names - so the NAMES array could be
empty.
Also User usually presets names for a fixed set of the desktops - so adding
more desktops will produce nameless desktops. Again decreasing number of
the
desktops should not really alter this property in order to be able to use
same
names if number of desktops increased later. So Here is the proposed
description :


_NET_DESKTOP_NAMES

The names of the first N desktops. This is a NULL spearated list of strings
in UTF-8 [1] encoding with an additional NULL at the end of the list.
This property MAY be changed by a Pager or the Window Manager at any time.
Note: that N could be different from _NET_NUMBER_OF_DESKTOPS. If it is less
then
_NET_NUMBER_OF_DESKTOPS - then all the desktops with numbers greater then N
are considered to have no names. If N is greater then
_NET_NUMBER_OF_DESKTOPS,
then names outside of the _NET_NUMBER_OF_DESKTOPS are considered to be
reserved
in case number of desktops is increased.

Rationale: Names are not nessessary attribute of the virtual desktop. As
the result
this list of names could be empty, shorter or longer then number of
desktops without
any impact on Virtual Desktop functionality. Since names are set by users
and users
are likely to preset names for fixed number of desktops - it does not make
sense
to shrink or grow this list when the number of available desktops changes.


> _NET_WORKAREA
> _NET_VIRTUAL_ROOTS
>
> It would be a good idea to state explicitly that these properties
> are parallel in the sense that they all contain arrays of length
> _NET_NUMBER_OF_DESKTOPS and their i-th entries all refer to the i-th
> desktop.
>
>
> Maybe we should add some information about allowed values:
>
> The following are always true:
> 0 <= _NET_CURRENT_DESKTOP < _NET_NUMBER_OF_DESKTOPS < 0xFFFFFFFF.
>
> WidthOfScreen  <= _NET_DESKTOP_GEOMETRY.width
> HeightOfScreen <= _NET_DESKTOP_GEOMETRY.height
>
> 0 <= _NET_DESKTOP_VIEWPORT[i].x <= _NET_DESKTOP_GEOMETRY.width -
> WidthOfScreen
> 0 <= _NET_DESKTOP_VIEWPORT[i].y <= _NET_DESKTOP_GEOMETRY.height -
> HeightOfScreen
>
> And a list of allowed values for _NET_SUPPORTED (although I strongly
> question the usefulness of _NET_SUPPORTED):

As was noted before  Selections mechanism is much more standard and cleaner
way to implement that. Since this topic is still under disscussion - may be
it would be better to change specs to use Selections ?

> _NET_CLIENT_LIST
> _NET_CLIENT_LIST_STACKING
> _NET_NUMBER_OF_DESKTOPS
> _NET_DESKTOP_GEOMETRY
> _NET_DESKTOP_VIEWPORT
> _NET_CURRENT_DESKTOP
> _NET_DESKTOP_NAMES
> _NET_ACTIVE_WINDOW
> _NET_WORKAREA
> _NET_VIRTUAL_ROOTS
> _NET_CLOSE_WINDOW
> _NET_WM_MOVERESIZE
> _NET_WM_NAME
> _NET_WM_VISIBLE_NAME
> _NET_WM_DESKTOP
> _NET_WM_WINDOW_TYPE
> _NET_WM_STATE
> _NET_WM_STRUT
> _NET_WM_ICON_GEOMETRY
> _NET_WM_ICON
> _NET_WM_PID
> _NET_WM_HANDLED_ICONS
> _NET_WM_PING
>
>
> _NET_WM_STRUT and _NET_WORKAREA must be explained in more detail.
>
> It is my understanding that the strut quadruples specify a reserved
> border
> around the screen whose width can vary for the four sides. The border
> thickness
> is specified in _NET_WM_STRUT in the following order: left, right, top,
> bottom.
>
> The description of _NET_WORKAREA sounds as if it was defined in the same
> way,
> i.e. specifying the thickness of a border at the left, right, top,
> bottom side
> of the screen. But looking at the implementation made available by
> Bradley
> Hughes, I find workarea specified as a usual geometry, i.e. x, y, width,
>
> height. What gives ? I personally find the usual geometry more natural.
> It should also be specified that this geometry is relative to the
> viewport
> and will always specify a rectangle completely contain
> What about windows which can't be maximized or shaded (e.g. because they
> are
> not decorated with a titlebar) ? This information is not currently
> available
> to pagers/taskbars, so they can't remove the corresponding items from
> their
> menus.

That calls for another property, similar to MWM_FUNC_* and MWM_DECOR_*
from Motif hints, which would list all the functions that could be
performed
on window :

Resize, Move, Minimize, Maximize, Close

Althou it is kinda redundand, since some of it can be set via standard X WM
properties :

Close - WM_PROTOCOLS  (don't set WM_DELETE_WINDOW if you don't want to be
closed )
Maximize, Resize - WM_NORMAL_HINTS ( max_width == min_width and max_height
== min_height )

>
>
> _NET_WM_ICON_NAME ? It has been proposed, why isn't it included ?  Maybe
> this
> has been neglected since most of the stuff addressed by the spec kind of
>
> assumes that no icons are displayed.
>
>
> _NET_WM_ICON_GEOMETRY Is this really a good idea ? It feels very hackish
> to
> expect the WM to display an animation, but not handle the icons. I'd say
> we
> should rather add instructions for detecting the window transition from
> normal
> to iconic state by third-party apps. Then the iconbox can handle the
> animation
> itself.
>

Perhaps "Icon Hijacking" mechanism ? When Window Manager iconizes app
and maps its Icon - Iconbox comes into play and "steals" the icon from WM -
reparents it into its own window. It is kinda implemented in most
swallowing
apps, like Wharf etc. But some special communications are needed in order
for
WindowManager to keep such iconized window in the list of clients.
Currently
if you swallow an icon - WM considers this app to be withdrawn and removes
it
from the list of client.


Cheers
Sasha Vasko