Re: _NET_WM_WINDOW_TYPE_MENU

[Havoc Pennington <hp redhat com>]

Olivier Chapuis <olivier chapuis free fr> writes: 
> One solution to these decorations problems are to use the MWM
> decoration hints. It seems to me that some DOCK must not be
> decorated at all (e.g., GNOME and KDE panels) as some others
> _may_ have some decorations (e.g., a task bask or pager).
> So what I suggest is to add something like what follow at the
> end of the "Rational:" paragraph of the _NET_WM_WINDOW_TYPE
> description.
> 
>   The window manager decides itself how it decorates the windows
>   of various types. However, when an application needs (or assumes
>   by itself) a special decoration it MUST use the MWM decoration
>   hints. The others MWM hints should be used in the same way.

That doesn't really work though, since you have lots of possible
behavior differences that are not just about decoration
(e.g. stacking, focus), and apps really should not be overriding the
decorations for a semantic type.

> Also I think that the wm-spec should contains a paragraph on the
> MWM hints in the "Non-ICCCM features" section (something that say
> that they may be used and that in some case the MWM decoration
> hint MUST be used(?)).

That's true, we do need to clarify the role of the MWM hints.

My view is that whenever they are needed we have a broken situation
where the semantic types aren't doing what we want, but realistically
we need to support "turn off all decorations" for back compat.

The more specific hints could be useful for an "OVERRIDE" type as 
mentioned for KWin. I'd definitely want to ignore the more specific
MWM hints on something like UTILITY though, because either the window
is UTILITY and should behave consistently like other UTILITY windows,
or it's not UTILITY and should not be marked as such.

I guess my feeling is that OVERRIDE is perhaps needed to support some
silly features of toolkits like Swing, but on the whole anytime you're
using OVERRIDE you would be creating a new type of window inconsistent
with other windows, and that can't be good for the user
experience. Aside from the inconsistency, again, you just can't get
things like stacking and focus to work correctly without the WM
understanding what kind of window you have.

I haven't seen many examples of windows that fall outside of current
categories though. Maybe the global menubar, maybe Windows-XP-style
system tray balloons. But both of those window types _clearly_ require
window manager support.

Havoc