Keeping things moving...

[Paul Warren <pdw ferret lmh ox ac uk>]

Hi,

I've been mainly lurking on this list since the beginning - good to see a
bit of action once again.  As Havoc has pointed out I think we need to
keep this spec developing in a purposeful direction with a view to
finalising it soon. I hope I am not treading on anybody's toes trying to
give the discussion a bit more direction.  I will try to summarise what
has been discussed recently, trying to reach some form of
conclusion/direction for each point. Perhaps we can discuss them for a few
days, and then I'll repost with some form of status report.

This email goes on for a bit, but I have broken it up into sections.  I
suggest that replies to this email should be restricted to one section per
email, with the subject set to the title of the section.  If you want to
reply to more than one section, please do so in separate emails.

-------------------------------------------------------------------------
_NET_WM_LAYER
-------------------------------------------------------------------------
This seems to have been a controversial point, but I think pretty much
everyone actually wants the same thing.  A window sets this hint to
indicate what *type* of window it is.  It is then up to the WM to decide
the stacking order on the screen.  For example, if a window sets
_NET_WIN_LAYER_ONTOP, it is a matter of WM policy to decide whether it
gets placed above or below windows on the dock layer.

* A window sets what layer it belongs to * The WM sets what order the
layers get stacked in *

Does anybody disagree with that?  

The spec currently offers: DESKTOP,BELOW,NORMAL,ONTOP,DOCK,ABOVE_DOCK,MENU

The "ABOVE_DOCK" layer does seem to indicate some physical stacking order,
right?  I guess a WM could still choose to but an ABOVE_DOCK window below
the panel, if it really wanted.

Is ONTOP, ABOVE_DOCK and MENU too much?  Would anybody like to argue for
or against scrapping ABOVE_DOCK?

-------------------------------------------------------------------------
Avoiding docks & autohide windows
-------------------------------------------------------------------------
Matthias has explained more clearly the _NET_WM_STRUT idea.  I get the
impression that most people, after fully understanding how it works,
approve of this, yes?  The only problem being that it might not be
sufficient to deal with autohide windows (see below).

Nobody seems to have a better name for it.  I personally think that STRUT
is OK.

A STRUT indicates how far into the edge of a screen a dock-type window
impinges, to allow maximised window to avoid it.  An auto-hide dock would
set this to its minimised size, so that windows can still be placed behind
it.

Whether a WM resizes windows when a (non-auto-hide) dock size changes is a
matter of WM policy, but these hints are sufficient for it to do so if it
wishes.

The WM should maintain a max workarea rect, calculated from the struts
from all windows.  Matthias suggested _NET_WM_MAX_WINDOW_RECT.  Spec 1.9b
already has _NET_WORKAREA for (AFAIK) exactly this purpose.  Choose a
name, people - I'm unclear on the distinction between _NET_WM_* and
_NET_*.  Either way, I think that a separate workarea needs to be
maintained for each desktop, as per 1.9b.

Minor point:
A corner panel, on eg. the bottom edge of the screen, should set the
bottom STRUT, but not the LEFT or RIGHT struts, I think.  

Auto hide windows:
It has been suggested that more support is needed for autohide windows,
specifically the ability to hide / unhide windows that are obscured by
other windows.  Dominic has proposed a mechanism for this, using
_NET_WM_WINDOW_HIDDEN/REVEALED, whereby a hidden window can request an
invisible "input area" which it gets notification of the mouse entering.

One advantage of this is that it would allow an auto-hide panel to be
completely hidden (an extra pixel for maxmised windows ;-).  

Dominic points out two problems:

1. It interferes with workspace flipping.  But auto-hide panels do that by
definition.  A user who wants workspace flipping and auto-hide panels
simultaneously is asking for trouble.

2. If implemented as an on-top invisible input only window then
enter_notify events for other windows would be missed, a problem for
sloppy focusers.  Can anyone offer a solution to this one?  Surely it is
only a problem if the window doesn't immediately raise itself and destroy
this invisible area?

What do people feel about this proposal?  (Dominic describes it fully in
his post on 27 Oct, Re: layer and strut hints are unnecessary.)

-------------------------------------------------------------------------
_NET_ACTIVE_CLIENT_WINDOW client message
-------------------------------------------------------------------------
As I understand it, this is what a eg. a tasklist app sends to say "the
user wants to work with this window".  Dominic has proposed degrees of
activation (see http://gnome.windsofstorm.net/wmhints/x321.html).  I
suggest that these go into the draft, having scrapped
_NET_ACTIVATE_FOCUS_AND_WARP.  Any objections?

-------------------------------------------------------------------------
_NET_NUMBER_OF_DESKTOPS _NET_DESKTOP_GEOMETRY
-------------------------------------------------------------------------
There was a suggestion that clients should not be able to change the
number of desktops/geometry - what happens to windows on deleted
desktops?  

1.9b suggests that a client can either change the number of desktops by
sending a _NET_NUMBER_OF_DESKTOPS message OR by sending
_NET_(INSERT/DELETE)_DESKTOP messages, to append/insert or delete a
specific desktop.  

I think we need to define the difference between these two types of
message, and if we can't, scrap one of them.  Perhaps we could scrap the
former?  I think that what happens to windows on deleted desktops is a
matter of WM policy, and is up to the WM to decide should it decide to
honour one of the above requests.  I suggest that a valid policy would be
to ignore it if there are any windows on the specified desktop.

-------------------------------------------------------------------------
_NET_SIZEMOVE_NOTIFY
-------------------------------------------------------------------------
This is here to allow apps to perform semi-opaque resizing (in the name or
speed), and only fully draw the window once its size has been finalised.

Matthias has suggested that this be scrapped, claiming that apps can be
better written to deal with opaque resizing.  I suggest that we should
scrap it, because apps that use this will make a really half-hearted
attempt at opaque resizing eg. just blank the window to grey for the
duration of the resize, missing the point of opaque resize?

Would anyone like to defend this one, or should it get the chop?

-------------------------------------------------------------------------
_NET_WM_STATE and _NET_WM_HINTS
-------------------------------------------------------------------------
1.9b complains that these are not extensible.  Can anyone suggest a better
solution, or do we just live with it?

-------------------------------------------------------------------------
MWM hints
-------------------------------------------------------------------------
I don't know what to say on this one.  Do we replace them entirely?

-------------------------------------------------------------------------

Hopefully this should give us something to talk about in moving towards a
final draft.  If anyone has anything that I have missed, perhaps they
could start up a separate thread for discussion on the list.

cheers,

Paul