Re: Work in Progress: draft 1.9a

[Dominik Vogt <dominik vogt fvwm org>]

On Sun, Jul 04, 1999 at 11:20:18AM +0200, Marko Macek wrote:
> When sending ClientMessages, all unused fields should be set to 0.
                                                 ^^^^^^
Why 'should' they be set to 0? A simple 'must' will spare us a 
lot of trouble. At least in German, the translation of 'should'
does not mean 'you are storngly advised to' but 'you may or may not'.
Making this clear won't hurt.

> _NET_CLIENT_LIST, XA_WINDOW[]/32
> 
> An array of all X Windows managed by the window manager.
> 
> [[This is simple. Does anyone feel we need a faster mechanism based  on
> incremental updates? (based selection query + ADD/REMOVE updates, we
> must  be careful about race conditions if we do this)?
> It would be nice to have a query for managed windows in Z-order, for
> external implementation of Alt-Tab]]

What would that list be used for in comparison to the list retrieved
by XQueryTree? All windows except override redirect windows are
managed by the WM.

> _NET_NUMBER_OF_DESKTOPS <#desktops>, CARDINAL/32
> 
> The number of virtual desktops. If a client wants to change the number
> of desktops, it can send a _NET_NUMBER_OF_DESKTOPS client message to
> the root window (type _NET_NUMBER_OF_DESKTOPS, format 32, l[0]=<new
> number>) If the clients wants to delete/insert a certain desktop, it
> should send _NET_{INSERT/DELETE}_DESKTOP to the root window (l[0] =
  ^^^^^^
must?

> desktop to insert/delete, (insert must also work for appending one
> desktop).

What will happen to windows on a desktop that is deleted?

> _NET_DESKTOP_GEOMETRY width,height, CARDINAL[2]/32
> 
> Array of two Cardinals that defines the width and height of each
> desktop in pixel. If a client wants to change the desktop geometry, it
> can send a _NET_DESKTOP_GEOMETRY client message to the root window
> (type _NET_DESKTOP_GEOMETRY, format 32, l[0]=<new width>, l[1]=<new
> height>).
> 
> _NET_DESKTOP_VIEWPORT x,y, CARDINAL[2]/32
> 
> Array of two Cardinals that defines the toplevel corner of the current
> view. For window managers that don't support paged desktops, this is
> always (0,0). If a client wants to change the desktop viewport, it can
> send a _NET_DESKTOP_VIEWPORT client message to the root window (type
> _NET_DESKTOP_VIEWPORT, format 32, l[0]=<new x>, l[1]=<new y> ). 
>
> _NET_CURRENT_DESKTOP <desktop>, CARDINAL[1]/32
> 
> The index of the current desktop, starts with desktop 1. If a client
                                                       ^^^
Why not start with 0? Any special reason?
> 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?]
> [What does this mean with respect to Unicode if anything?]

I think it is very dangerous to encourage *every* application to use
these hints (_NET_DESKTOP_GEOMETRY to _NET_DESKTOP_NAMES). I would be
mouch more comfortable if we define that these hints are reserved for
use by pagers only. Perhaps a pager should even be forced to register
as a pager by setting a _NET_IS_PAGER_APPLICATION hint?

> _NET_ACTIVE_WINDOW, WINDOW/32
> 
> The window handle of the currently active window. This is a read-only
> property set by the window manager. If a client (for example a
> taskbar) wants to activate another window, it can send a
> _NET_ACTIVE_WINDOW client message request to the root window (window
> is the respective window, type _NET_ACTIVE_WINDOW, format 32,
> l[0]=0 /*may be used later*/ )
> 
>   Rationale: XSetInputFocus is not sufficient, since the window may be
>   hidden on another virtual desktop ( in that case XSetInputFocus
>   fails with a BadWindow error )

Imagine the user wants this: When a button on the task bar is pressed
he want's that the window is mad fully visible (i.e. the desk and
viewport are switched, the window is raised, unshaded and de-iconified)
and the pointer is warped into the window and the window is focused.
But when the pointer simply enters the button the application window is
only raised and focused.

