Re: Work in Progress: draft 1.9a

[Marko Macek <Marko Macek gmx net>]

Resending to the list...

Dominik Vogt wrote:
> 
> 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.

Thanks. I will change should->must.
 
> > _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.

Retrieving the list with XQueryTree is not very simple considering that
different WM implementations are possible.
 
> > _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?

I guess they should be moved to the new current desktop.
 
> > _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?

Obviously, there is no sense for a normal application to use these and
should be discouraged.
 
> > _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.

(Personally - definatelly not warped :) )

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

Do you have a suggestion for meaningful degrees of activation? 

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

Work area doesn't include the taskbar/panel/dock/... People do not want
to maximize over them.
 
> > 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.

Not necessary IMO. XKillClient should only be used on windows that do
not support WM_DELETE_WINDOW. Using it on windows that support WM_DELETE
WINDOW is a really bad idea unless the user directly requests it. 

(Personally I think it is VERY dangerous to have Destroy without
confirmation in the menu nearby Close. It's just too easy to hit the
wrong one).
 
> > _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

Obviosly applications should only resize themselves.

> 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

I really dislike this too.

> should really be handled by the WM somehow.

This message is intended for that. The app sends it whenever it wants to
resize/move and the WM will take over.

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

The app only writes before mapping the window. Afterwards it must send
client-messages and the WM will update the property. This allows the WM
to have more control.

The WM could move all the dialogs when the main app window changes
desktop, for example.
 
> > 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?

We probably don't need this. Not setting the property is the same thing. 

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

It is intentional because they are strongly related.
 
> > 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).

Obviously.

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

It will not. XGrabKey still works.
 
> > [[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

The Dock layer might go away when NET_WM_STRUT is finalized...

We do need:
- DESKTOP,
- NORMAL
- ONTOP and for completeness BELOW.


MENU might be useful to WMaker/AfterStep/...
 
> >
> > [[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.

OK. (Fvwm has seriously confused some people with
desktop/desk/page/sticky...)

icewm uses the term Workspace and Occupy All (just like CDE).
 
> > #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

It does.

> 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

The app should only send the bits it wants to change. (<mask>). Also:
mask=0xFFFFFFFF state=0 should restore the window to normal state.

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

It should, no?

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

It should stay on the current desktop. Hmm, perhaps the omnipresent
could be some reserved number in NET_WM_DESKTOP. Matthias?

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

omnipresent is togglable by the user in most current WMs, no?
Also, the app should really have an option not to set this.

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

Obviously.

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

The app should not do this. 
 
> 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.

This will only cause the applications to map/unmap themselves when they
want to change some hints. Java does this for MWM hints (because some
WMs apparently don't update them on-the-fly) and it is VERY annoying to
have the window blink.

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

No. It should probably be renamed to _IGNORE_ARRANGE.
 
> > #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?

That too. I added this because mozilla would like to have it. See my
recent email. We should ask them exactly what they would like to have.

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

With the <mask> argument above.

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

This makes sense. Matthias? I didn't plan to implement any of this
animation stuff in icewm anyway.

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

Current desktop environments (GNOME/KDE) have filemanager icons on the
desktop. There are no icons for app windows.
 
> 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':

Do you mean file manager icons by "shorcuts". IMO the only reasonable
implementation is to keep a file manager window at the bottom of the
Zorder (layer=DESKTOP). The current GNOME implementation where every
icon is a managed window is very messy and doesn't work well. The
desktop should behave exactly like a file manager window (with no menus,
toolbars, ... scrollbars should be there if necessary).
 
> 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.

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