Re: WM Spec Purpose, etc.



On Fri, 16 Jul 1999, Michael Rogers wrote:

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

What I was referring more to is how GNOME or KDE will know certain pieces
of info about the WMs and the WM config tool, not so much as the config
tool talking to the WM. In my opinion, the config tools should be written
by the people writing the WM. They can use CORBA, IPC, whatever they want,
as long as it gets the job done and deals with at least (X) particular
options.

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

Any comments from the list on suggestions in this venue?

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

Even with the patch for better GNOME compliance, GMC is the one GNOME
thing that Blackbox unequivocably does not play nicely with at the moment.

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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]