I don't think this can be handled by this hint alone. The hint could
have a parameter to indicate the degree of activation. Note that the
details of what is done should be configured inside the WM because
the user might have a keyboard shortcut that does something similar
in the WM already.

> _NET_WORKAREA CARDINAL[][4]/32
> 
> Readonly property set by WM upon calculating the work area for each
> desktop.
> Contains the left,right,top,bottom coordinates for each desktop.
> Work area is used for maximizing windows and by the desktop to place
> desktop icons appropriatelly.

What is a 'work area' in comparison to the viewport?

> 2. Other Root Window Messages
> -----------------------------
> 
> _NET_CLOSE_WINDOW
> 
> Clients that wish to close another client ( typical examples are
> pagers or taskbars ), shall send a _NET_CLOSE_WINDOW client message
> request to the root window (window is the respective window that shall
> be closed, type _NET_ACTIVE_WINDOW, format 32, l[0]=0 /*may be used
> later*/ )
> 
>   Rationale: A window manager might be more clever than the usual
>   method (send WM_DELETE message if the protocol is selected,
>   XKillClient otherwise). It might introduce a timeout, for example.
>   Instead of duplicating the close code, the WM can easily do the job.

Fvwm allows to chose between different methods of removing other clients:

 'Delete' requests that the application removes the window itself
 'Close' tries a 'Delete' first and if that fails it uses XKillClient
 'Destroy' always uses XKillClient.

It would be a good thing to have this as a parameter.

> _NET_WM_MOVERESIZE
> 
> When application wishes to initiate window resizing it should send
                                                         ^^^^^^
must?
> 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 */

Well, I think we can't just allow applications to resize windows
of other applications (managed by the wm). Applications doing this
would indeed try to do window manager tasks. The application can not
know what decoration the WM has put on the target window and thus
trying to guess what will fit on the screen only leads to trouble.
Same with moving. At present GNOME menu bars move themselves. This
should really be handled by the WM somehow.
 
> 3. Application Window Properties
> --------------------------------
> 
> _NET_PROPERTIES, ATOM[]/32
> 
> Enables only use of listed properties on this window. If this property
> is set, the WM will only handle (XGetWindowProperty) properties listed
> here. This property must be set before any other _NET hints can be
> used. If this property is set, it should also include any ICCCM
                                    ^^^^^^
must? We will add unnecessary complexity with a 'should'.
> client-only (not WM_STATE) hints and MOTIF hints that are set by the
> client. If WM_PROTOCOLS is not listed here, the WM is safe to assume
> that it contains exactly WM_DELETE_WINDOW.


> _NET_WM_DESKTOP <desktop>, CARDINAL[1]/32
> 
> Cardinal to determine the desktop the window is in (or wants to be),

Does this mean the WM *and* the client are allowed to write this?
E.g.: Window is on desk 2. App. requests the window to be unmapped,
WM sets property to 0. App. maps its window again, WM reads the property
(== 0) and places the window on desk 1, now that it may do what it wants!!
This needs to be clarified.

> starting with 1 for the first desktop. 0 indicates that the window is
> withdrawn and the window manager is free to place it. 

Sounds like a re-implementation of the withdrawn state. Why?

> A window manager honors _NET_WM_DESKTOP whenever a withdrawn window
                   ^^^^^^
Or it may choose to never honour it (e.g. if the user asked it to
do so).
> requests to be mapped.  When being in another state (iconified or
> mapped), the client can request a change by sending a _NET_WM_DESKTOP
                                                        ^^^^^^^^^^^^^^^
Is that an intentional name collision? I don't think it's a good idea
to have a client message and a property with the same name.

> client message to the root window. (window is the respective window,
> type _NET_WM_DESKTOP, format 32, l[0]=<desktop>)


> _NET_WM_DECORATION, CARDINAL/32
> 
> How the window's decoration frame should look like. Possible values
> are None, Normal, Tiny, Tool and Menu.
> 
>...
>
> A window manager honors _NET_WM_DECORATION whenever a withdrawn window
                   ^^^^^^
