Hints for unmanaged window [was Extending XFixes Extension]
chapuis at lri.fr
Thu Nov 4 22:25:29 PST 2004
On Thu, Nov 04, 2004 at 09:22:11PM -0500, Owen Taylor wrote:
> On Thu, 2004-11-04 at 23:09 +0100, Amir Bukhari wrote:
> > > I don't see any reason to extend that to listing particular display
> > > connections. It's somewhat interesting for a profiler - and the
> > > X-Resource extension I think does list clients. But other than that,
> > > I don't think it's relevant information.
> > > From rom what you are describing above, I think the concept you want
> > > is the window group based on the group leader.
> > >
> > your though is based on 2D Desktop, what we implement is 3D Desktop,
> > that mean all top-level windows (including non-redirect one) are all
> > managed with 3D Window Manager, so it nees a lot of information about
> > application to render their top-level windows.
> > GNOME give for example give popup windows a group leader, which is
> > different of from dialog boxes and this also different from the main
> > application window, so 3D Manager doesn't know (for examole) to which it
> > should attache the popup menus. think about of you have more than
> > applications opened!
> GTK+ is actually pretty liberal about setting ICCCM properties on
> override-redirect windows. Just checked a menu and it indeed
> has the group leader hint on it, plus most of the other stuff
> GTK+ sets on managed window.
> But how does knowing the display connection tell you what window a
> popup should be attached to? Apps with multiple toplevels are common?
> If you want to get that information right, I think you need
> to make requests to toolkit authors to start setting the transient-for
> hints on popups. We'd be happy to do that for GTK+.
> (_NET_WM_WINDOW_TYPE would also be useful it seems.)
I read this discussion with a lot of interest as metisse (an other
3D desktop) needs such "hints". It will be very useful to have
information on unmanaged window. This will be useful for a
"simple" composite manager too. I think that the EWMH specification
should be used and so extended (so I cc to the wm-spec list).
A few months ago I written the following as a new section for the
EWMH specification but never send it. Maybe this can be used as
An override redirect window SHOULD be ignored by the Window Manager
and by any Client, but the creator of this window. However some
special applications need some information on these windows. By
definition an unmanaged window is an InputOutput top level window
which is not managed by the window manager (roughly speaking a visible
window which does not appear in the _NET_CLIENT_LIST). Such window is
either an override redirect window or a window created by the window
manager to handle window management as a move-resize feedback window
or a window frame (some window manager use override redirect windows
for such windows, others no).
This proprety is similar to the WM_TRANSIENT_FOR property but for
unmanaged window. This property SHOULD be set before mapping
to a top level managed window indicating the main application window.
This SHOULD be set by the Client before mapping an unmanaged
window to a list of atoms indicating the functional type of this window.
If there is no contradiction, the Client SHOULD specify one of the basic
window type atoms from the list below. More that one window type can be set
to allow extension of the list of types.
_NET_UM_WINDOW_TYPE_MENU indicates a popup menu.
_NET_UM_WINDOW_TYPE_PULLDOWN_MENU indicates a pull down menu (from a
combobox for example).
_NET_UM_WINDOW_TYPE_TOOLTIPS indicates a tool tips.
_NET_UM_WINDOW_TYPE_FEEDBACK indicates a temporary feed back window
(a move resize feedback window for example).
_NET_UM_WINDOW_TYPE_DND indicates a window which release a drag and drop
_NET_UM_WINDOW_TYPE_OBJECT indicates a temporary object (a realization
of the move a window widget for example).
_NET_UM_WINDOW_TYPE_FRAME indicates a window manager window frame.
_NET_UM_WINDOW_TYPE_ICON indicates a window manager icon.
_NET_UM_WINDOW_TYPE_IGNORE indicates a window that should not be
considered at all (as an off screen unmanaged window).
More information about the xorg