Re: WIP: wm-spec 1.9b

[Michael ROGERS <M Rogers cs ucl ac uk>]

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

Don't forget that many users will not realise where the problem lies if, for
example, one application maps its transients in the ABOVE layer while another
maps its transients in the NORMAL layer. The user will just see that the
windows behave unpredictably, and conclude that X/Gnome/KDE is difficult to
use. If we introduce a complex set of hints we *will* get a complex set of
behaviours, and the overall effect will be to make KDE/Gnome look patchy and
inconsistent.

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

I think the current draft definitely describes a remote window managing
interface. Surely CORBA is the right way to do this? If we have to leave the
CORBA interface definition until later, so be it. I don't think we should try
to hack together a solution using X hints just to get the spec finished on
time.

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

I think there is a case for layers if, eg, desktop shortcuts are going to be
managed by the WM - you don't want them to be raised above "normal" windows.
Similarly there are some permanent desktop features (such as the panel or the
clock) which you might like to have "stuck to the desktop" or "stuck to the
screen". I think we should try to keep the layers implementation as simple as 
possible, however, so I suggest this:

BOTTOM: The window is a desktop feature (eg shortcuts, Bonobo/Active Desktop
component thingies). Permanent features like the Gnome panel might also use
this layer.

NORMAL: All "application" windows (top-level, transient, toolbars etc.)

TOP: The window should obscure everything and generally get in the way.  ;) 
Pinned menus and permanent features like the Gnome panel might use this layer.

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

It's good for, eg, typing on the desktop to launch applications. It also
shifts the root-window-click-proxying burden from the WM to the file manager;
the file manager makes desktop clicks available to the WM, not the other way
round.

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

Ack. Good point. Mind you, there must be some code in Eterm to handle E's
multiple virtual root windows. Anyone know how it's done?

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

Even if the shortcuts are implemented as shaped windows, they will not have WM
parents which need to be shaped, so this will cut the number of shaped windows 
in half.

> - 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 think any user who wants to run more than one file manager (each with its
own desktop shortcuts and probably its own root menus) is pretty confused
already.:)  Do you really run two file managers at once? Why?

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

I suggest that we move this functionality into a CORBA interface. But then you
already knew that.  :)


Michael Rogers