Re: WM Spec Purpose, etc.

[Michael Rogers <m rogers cs ucl ac uk>]

Thanks for summarising our aims. As always I have a couple of comments. 
;)

> Compliance: Compliance to this specification will easily allow information
> to be shared between the desktop interfaces and the window manager. This
> will also define a common set of configuration parameters to allow the
> window manager to be controlled via a control center or configuration
> tool.

I'm not sure about "a common set of configuration parameters" - whatever
solution we arrive at for configuration tools, we need to allow room for
weird window manager features which may be added in the future. Ideally
the interface between the window manager and other applications should not
assume any particular set of features.
 
>    OTOH, a common definition for determining transparency would be a "Good
> Thing". I know WM and E support this (Esetroot and wmsetbg), and it would
> be nice, but it would be nice not to exclude a good old xv -root from
> being at least tolerated.

I think gnome-terminal relies on the background being loaded with imlib...
would ImageMagick be an acceptable portable alternative to xv?

> * Swallowed Apps (dock/wharf/slit/panel/taskbar)
> 
>    A window that can contain "swallowed" apps. This will vary depending on
> the WM, and if none is present, something like the GNOME panel or the KDE
> taskbar can cover for it. Or via the Control Center of the UI, disable
> using the 

If the taskbar can swallow apps, I think it should take precedence - it
reduces screen clutter to have all your decorations along one edge.
 
> * Icons on root window (file managers and applications)
> 
>    Some WMs allow iconized windows. Some don't. This is an important point
> of individualization; if I were to run OLVWM, I would want to have the
> icons you get by default. If I were running blackbox, I wouldn't. There
> should be a method so that whomever controls the root window will display
> icons for other applications. IE, the WM contacting the UI-based FM to put
> an icon on the root window for an iconized app; or the FM contacting the
> WM to put a shortcut to the GNOME website on the root window. Disabling
> all application iconization for the purpose of the file managers seems
> like a "Bad Thing" in my opinion.

IMO file manager icons and application icons should not be mixed - they
mean different things, and are used in different ways (application
icons are used in place of a taskbar, file manager
icons are used for launching new apps). My favourite solution is to do
without desktop/file manager integration entirely, since the panel
provides icons for launching new applications, but failing that I think we
should use something like the NET_STRUT suggestion to set aside an area of
the screen for application icons, where they will not be covered by panels
or file manager icons.
   
>    If the WM is not controlling the root window, then you can either
> disable the WM menus (not a good idea, IMHO), or find a way to communicate
> between them. In my opinion, the WM should accept responsibility of the
> root window and create icons as needed for the File Managers, etc. for
> shortcuts. Then it can control the menus, and you can use the panel or
> kpanel for the UI specific menus.

I agree that the WM should control the root window. If the file manager
wants to create a desktop, it should use a large window in the lowest
layer, not the root window. Mouse clicks not used by the file manager
could be sent to the root window for the use of the window manager.

One thing we should define is which root window mouse clicks the window
manager can expect to receive. I suggest the middle button only (at least
for Gnome). Are there any window managers which need two separate menus
(bearing in mind that Gnome has its own application launching menu)?


Michael Rogers