Re: WM Spec Purpose, etc.

[Nathan Clemons <nathan windsofstorm net>]

On Mon, 12 Jul 1999, Michael Rogers wrote:

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

That's what I'm here for.

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

I meant like for GNOME applications, you have a desktop file which tells
you a bit about the application. Something similar to tell you what the
config tool name is, what the name of the WM binary is, what the name of
the window manager is, perhaps the WM author & email address, maybe some
other things about how it behaves on non-configurable issues.

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

So as long as it load w/ imlib, it works fine? Ok, then anything with xv
would still have a background, but apps would not be able to work
transparently? I just want to make sure while you may loose functionality
if you do it, it can still function as a basic quick measure.

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

This should be user/WM configurable. I have my preference, you have yours,
it should be an option. =)

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

I like the idea of being able to launch applications via shortcuts on the
desktop... it's standard to MacOS, Windows, and it's the way most people
are used to it functioning. I don't like the idea of abandoning it. Votes
for pursuing NET_STRUT in this manner?
    
> >    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
> 

Blackbox uses the middle button as of 0.50.5 for workspace switching, and
the third button for menus.

-------------------------------------------------------------------------
Nathan P. Clemons                       "Peace favor your code."
nathan@windsofstorm.net                 ICQ: 2810688
IN CONSTRUCTION:                        http://gnome.windsofstorm.net
-------------------------------------------------------------------------