Re: WM Compliance

[Eckehard Berns <eb berns prima de>]

On Tue, Jun 09, 1998 at 04:09:20PM -0700, Adam Jacob wrote:
> > But I have to admit, that the whole lamp/beacon issue is not that important,
> > and a wm could simply ignore it. It would be nice if some window managers
> > would start to support it, because without the wm's support no one will
> > actually implement it into his app and we will never see if the lamps can
> > make our life easier.
> 
> 	<nod> What are the hooks that you think would be specifically
> needed to implement the lamps?

The wm would just have to read the WIN_APP_STATE window property. The value
given corosponds to a certain type of state (not color). I'm not quite sure if
the app would have to send some kind of notify to the window maker or if
changing the window properties does this automatically. And I cannot test the
code because no existing wm has implemented lamps yet.

> 	Do we want the lamps to be a part of a "WindowManager Compliance"
> speficiation or not?  

[I personally don't want anything to be part of a `WindowManager Compliance'.
If a wm reacts on the properties a GNOME app sets on its windows the wm could
be called `more GNOME friendly' maybe. But doing so will make the wm more
usable with other non-GNOME apps, too. Just because GNOME is in the position
where it can try to make up some new standards doesn't mean other apps
wouldn't benefit from that.]

I'd say that implementing the lamps is some kind of extra a user can benefit
from. Other things like the session management, the tear-off menu bars (and
maybe menus), desktop icons, and that panel-space-reserving things are far
more important IMHO, as they let us skip the override-redirect and work with
session management more effectively.

> 	I, personally, would say not... mainly because of the 
> internationalizaton issues of showing state by color.  Also because
> having "lamps" may adversley affect the desired look and feel of a
> windowmanager... easy examples being WindowMaker, AmiWm, and FVWM-95.
Nope.
> 	Perhaps we could put it in the "optional" section?
Yepp.
> 	Granted, it would affect "look" more than "feel", but...

Well, one might get confused by the word lamp somehow. I think that the whole
issue isn't even a color reactiveness but a way for the app to tell the window
manager about its state. That's all. The proposed way is to make this state
visible by lamps, but that is only one way. I can think of some other. A wm
might just want to list all windows with the WIN_APP_STATE property set in a
separate window or menu (together with its state). As mentioned either in the
proposal or some reply, the original idea was to generate a list of apps
which would be shown with their state in just such a window. Or you could
enhance the window list menu by adding the state of that window after the
window title. And even when ignoring the lamp you could implement a beacon.
WMaker could change the color or look of the tile for that app.

As you might see there are many ways a wm could show that state. I don't think
a window manager would have to change the overall "look". Even if the
info about the windows state is hidden in some menu and displayed via text
instead of colors (i18n), the user would still benefit from it.

-- 
Eckehard Berns