Re: WM Spec Purpose, etc.

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

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

Sorry, I misunderstood you. I think the idea of a .desktop (or whatever)
file for window manager config tools makes much more sense than a big
complex IPC interface.
 
> > > * 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. =)

Fair point.  :)
 
> > > * 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?

Maybe I was confusing my personal preference for no desktop icons with
what should go into the spec. I still think it's a bad idea to have the
same behaviour and appearance for shortcuts and application icons, though.
 
> > 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.

How does it interact with gmc? Who gets the right clicks?


Michael Rogers