Or it may choose to never honour it (e.g. if the user asked it to
do so).
> requests to be mapped.  When being in another state (iconified or
> mapped), the client can request a change by sending a _NET_WM_DECORATION
> client message to the root window. (window is the respective window,
> type _NET_WM_DECORATION, format 32, l[0]=<decoration>)
> 
>   Rationale: especially DECORATION_NONE is very important. It allows
>   application developers to create borderless windows ( for example
>   taskbars, desktop panels or application specific floating toolbars )
>   without the need of making them override_redirect. This way the
>   window can benefit from the window manager's focus handling, which
>   isn't possible at all with override_redirect windows.

Of course, if these are *hints* the application has to work even if
the WM (i.e. the user) insists to put a border around it.

> [[How should overlaps with MWM hints be handled?]]

Can this happen at all? Will applications that set _NET_ hints use
MWM hints? We can simply define that setting MWM and _NET_ hints at
the same time is illegal.

> _NET_WM_LAYER, CARDINAL/32
> 
> #define _NET_WIN_LAYER_DESKTOP                0
> #define _NET_WIN_LAYER_BELOW                  2
> #define _NET_WIN_LAYER_NORMAL                 4
> #define _NET_WIN_LAYER_ONTOP                  6
> #define _NET_WIN_LAYER_DOCK                   8
> #define _NET_WIN_LAYER_ABOVE_DOCK             10
> #define _NET_WIN_LAYER_MENU                   12
> 
> The intentions are as follows:
> 
> DESKTOP: A single window at the bottom should be a desktop with icons.
> It should have the same dimensions as the screen.

Duh, a 'private' root window will seriously hamper the WMs ability to
manage keyboard shortcuts. 

> [[Even with virtual scrolling desktop?]]
> This allows the desktop environment to have full control of the desktop.
> (With focusing, background handling and no shaped windows).
> 
> NORMAL: the default for all windows
> 
> ONTOP,BELOW: Normal window that should stay on top/below other windows.
> 
> DOCK: Windows docked at the edge of the screen.
> 
> MENU: layer for NextStep/WMaker style menus that stay on top.

This layer architecture limits the user in enforcing their preferences
severely. It is like a hard coded stacking order. E.g. lots of users
simply *hate* that they can't lower their dock/panel/taskbar below other
windows. Anyway, the 

> 
> [[Some adjustments for DOCK might be necessary when _NET_WM_STRUT is
> finalized]]
> 
> _NET_WM_STATE CARDINAL/32
> 
> #define _NET_WM_STATE_STICKY (1<<0) /* the window sticks on the screen
> even when the virtual desktop scrolls */
> #define _NET_WM_STATE_OMNIPRESENT (1<<1) /* the window is visible on all
> virtual desktops */
How about something less esoteric like

 _NET_WM_STATE_FIXED_ON_SCREEN

and

 _NET_WM_STATE_VISIBLE_ON_ALL_DESKTOPS

I know, it's more letters, but you could understand what it means, even
if you're no WM hacker. And it avoids other definitions of the term
'STICKY'. Fvwm for example has a 'sticky' style that essentially means
'omnipresent' and 'sticky' at the same time in above terms.

> #define _NET_WM_STATE_MAXIMIZED_VERT (1<<2)  /* the window is vertically
> maximized */
> #define _NET_WM_STATE_MAXIMIZED_HORZ (1<<3)  /* the window is
> horizontally maximized */
> #define _NET_WM_STATE_SHADED (1<<4)  /* the window is shaded */
> 
> A window manager honors _NET_WM_STATE whenever a withdrawn window
> requests to be mapped.  When being in another state (iconified or
> mapped), the client can request a change by sending a _NET_WM_STATE
                                                        ^^^^^^^^^^^^^
Again a name collision?
> client message to the root window. (window is the respective window,
> type _NET_WM_STATE, format 32, l[0]=<mask>, l[1]=<new values for masked
> bits> )

