Global events receiving (keyboard, mouse events, active window change)

Glynn Clements glynn at gclements.plus.com
Fri Jan 5 03:21:48 PST 2007


Alexander Nemish wrote:

> 1. Also I need to get all top-level windows and their titles. I'm using
> XQueryTree(dpy, root_window, ...) and XGetWMName for every child
> returned. I'm getting _all_windows and have no idea on which are
> top-level.

Probably because the notion of a "top-level" window isn't clear cut.

The term normally refers to a window which was created as a child of
the root window.

If a WM is running, and the window doesn't have the override-redirect
flag set, the WM will probably reparent such windows within a frame
(with a title bar, resize handles etc). The reparented window will no
longer be a direct child of the root window.

In that situation, the top-level window (the one which the application
created as a child of the root window, with the various WM-related
properties) may now be nested more deeply within the window stack. 
Exactly where will depend upon the WM (if one is running).

You could traverse the entire window tree from the root down, looking
for anything with a WM_NAME property (and/or other WM-related
properties).

However, there are potentially still issues with other forms of
reparenting, e.g. where an application "swallows" a top-level window
by reparenting it within a child window. Is such a window a
"top-level" window?

If you know that the current WM (if there is one) always reparents
top-level windows in a particular manner, you can always ignore
windows which are too high or low in the window tree.

However, some WMs may be too flexible in this regard. E.g. FVWM
includes the FvwmScroll module which allows any managed window to be
swallowed within a scrollable viewport. In this state, the original
window (with the WM_* properties) will be reparented even further and
thus appear lower in the window tree.

To provide a concrete example, here is the output from
"xwininfo -root -tree" for an xterm, edited to show only relevant
information. In all cases, the window you are likely to consider the
"top-level" windows is 0x400010 (0x400017 is the xterm's vt100
widget):

xterm with no WM:

  Root window id: 0x28 (the root window) (has no name)
     0x400010 "xterm": ("xterm" "XTerm")  564x316+0+0  +0+0
        0x400017 (has no name): ()  564x316+0+0  +0+0

xterm under FVWM:

  Root window id: 0x28 (the root window) (has no name)
     0x200112 (has no name): ()  572x342+0+0  +0+0
        0x200113 (has no name): ()  564x316+4+22  +4+22
           0x400010 "xterm": ("xterm" "XTerm")  564x316+0+0  +4+22
              0x400017 (has no name): ()  564x316+0+0  +4+22

xterm under FVWM, with scrollbars:

  Root window id: 0x28 (the root window) (has no name)
     0x200144 (has no name): ()  316x210+1+1  +1+1
        0x200145 (has no name): ()  308x184+4+22  +5+23
           0x800001 "xterm": ()  308x184+0+0  +5+23
              0x800002 (has no name): ()  282x158+5+5  +10+28
                 0x400010 "xterm": ("xterm" "XTerm")  564x316+0+0  +10+28
                    0x400017 (has no name): ()  564x316+0+0  +10+28

Note that the 0x2????? windows belong to the WM, the 0x4????? windows
belong to the xterm client, and the 0x8????? windows belong to the
FvwmScroll module.

-- 
Glynn Clements <glynn at gclements.plus.com>



More information about the xorg mailing list