Re: Work in Progress: draft 1.9a

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

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

This is an example of the mess created by allowing applications to perform
window manager fuctions.

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

Yes. If we have to have pager compliance in the main specification, let's
make sure the pager hints are distinct from the hints used by normal
applications.

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

Messy. It would be much simpler to use the WM's own pager if this kind of
configurability is required.

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

Again, this is messy, since all the details of the window manager's
functionality cannot be exported. The problem is pager compliance.

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

Isn't that the purpose of this part of the spec? To allow an application to
provide its own move/resize handles, while using the wm's move/resize
behaviour?

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

I don't understand why - can you give an example of this?

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

I agree - there should be as few layers as possible, to allow the user
maximum control. I think desktop, below, normal and above are enough.

>> [[Some adjustments for DOCK might be necessary when _NET_WM_STRUT is
>> finalized]]

(ie, it won't be needed)

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

Good idea. Let's make this spec a bit less obscure than the last one!

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

I agree - this sort of thing is up to the window manager. Why should an app
want to shade itself anyway, and what will happen if the window manager
doesn't support shaded windows?

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

I would go further and say that the application should not request any state
beyond visible/iconified/hidden. The rest is up to the user.

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

The pain is caused by pager compliance. In the time we have spent and will 
spend trying to bend our window managers to fit the Gnome pager, we could all 
have implemented pagers in our own window managers, without this mess of 
hints!

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

I like this idea. It leaves the specific interpretation up to the user, while
allowing the programmer to assume that a reasonable default behaviour is
being used. If we could combine this with the list of supported features,
the programmer could check that a class of decoration/behaviour was
supported before using it.

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

I agree. The handling of icons is already covered by the ICCCM, and the icon
geometry is set by the window manager, not the application, to give a
consistent appearance.

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

I think you're creating mess by trying to split an application where there 
isn't a functional line. If the desktop environment is going to create hordes 
of icons, it should manage them itself. The model for desktop icons used by 
Gnome (I don't know about KDE) is that the desktop is like a file manager 
window. In that case, desktop icons should obviously be handled by the file
manager. Unfortunately, X already has a concept of icons as miniaturised 
applications, so there is a conflict. 

The radical solution is to say screw Windows 95, we will use X-style icons and
find another way of displaying shortcuts (the Gnome panel has launchers, for
example). I like this solution but I can't see the people who want to ease
the transition from Windows to Gnome adopting it.

The other solution is to say that the window manager should give up control
of the desktop to the desktop environment. The window manager must find
another way of displaying "iconified" applications (a menu, for example).
This solution suits me too (I prefer menus to icons), but I can't see
existing window managers adopting it.


Michael Rogers