I don't think it's a good idea to allow applications to control their
state when they are mapped. All these states are tracked by the WM
after the window has been mapped nad the application cannot and should
not know about what the WM is doing. The WM would have to inform the
app of any state changes so that it can set the correct bits when
it sends its next client message. I see a number of problem that
unnecessarily add to the complexity of state handling and make it
very prone to bugs. It will be very hard to write a working application:

 - What will happen if an icon is shaded/maximized? Will it de-iconify?
   THe application can't rely on the state it will have afterwards.
 - ... a maximized window is maximized again and then unmaximized?
   Will it have its original size or the the size of the last maximization?
 - What if the application makes its window 'omnipresent', the user switches
   the desk and the application removes the 'omnipresent'? The window may
   be lost on a different desktop than the other windows of the application.
 - And what if the user doesn't like to have applications that occupy
   *all* desktops. Perhaps he wants desk 5 reserved for something entirely
   different. How can he force the application not to set this hint?
 - 'Maximized' dosn't necessarily mean the window is big. You can tell
   fvwm to make a window as big as possible without overlapping other
   windows. Applications must not rely on any particular size or state
   when they request a change in state.
 - What is the difference between a maximized window and one that has
   been resized by the user? Why should the application care about
   this difference. The application will override the user's choice if
   it explicitly requests maximization when the user 'maximized' it this
   way.

Overall this introduces too many ways for applications to override
WM and user preferences. For the sake of simplicity and managability
the state hints should really be limited to the time when the window
is mapped. An application using this hint for a different purpose
than obeying user preferences (which will always be the case after it
has been mapped) will make things rather difficult and often surprising
for the user.


--
> _NET_WM_HINTS CARDINAL/32
> Additional hints for the window manager or tools like panels or
> taskbars.

I'm quite unhappy with the naming here. Either they are WM hints or not.
If taskbar hints are needed then define them as _NET_TB_..., but not
as _NET_WM_... hints.

> Possible values:
> 
> #define _NET_WM_HINTS_SKIP_FOCUS (1<<0) /* "alt-tab" skips this win */
                                             ^^^^^^^^^

We should really reach a decision if the WM or the DE is responsible for
such keyboard shortcuts first. And why shouldn't the user be allowed to
control this? With all these hints the user would have to tell the WM
to ignore for specific applications, WM configuration will become a major
pain in the ass for users that like to have control over what they get.

> #define _NET_WM_HINTS_SKIP_WINLIST (1<<1)  /* do not show in window list
> */
> #define _NET_WM_HINTS_SKIP_TASKBAR (1<<2) /* do not show on taskbar */

Same as above. These hints are simply a poor excuse for not having a


> #define _NET_WM_HINTS_NO_AUTO_FOCUS (1<<3) /* do not automatically put
> focus on this window when it pops up */

Urk. The *application* is allowed to tell the WM what the focus policy
should look like? Perhaps I'm too pampered by fvwm's flexibility, but
I definitely want to control this myself *without* having to override
all kinds of default behaviour first.

> #define _NET_WM_HINTS_STANDALONE_MENUBAR  (1<<4) /* this window is a
> standalone menubar */

What would the effect of this be?

> #define _NET_WM_HINTS_FIXED_POSITION  (1<<5) /* this window has a fixed
> position (should be excluded from desktop uncluttering etc.) */

Does this include moving?

> #define _NET_WM_HINTS_DO_NOT_COVER (1<<6) /* attempt to never cover up
> this window if possible (placement policy priority hint)*/
> #define _NET_WM_HINTS_LOCK_ZORDER (1<<7) /* window will not be raised
> when clicked even if WM does this for normal windows)*/

What about lowering?

> #define _NET_WM_HINTS_NO_MOVE_WITH_OWNER (1<<8) /* for transient
> windows, will not be moved when owner is moved/sized */

Er, isn't *not* moving the default? Moving transients with the
main window is quite hard to implement anyway. If an applications
wants to move all windows at once then it should not create transients
but subwindows. I would remove this bit.

--
I don't like this approach at all. I would rather define classes
of applications with recommendations how the WM *may* implement
them. This would ensure consistency but would not cost too much
flexibility. Examples:

Class: 'TaskBar'
WM Recommendation: skip focus, skip window list, fixed position,
do not cover, lock zorder

