On Fri, May 03, 2002 at 12:18:42AM -0400, Havoc Pennington wrote:
> Lubos Lunak <l lunak sh cvut cz> writes:
> >  TYPE_MENU is used for the mac style menubar, not for tear-off
> > menus, the tear-off menus (created by Qt) are normal TYPE_NORMAL
> > windows (and spec says that TYPE_MENU is for tear-offs). The correct
> > way would be to make KWin treat TYPE_MENU the same way as
> > TYPE_NORMAL (i.e. tear-offs are not handled specially in KWin right
> > now AFAIK), and I guess we need also TYPE_GLOBAL_MENUBAR for the mac
> > style menubar (either in the spec or a KDE extension).
> I think simply DOCK _may_ work for the global menubar; the GNOME "menu
> panel" uses DOCK and I can't think of what would be different about
> I do think we have several kinds of "dock" things; gkrellm-style
> floating gadgets for example. The KDE pager thing (I'm not sure what
> to call it - it's a little window you get if you click the arrow on
> the workspace-switcher applet? right now it sets type TOOLBAR) -
> anyway this thing may be a different kind of window, or maybe it's
> like a UTILITY toolbox/palette window? Or possibly it's just a DOCK.
> At some point to make a nice integrated desktop I'm finding that we do
> have to more or less declare that all windows must fit into a fixed
> category; apps just can't get the behavior right without WM
> assistance. :-/ e.g. apps can't do stacking order stuff at all...
> MacOS only had 4 or 5 possible categories, so it should be feasible.
> Anyway, I think it's a consequence of the X architecture that the WM
> has to understand what kinds of windows there are.

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

  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.

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(?)).


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