Re: _NET_WM_WINDOW_TYPE_MENU

[Havoc Pennington <hp redhat com>]

Lubos Lunak <l lunak sh cvut cz> writes:
>  The mac style menubar is different, as every application provides its own 
> menubar and they are shown&raised/hidden when the apps windows become 
> (in)active (a comment in the source says it avoids flicker). Maybe it will 
> work with DOCK, as it is transient, I'll see.

I agree we may need a hint for that then.

>  BTW, a bit OT, but any idea if Gtk+ could support this too? I'm
> getting used to this feature, and it's a bit annoying with those few
> non-KDE apps I use.  Or would wider use of this feature make Apple
> ... erm, annoyed?

Yeah, we may add it in 2.4. We were waiting to more comprehensively
rework the menu API.
 
>  It's simply called KPager, and I think it should be UTILITY.

That was also my first impulse, FWIW.
  
> > Note that the actions listed here are those that the <emphasis>window
> > manager</emphasis> will honor for this window. The operations must still be
> > requested through the normal mechanisms outlined in this specification. For
> > example, _NET_WM_ACTION_CLOSE does not mean that clients can send a
> > WM_DELETE_WINDOW message to this window; it means that clients can use a
> > _NET_CLOSE_WINDOW message to ask the window manager to do so.
> [snip]
> > _NET_WM_ACTION_CLOSE indicates that the window may be closed (i.e. a
> > WM_DELETE_WINDOW message may be sent).
> 
>  Aren't these two a bit conflicting about WM_DELETE_WINDOW ? ;)

The "WM_DELETE_WINDOW message may be sent" line is meant to refer to
the window manager, I think. But it could stand some clarification.

Havoc