Re: WIP: wm-spec 1.9b

[Dominik Vogt <dominik vogt fvwm org>]

On Sun, Aug 22, 1999 at 06:55:00PM +0200, Marko Macek wrote:
>         _NET* window manager hints,protocols... proposal draft 1.9b
>         -----------------------------------------------------------
> 
> Several people mentioned that this specification allows applications to
> do 
> lots of weird things that user might not want. I agree with most of
> them. 
> 
> We should probably include  a policy statement saying that applications
> are allowed to do things like changing states, ... only as a direct
> consequence of the user action.. The application must not use these
> hints to enforce things the way it wants them if the user thinks
> differently. 

Yes! And furthermore this should be explicitly stated in the critical
parts of the spec.

> If we design a WM spec thinking just about misuse of certain hints, we
> will get nowhere.

*But* if we recognize possible misuses we can at least explicitly state
them in the spec.

> IMO, if applications misuse parts of this spec, it
> will annoy the users and cause them to switch to another app.

No, from my experience users rather change the window manager than
their applications. E.g. between how many web browsers can you choose
on UNIX if you need one that has a fairly decent Java implementation?

> An array of all X Windows managed by the window manager.
> 
> _NET_CLIENT_LIST has mapping order

What should this be good for? Why should some application need to
know the internal order of windows in the WM? Isn't the stacking
order enough?

> _NET_CLIENT_LIST_STACKING has stacking order
>
> [[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)?

Hm, I don't think we need this. This just makes the code on client
and WM side more complicated. And what would be the use model behind
this? Are we trying to provide a 'remote' window managing interface?

> It would be nice to have a query for managed windows in Z-order, for
> external implementation of Alt-Tab]]

If an application wants to know the Z order it can query the X server
and ignore non-managed windows. No need to ask the WM. (And it would
make the client to prone to internal bugs in the stacking order of
the WM).

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

But when multiple clients start doing this to make themselves visible
this may lead to a race condition. 

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

It's not obvious to me if the desktop view or the desk of the window
will be changed here. This needs to be clearer.

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

Wow, what will happen if you have multiple pagers and one
changes the names? I don't see why the WM should be involved
in naming desktops. Since the WM doesn't need the information
itself, why should this be in the scope of a WM spec?

> _NET_WORKAREA CARDINAL[][4]/32
> 
> Readonly property set by WM upon calculating the work area for each
> desktop. (the first quadruple = desktop 1, etc).
> 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.
> 
> Work area refers to current page minus space occupied by panels, docks
> etc.  The purpose is to ensure that maximised applications do not cover
> panels, and so that desktop icons don't get put under panels. 
> 
> [[IMHO having different work areas on different desktops is messy,
> although flexible]].

If the hint gives you the size of the desktop, why is it called
...WORKAREA? And what do you mean with 'the first quadruple' when
there are only four values? Am I missing something?

> _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.
> [[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 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.
> 
> [[Some adjustments for DOCK might be necessary when _NET_WM_STRUT is
> finalized]]

Why, why, why??? All I hear about layers are complaints. If you want
a window that is on top, ask the WM to do so. If you have a temporary
menu you can make it override-redirect. If you have tear of menu and
put it on the MENU layer your users will hate you. Or let's take the
DOCK layer. Can anybody explain to me the gain in usability if a panel
or taskbar or whatever refuses to be lowered under normal windows?
Isn't is much more convenient if it can be raised/lowered normally
and simply asks to be raised whenever the user activates is? And I'm
sure that application writers will get the notion that it would be
a good idea to place transients on a higher layer than their 'parents'.

They *only* situation where I recognize the value of layers is
when the user *really knows* the layer concept and explicitly
asks an application to use a certain layer. No application is
allowed a 'program specified' layer hint, i.e. *all* applications
(including taskbars and panels) start on the NORMAL layer unless
the user modified their configuration.

...

Well, even if you disagree totally with the last two paragraphs,
please consider the following very carefully:

At the fvwm-workers mailing list we have spent several months know
trying to implement stacking order code that is able to handle the
current GNOME layer hints, transient and override redirect windows
properly. Perhaps you know fvwm's philosophy that states that we
try to provide the user with every option he asks for, and especially
we try to make it work with any application, regardless of how badly
broken it is. Just an example: KFM uses 'override redirect' for its
icons. If you restart fvwm while KFM is running, all these icons
end up atop all other fvwm windows. But we don't tell the users
"sorry, KFM is very broken, just use a different file manager", but
we are working on a hack that alleviates the problem.

With this is mind now look at the complexity of the stacking order
code. At the moment it must handle (but doesn't):

 1) Layer hints to the WM given in the WM config file.
 2) Layer hints set by the application.
 3) Layer hints set by the user in the application's config.
 4) Broken override redirect windows (like KFM's).
 5) Transient windows.
 6) Transients of transients of transients of ...
 7) Transients on a different layer than the 'parent'.
 8) Layer hints changing while a window is mapped.
 9) Raising or lowering windows that are or are not obscured by
    others (th Z order provided by X doesn't help much here).

And in the future:

 10) Applications requesting to be raised or lowered.
 
