incorrect interpretation of window types toolbar and menu

[Lubos Lunak <l lunak suse cz>]

(CC-ing one of OpenBox developers because I'm not sure if any of them is 
subscribed here, sorry if you are).

 Hello,

 (Intro: I tried to create a patch for Qt to make sure it always sets correct 
window type, because I even intend to use it in KWin, and guess what - I 
actually broke Qt by the patch. At least with some window managers. That's 
why one OpenBox developer is in CC. And one FVWM developer would be there 
too, but I remember seeing some of them here, so I hope this isn't needed).

 Get some application that sets window type for torn-off toolbars and menus 
(or just create a testapp, e.g. metacity-window-demo would do, but with real 
app it will be more obvious).

 Menus first - they're almost useless with OpenBox or FVWM (only recent 
versions of FVWM). They are on all desktops, they are borderless, and one 
cannot move them. My guess is that this is because KDE (3.0 and older) used 
_NET_WM_WINDOW_TYPE_MENU for something different than what the spec says - it 
was used for the standalone menubar a'la macmenu. That was indeed KDE mistake 
(even though I was told that TYPE_MENU was originally meant to be that, and 
it somehow ended up meaning what it is now), but I suppose you could at least 
have told us, instead od doing the same. See also 
http://mail.gnome.org/archives/wm-spec-list/2002-May/msg00001.html.

 The attached piece of code is what's currently in KWin to detect the old 
incorrect usage of TYPE_MENU, feel free to use it. If you want to keep 
support for KDE's menubar, which is _KDE_NET_WM_WINDOW_TYPE_TOPMENU since 
KDE3.1, and will need a bit of work to handle in KDE3.2, we can discuss that 
at the kwin kde org mailing list. Or here, if there's enough interest.

 Toolbars second - that's not as bad. If you actually manage to find something 
that has tear-off toolbars and sets the window type on them, you'll get no, 
one or two decorations depending on what you use. Could we please agree how 
to decorate them? I think I already asked about this here once, but I can't 
find it in the archives :(. I also don't remember what conclusion there was, 
if any.

 I think the correct way here is that the application doesn't draw the 
decoration, only the WM does. This will allow the WM to control the dragging 
of the toolbar. On the other hand, there's a small problem, since one needs 
to be able to dock the toolbar back in the application, that's why Qt 
currectly draws the titlebar itself. I think that would need a message to the 
toolbar to make it dock back, and the WM could provide e.g. a titlebar 
button. Could we agree on this, or does somebody have any better idea?

-- 
Lubos Lunak
KDE Developer
l lunak suse cz     l lunak kde org

        if( wt == NET::Menu )
        {
            // ugly hack to support the times when NET::Menu meant NET::TopMenu
            // if it's as wide as the screen, not very high and has its upper-left
            // corner a bit above the screen's upper-left cornet, it's a topmenu
            if( x() == 0 && y() < 0 && y() > -10 && height() < 100
                && abs( width() - workspace()->geometry().width()) < 10 )
                wt = NET::TopMenu;
        }