Re: Keeping things moving...

[Marko Macek <Marko Macek gmx net>]

Paul Warren wrote:
> -------------------------------------------------------------------------
> _NET_WM_LAYER
> -------------------------------------------------------------------------
We need _DESKTOP, _NORMAL, _ONTOP and maybe _BELOW if anyone wants it?
(I can live without it). Layer should be an ATOM. (perhaps a better name
is needed?)

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

>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.
MS uses WORKAREA term, I suggest we use it, because it is short.
_NET_WM_WORKAREA?

I now also like (Rasterman's?) idea of a single NOCOVER hint to
automatically set this for the widndow+frame (client otherwise have
problems getting the frame of the window).

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

Yes

>-----------------
>Auto hide windows:
Interesting, but I think it needs a prototype implementation and testing
(I never use autohide).

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

No. I propose that activation type is an ATOM to be extensible.
 
> -------------------------------------------------------------------------
> _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

There is no _NET_NUMBER_OF_DESKTOPS message if we keep the below two
messages.

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

If the request is not ignored, the windows should be visible after the
desktop is deleted (move to current/new desktop).

It is good enough if we leave this out of first spec and add later (I
will implement it though, just to see if there are any problems).

> _NET_SIZEMOVE_NOTIFY
> Would anyone like to defend this one, or should it get the chop?
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?

I think we need to make them both list of atoms. for _NET_WM_STATE we
need the following messages to change them:

_NET_ADD_STATE, _NET_REMOVE_STATE, _NET_TOGGLE_STATE, _NET_SET_STATE (at
least two atoms need to be changeable at once, say l[0], and l[1]). (one
atom at the time would be enough except for maximize). Initial mapping
is not a problem, because the app can set any number of values).

For _NET_WM_HINTS:
_NET_ADD_HINT, _NET_REMOVE_HINT (one at the time is enough). The app can
set any number before mapping.
 
> -------------------------------------------------------------------------
> MWM hints
> -------------------------------------------------------------------------
> I don't know what to say on this one.  Do we replace them entirely?

At least provide a way to pack them into our combined hint property.
 
Mark
-- 
... GUI: WPS.
------------------------------------------------------------------------
Marko.Macek@gmx.net                 http://www.kiss.uni-lj.si/~k4fr0235/