Re: _NET_WM_WINDOW_TYPE_MENU

[Lubos Lunak <l lunak sh cvut cz>]

On Friday 03 May 2002 06:18, 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
> GLOBAL_MENUBAR offhand.

 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.

 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?

>
> 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.

 It's simply called KPager, and I think it should be UTILITY.

>
> 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.
>
> >  Maybe I'm just too blind, but where can one see the up to date
> > version of the spec?
>
> I'll append the latest draft to this mail. I need to get it on the web
> site I know, I'll try to do it tomorrow.
>
> > Also, which WMs use the spec, only KWin,Sawfish,Metacity?
>
> As far as I know. Once GNOME 2 is out there may be more interest from
> other window managers, since people have traditionally used GNOME with
> WindowMaker and so forth.
>
> These three implementations are surprisingly interoperable though, as
> I mentioned earlier I was able to run Metacity with KDE 3 and things
> worked nicely as far as I could tell. I've been meaning to try KWin
> with GNOME 2.

 Below is a list of things KDE does differently from the spec or doesn't do 
them at all. Nothing fatal, just the window types may cause some little 
trouble. Also, there may still be places in KDE where DCOP is used for 
communicating with KWin, instead of using the more generic methods. I'll try 
to make the list shorted when I have time.

 So let's see how many things there are that KDE doesn't either support or 
does things differently:

> 	<sect2>
> 		<title>_NET_DESKTOP_VIEWPORT</title>
> 	<programlisting><![CDATA[
> _NET_DESKTOP_VIEWPORT x, y, CARDINAL[][2]/32
> ]]></programlisting>
> 	<para>
> Array of pairs of cardinals that define the top left corner of each
> desktops viewport.  For window managers that don't support large desktops,
> this MUST always be set to (0,0).

 KWin doesn't support this feature, and doesn't set this property to (0,0).

> 	<sect2>
> 	<title>_NET_VIRTUAL_ROOTS</title>
> 	<programlisting><![CDATA[
> _NET_VIRTUAL_ROOTS, WINDOW[]/32
> ]]></programlisting>
> 	<para>
> To implement virtual desktops, some window managers reparent client windows
> to a child of the root window.  Window managers using this technique MUST
> set this property to a list of IDs for windows that are acting as virtual
> root windows.  This property allows background setting programs to work
> with virtual roots and allows clients to figure out the WM frame windows of
> their windows.
> 	</para>
> 	</sect2>
> 	</sect1>

> 	</sect2><sect2><title>_NET_WM_MOVERESIZE</title>
> 	<programlisting><![CDATA[
> _NET_WM_MOVERESIZE
>   window = window to be moved or resized
>   message_type = _NET_WM_MOVERESIZE
>   format = 32
>   data.l[0] = x_root
>   data.l[1] = y_root
>   data.l[2] = direction
> ]]></programlisting>
> 	<para>
> 	This message allows an application to initiate window movement or
> resizing.  This allows the application to define its own move and size
> "grips", whilst letting the window manager control the actual move/resize. 
> This means that all moves / resizes can happen in a consistent manner as
> defined by the WM. </para>

 Not supported.
 
> 	<para>
> _NET_WM_WINDOW_TYPE_TOOLBAR and _NET_WM_WINDOW_TYPE_MENU indicate toolbar
> and pinnable menu windows, respectively (i.e. toolbars and menus "torn off"
> from the main application). Windows of this type may set the
> WM_TRANSIENT_FOR hint indicating the main application window.
> 	</para>

 As already stated, TYPE_MENU is used for something different, and Qt doesn't 
set it on the windows that should have it.

> 	<para>
> _NET_WM_WINDOW_TYPE_UTILITY indicates a small persistent utility window,
> such as a palette or toolbox. It is distinct from type TOOLBAR because it
> does not correspond to a toolbar torn off from the main application. It's
> distinct from type DIALOG because it isn't a transient dialog, the user
> will probably keep it open while they're working. Windows of this type may
> set the WM_TRANSIENT_FOR hint indicating the main application window.
> 	</para>
> 	<para>
> _NET_WM_WINDOW_TYPE_SPLASH indicates that the window is a splash screen
> displayed as an application is starting up.
> 	</para>

 These two are new and not supported yet.

> 	<para>
> _NET_WM_WINDOW_TYPE_DIALOG indicates that this is a dialog window.  If
> _NET_WM_WINDOW_TYPE is not set, then windows with WM_TRANSIENT_FOR set MUST
> be taken as this type.
> 	</para>

 The part in Qt setting this should be finally enabled, at least guessing from 
the comment ;).

> 	<para>
> _NET_WM_WINDOW_TYPE_NORMAL indicates that this is a normal, top-level
> window. Windows with neither _NET_WM_WINDOW_TYPE nor WM_TRANSIENT_FOR are
> set MUST be taken as this type.
> 	</para>


 KDE also has _NET_WM_WINDOW_TYPE_OVERRIDE, which basically means a borderless 
window, and it seems to be a bit overused (now it's used at least for 
toolbars and fullscreen windows). It looks more like a quick and dirty hack 
to me, and it corresponds to Qt's WStyle_NoBorder (in order words, IMHO it 
shouldn't be used anywhere in KDE, but we can't get rid of it).

>         <para>
> _NET_WM_STATE_HIDDEN should be set by the window manager to indicate
> that a window would not be visible on the screen if its
> desktop/viewport were active and its coordinates were within the
> screen bounds. The canonical example is that minimized windows should
> be in the _NET_WM_STATE_HIDDEN state.  Pagers and similar applications
> should use _NET_WM_STATE_HIDDEN instead of WM_STATE to decide whether
> to display a window in miniature representations of the windows on a
> desktop.

> 	<para>
> _NET_WM_STATE_FULLSCREEN indicates that the window should fill the entire
> screen and have no window decorations. For example, a presentation program
> would use this hint.
> 	</para>

 Both these are new and not supported yet.

> 	<sect2>
> 		<title>_NET_WM_ALLOWED_ACTIONS</title>
> 		<programlisting><![CDATA[
> _NET_WM_ALLOWED_ACTIONS, ATOM[]
> ]]></programlisting>
> 		<para>

 Not supported.

> 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 ? ;)

> 	<sect2>
> 		<title>_NET_WM_PID</title>
> 	<programlisting><![CDATA[
> _NET_WM_PID CARDINAL/32
> ]]></programlisting>
> 		<para>
> If set, this property MUST contain the process ID of the client owning this
> window.  This MAY be used by the Window Manager to kill windows which do
> not respond to the _NET_WM_PING protocol.

 This one is set by KDE, not Qt, and only for normal toplevel windows.

> See also the implementation notes on <link linkend="KILLINGWINDOWS">killing
> hung processes</link>. </para>
> 	</sect2>
> 	<sect2><title>_NET_WM_HANDLED_ICONS</title>
> 	<programlisting><![CDATA[
> _NET_WM_HANDLED_ICONS
> ]]></programlisting>
> 	<para>
> This property can be set by clients to indicate that the Window Manager
> need not provide icons for iconified windows, for example if the client is
> a taskbar and provides buttons for iconified windows.
> 	</para>

 Supported, but not set by the taskbar.

> 	</sect2>
> </sect1>
> <sect1>
> 	<title>Window Manager Protocols</title>
> 	<sect2>
> 		<title>_NET_WM_PING</title>
> 		<para>

 Not supported.

> <sect1>
> 	<title>Implementation notes</title>

 Section skipped, things like window gravities make me scared.

-- 
 Lubos Lunak
 llunak suse cz ; l lunak kde org
 http://dforce.sh.cvut.cz/~seli