Class: 'MenuBar'
WM Recommendation: skip focus, skip window list, fixed position(?),

Class: 'Panel'
...
Class: 'Pager'
...

You get the idea. We don't allow to ask applications for their
specific decorations either (only the general class like
TINY or NONE). So I suggest this:


  _NET_WM_BEHAVIOUR, CARDINAL/32

  #define _NET_WM_BEHAVIOUR_NORMAL 0
  #define _NET_WM_BEHAVIOUR_TEAR_OFF_MENU 1
  #define _NET_WM_BEHAVIOUR_MENU_BAR 2
  #define _NET_WM_BEHAVIOUR_TASK_BAR 3
  #define _NET_WM_BEHAVIOUR_PANEL 4
  #define _NET_WM_BEHAVIOUR_PAGER 5
  #define _NET_WM_BEHAVIOUR_INFORMATION_WINDOW 6 /* windows that
  passively display information like xosview or a xclock */
  ...

> A window manager honors _NET_WM_HINTS whenever a withdrawn window
> requests to be mapped.  When being in another state (iconified or
> mapped), the client can request a change by sending a _NET_WM_HINTS
> client message to the root window.  (window is the respective window,
> type _NET_WM_HINTS, format 32, l[0]=<mask>, l[1]=<new values for masked
> bits> )

Hm, how can you distinguish between 'I don't care' (bit set to zero) and
'Don't do it' (bit set to zero)?

> _NET_WM_ICON_GEOMETRY
> 
> An array x,y,w,h of type CARDINAL, format 32.  This optional property
> may be set by standalone tools like a taskbar or an iconbox. It
> specifies the geometry of a possible icon in case the window is
> iconified.
> 
>   Rationale: This makes it possible for a window manager to display a
>   nice animation like morphing the window into its icon.

?? Since the window manager already handles icons, what would that hint
tell it? It knows much better what icon it will use and where it will be
placed than any application. Or is the reasoning here that the WM will
not handle icons? If this is the case I wonder why the WM should draw
icon animations at all. If it isn't even allowed to manage icons it is
clearly not the WM's responsibility to draw animations. So if it's
desirable that the taskbar manages all icons it should tell the WM
not to handle icons at all and do the drawing itself, but not misuse
the WM as an 'animation extension'. If a central place for animations
is needed there should be some kind of 'animation server'.


--
In general, what I miss in this draft is a list of properties/hints/protocols
that a compliant window manager *must* obey and what it *should* or *may*
obey. E.g. it was said in the previous discussions that the paging
interface would be constituted of hints, i.e. the user can tell the WM
to ignore all this if he doesn't like it. How would that work if
you used _NET_NUMBER_OF_DESKTOPS to delete/add desktops?

Another thing that isn't addressed are icons. What is the rationale
bbehind the implicit assupmtion that compliant WMs will not manage
icons (because of feature duplication with the desktop environment)?

Rationale for letting the WM do *all* icon management:

Icons are closely linked to their applications and the WM may make
them look similar to their full sized window (e.g. colour of the
window/icon title). Icon management has always been a core
responsibility of the WM and thus many WMs are very sophisticated
when it comes to icon management. Furthermore it is undesirable
that the WM controls mouse bindings on full sized windows while
the desktop environment handles the bindings on icons (because it
is hard to understand/change for the user).

Implementation idea for 'shortcuts':

The desktop environment sets icon hints much like a normal application
would, but it can have any number of icons. There must be a way to
tell the WM to add or remove any particular shortcut. The desktop
environment may provide an icon window or a pixmap. If it provides
a pixmap it leaves decoration the shortcut to the WM (exactly like
it is with icons). The WM communicates the window id of the shortcut
window back to the desktop environment so that it can select mouse
or keyboard events on the shortcut. The WM never selects any mouse
or keyboard events on the shortcut. Perhaps there has to be an
interface to request icons and or shortcuts to be rearranged.
--

Bye

Dominik ^_^

--
Dominik Vogt, dominik.vogt@gmx.de
Reply-To: dominik.vogt@gmx.de