Okay, this looks simple at first. But let's take an application with
a transient window that maps the transient on a higher layer (5, 7).
Now it requests to change its own layer (8). The user already asked
the application to map of layer x (1). To make it even worse the
transient has its own transient. Don't laugh. That is really no
unusual setup. With netscape you can have transients of transients.
GNOME panel changes its layer at run time and it does create popup
menus.

It's *extremely* difficult to code (you won't believe it until you
tried to code it yourself). If you don't believe me, try to answer
this question:

  If you have an application window A on layer x with a transient
  B on layer y (both specified in the WM configuration). Now A changes
  its layer to x+3. Where should windows A and B end up?

  Some suggestions:

   - both on layer x+3?
   - A on x+3 and B on y?
   - A on x+3 and B on y+3?
   - A on x and B on x?
   - A on x and B on y?
   ...

So to make the layer hints manageable at all (if I can't convince
anybody that the whole idea isn't good) it suggest the following
severe restrictions for layer hints:

 1) Transient windows *must not* set layer hints. If they do the
    WM must ignore them. Instead the WM uses the layer hint of
    of the 'parent' (recursively if necessary).
 2) Applications may only change their layer while in withdrawn
    state.
 3) The WM always places transients on the same layer as the
    'parent'.

> _NET_WM_HINTS CARDINAL/32
> Additional hints for the window manager or tools like panels or
> taskbars.
> Possible values:
> 
> #define _NET_WM_HINTS_SKIP_FOCUS (1<<0) /* "alt-tab" skips this win */
> #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 */
> #define _NET_WM_HINTS_NO_AUTO_FOCUS (1<<3) /* do not automatically put
> focus on this window when it pops up */
> #define _NET_WM_HINTS_STANDALONE_MENUBAR  (1<<4) /* this window is a
> standalone menubar */
> #define _NET_WM_HINTS_IGNORE_ARRANGE  (1<<5) /* this window has a fixed
> position (should be excluded from desktop uncluttering etc.) */
> #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)*/

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

Yes, remove this. If a transient wants to move with its 'parent'
this can already be handled by the application with the hints in
this spec. Otherwise, leave the decision to the WM policy.

> 
> 6. File Manager desktop
> -----------------------
> 
> This spec suggests implementing the file manager desktop by mapping a
> desktop-sized window (no shape) to all desktops with Layer=Desktop. 
> This makes the desktop focusable and greatly simplifies implementation 
> of the file manager. It is also faster than managing lots of small
> shaped 
> windows. The file manager draws the background on this window. There
> should be a  root property with a window handle for use in applications
> that want to draw the background (xearth).

I'm concerned that this model won't work.

 - What is focusing the desktop good for? The only thing that would happen
   is that WM keyboard shortcuts don't work anymore.
 - What about applications that can work with the root window background
   now? They would *all* have to be modified plus they would have to
   distinguish between a FM free desktop and one with a running desktop.
 - What about apps with 'transparent' background?
 - Why is this supposed to be faster? I guess the shortcuts will still be
   implemented as subwindows of the faked root window. Otherwise the
   background would have to be redrawn frequently.
 - Multiple file managers will obscure each other! Being unable to run
   more than one FM at once seems to be a silly restriction to me (and
   confusing for the user).

I suggest this:

 - a shortcut window is a simple shaped, borderless window that is
   managed by the WM. And -hey- here's something useful for the
   layer hint. An additional hint is set that informs the WM that
   the window wants to be handled the way the WM treats shortcuts.

> 7. Implementing enhanced support for application-modal dialogs in the
> WM.
> -------------------------------------------------------------------------
> 
> If the WM_TRANSIENT_FOR property is set to None or Root window, the
> window
> should stay above all other windows in the same group.

Uh, and how would one find out the group if the window doesn't give
a hint about the group leader? And what about multiple windows in
the same group that use this hint?

> [[ should the same happen if the group leader is not managed? ]]

This would imply that you frequently poll the window list from the
X server. Otherwise how would you know if the unmanaged window
exists or not?

> 2. We must include an KWM_WIN_ICON equivalent for setting small icons. 
> (16x16 icon)

> (This assumes that we allow minor ICCCM violation for 
> specifying colored large icons the ICCCM way (ICCCM allows only 1-bit)).
> (IMO ICCCM needs to be updated to allow root-window depth icons,
> everyone
> does it anyway).

Yes, I agree. But I guess since the X Consortium shut down operation
that the ICCCM is unmaintained now. Correct?


-------------- general remarks --------------

I'm still unhappy with the way the spec draft allows clients to take
control over the window manager. There are very dangerous hints like
_NET_DESKTOP_VIEWPORT/DESKTOP, _NET_WM_LAYER, _NET_WM_MOVERESIZE and
so on. I guess most of us already have come into contact with those
messy Java applications that maximize and respawn windows. What will
prevent them from closing or moving other applications? It's *so*
easy with this draft.

If this kind of control is really required I strongly suggest that
the hints providing WM functionality are grouped together and get
a name that makes it clear that they are used by desktop and WM
components only.

Bye

Dominik ^_^

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