Re: _NET_WM_WINDOW_TYPE_MENU

[Havoc Pennington <hp redhat com>]

Cristian Tibirna <tibirna kde org> writes: 
> I don't have enough experience to realize if decorating TYPE_MENU windows 
> would wreak havoc anywhere. I fact, I now wonder what is the purpose of the 
> TYPE_MENU spec in the NET protocol (i.e., what were the reasons for which it 
> was specified). And I also wonder: is a menu gets decorated, what 
> differentiates it from a normal window? Why does it need/require the 
> TYPE_MENU hint on it?
> 

The type hints are meant to mark all distinct kinds of window, so the
window manager can fine-tune behavior.

You might want a different kind of decorations for torn-off menus, for
example, or might always use the placement algorithm for normal
windows and honor position hints for tearoff menus, or may
iconify/deiconify tearoff menus with the parent app. Those are just 3
examples I thought of quickly, there are lots of things you could
potentially do.

IMO there's no question that torn-off menus (MENU) are intended to be
decorated by the window manager, since all toolkits have traditionally
set them up as decorated windows. Torn-off toolbars (TOOLBAR) are
harder, current KWin decorates these and Metacity does not. I haven't
checked with Sawfish. However Qt last I looked seemed to draw its own
decorations for the torn-off toolbar, and GTK draws a resize grip, so
maybe we should be transitioning to having the WM do the decorations
for toolbars as well.

Another pending issue with these hints is that the spec recommends
setting WM_TRANSIENT_FOR on the menu/toolbar indicating that 
the menu/toolbar is associated with a given window, for better
handling of minimization, etc. But this may confuse some older window
managers into thinking the menu/toolbar is a dialog.

On the other hand, some versions of Java set WM_TRANSIENT_FOR on
regular menus (i.e. not torn off, still attached to the menubar), so
no window manager can do anything strange with dialogs right now
anyway without breaking Java.

Havoc