Re: WIP: wm-spec 1.9b

[Marko Macek <Marko Macek gmx net>]

Tim Janik wrote:
> On Sun, 22 Aug 1999, Marko Macek wrote:

> this definitely needs to be an array of two cardinals for all dsktops
> present. if a pager is only supplied with information about the viewport
> of the current desktop, it cannot provide correct thumbnails of the
> non-visible desktops. it'd be sufficient for _NET_DESKTOP_VIEWPORT to

Agreed. 

> be a readonly property, if we introduce a _NET_DESKTOP_CURRENT_VIEWPORT
> client message that the pager can use to change the viewport for the
> current desktop (i doubt that there'd be any use for applications to
> change the viewport for desktops other than the current):
> 
> _NET_DESKTOP_VIEWPORT x,y, CARDINAL[][2]/32
> 
> Readonly property set by WM upon viewport changes within any of the
> desktops it provides. Contains two Cardinals per desktop (x,y) that define
> the toplevel corner of their current views (the first (x,y)-pair identifies
> the coordinates for desktop 1, the second (x,y)-pair for desktop 2 and so
> on). For window managers that don't support paged desktops, this is always
> an array of (0,0) pairs.
> 
> _NET_DESKTOP_CURRENT_VIEWPORT x,y CARDINAL[2]/32
> 
> If a client wants to change the current desktop's viewport, it can send a
> _NET_DESKTOP_CURRENT_VIEWPORT client message to the root window (type
> _NET_DESKTOP_CURRENT_VIEWPORT, format 32, l[0]=<new x>, l[1]=<new y> ).
> The viewport change will be reflected in a _NET_DESKTOP_VIEWPORT update
> by the window manager.

I'd prefer to add l[2] = desktop (0 = current, 1,2,3 = desktop nr.)

> > _NET_CURRENT_DESKTOP <desktop>, CARDINAL[1]/32
> >
> > The index of the current desktop, starts with desktop 1. If a client
> > wants to switch to another virtual desktop, it can send a
> > _NET_CURRENT_DESKTOP client message to the root window (type
> > _NET_CURRENT_DESKTOP, format 32, l[0]=<new index> )
> >
> > _NET_DESKTOP_NAMES
> >
> > The names of all virtual desktops. Text Property. Can be changed by
> > anyone (by pager for example, when renaming desktops).
> >
> > [[Should WM update this when modifying desktop count?]]
> 
> definitely, i think the window manager should even double check client
> changes to this property and ensure that it always contains as many
> names as are desktops present.

Agreed.
 
> > _NET_WM_MOVERESIZE
> >
> > When application wishes to initiate window resizing it must send
> > a message to the root window:
> >
> >    window = target app window
> >    message_type = _NET_WM_MOVERESIZE
> >    format = 32
> >    data.s[0] = x_root
> >    data.s[1] = y_root
> >    data.s[2] = direction:
> >
> > #define _NET_WM_MOVERESIZE_DIRECTION_TOPLEFT 0 /* towards the top-left
> > */
> > #define _NET_WM_MOVERESIZE_DIRECTION_TOP 1 /* towards the top */
> > #define _NET_WM_MOVERESIZE_DIRECTION_TOPRRIGHT 2 /* towards the
> > top-right */
> > #define _NET_WM_MOVERESIZE_DIRECTION_RIGHT 3 /* towards the right */
> > #define _NET_WM_MOVERESIZE_DIRECTION_BOTTOMRIGHT 4 /* towards the
> > bottom-right*/
> > #define _NET_WM_MOVERESIZE_DIRECTION_BOTTOM 5 /* towards the bottom */
> > #define _NET_WM_MOVERESIZE_DIRECTION_BOTTOMLEFT 6 /* towards the
> > bottom-left */
> > #define _NET_WM_MOVERESIZE_DIRECTION_LEFT 7 /* towards the left */
> > #define _NET_WM_MOVERESIZE_DIRECTION_MOVE 8 /* only movement */
> 
> how is that different from plain usage of XMoveResizeWindow() which
> will be caught by the window manager anyways? and what is the direction
> meant for if x_root and y_root are specfied anyways?

This message starts interactive WM resize/move code. The x_root and
y_root are 
mouse coordinated where window should be grabbed.
 
> > _NET_WM_DESKTOP <desktop>, CARDINAL[1]/32
> >
> > Cardinal to determine the desktop the window is in (or wants to be),
> > starting with 1 for the first desktop. 0 indicates that the window is
> > withdrawn and the window manager is free to place it. 0xFFFFFFFF
> > indicates
> > that window appears on all desktops/workspaces.
> 
> how is 0xFFFFFFFF here different from sticky/fixed position?
> i think it is messy to intermix an index number with a flag value,
> especially since i don't see the point here.

It has the advantage that you can check only this propery and see if the
window should appear on all desktops or just a single one. It seems a
lot 
cleaner to me.
 
> > _NET_WM_SIZEMOVE_NOTIFY
> >
> > If this protocol is selected, the window will receive
> > _NET_WM_SIZEMOVE_BEGIN and _NET_WM_SIZEMOVE_END client messages when the
> > window manager starts or ends resizing in opaque mode.
> >
> >   Rationale: This allows slow applications to use a faster resizing
> >   method until they finally receive the _NET_WM_SIZEMOVE_EXIT hint.
> 
> so we got _NET_WM_SIZEMOVE_NOTIFY, _NET_WM_SIZEMOVE_BEGIN,
> _NET_WM_SIZEMOVE_END and _NET_WM_SIZEMOVE_EXIT client messages?
> what about:

Oops, some mistakes here...

_NET_WM_SIZEMOVE_NOTIFY is a property set by client that requests
the _NET_WM_SIZEMOVE_BEGIN and _END events being sent whenever window is
being opaquely moved/resized. _NET_WM_SIZEMOVE_EXIT should be _END
instead.
 
> windows that embed overlay video will want to update the overlay
> area during plain moves as well.

You mean during opaque moves? They can check configure notify events.

Mark
-- 
... GUI: WPS.
------------------------------------------------------------------------
Marko.Macek@gmx.net                 http://www.kiss.uni-lj.si/~k4fr0235/