Re: Collating proposed changes to 1.9e

[Jeff Raven <jraven psu edu>]

On Tue, Jul 04, 2000 at 02:01:23PM +0000, Michael Rogers wrote:
> >If the user has set the panel to raise on mouse-over, then if it
> >fails to become visible on a mouse over it is failing to behave
> >according to the policy set by the user. That is why an 'on top'
> >hint would be useful here.
> 
> But the user should not specify policy through a client! The WM is there to 
> implement a window management policy so that clients from different sources 
> behave consistently.
> 
> >If the window manager happens to provide a configuration option
> >'Keep windows of type DOCK from ever being on top', and the user
> >opts for it, the window manager can feel free to ignore the panel's
> >request to be on top. Though frankly I have no idea why a window
> >manager would provide such an option.
> 
> Um... for the same reason that the panel would provide such an option.
> 

Can you show me a panel which provides an option to _never_ be
on top?

Sigh. This has long since gotten old. The point of this example
was not to rehash the previous discussions, it was to provide a
different example for the Gnome folks of a use for an 'on top'
hint. There are many others (not the least of which is that the
client's configuration menu is often the most convenient place
for users to access it). Whether or not some of the other folks
on the list agree with the hint does not concern me.

The fact of the matter is, unless I misread the information on
kde.org, KDE2 will be entering a feature freeze in approximately
two weeks. From that point on I suspect that the KDE developers
would prefer not to change their implementation of the spec. All
of which would mean that unless the spec is in a final form
acceptable to both KDE and Gnome (without any desktop-specific
extensions) sometime in the next few days, we'll be right back
where we were before any of the wm-spec nonsense started.

Frankly, I don't see that happening.

Jeff Raven