[Xcb] [ANNOUNCE] xwininfo 1.1.0

[Vincent Torri]

On Sun, 26 Sep 2010, Alan Coopersmith wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> xwininfo is a command-line utility to print information about windows on an
> X server.  Various information is displayed depending on which options are selected.
>
> The major new feature of this release is the rewrite to use libxcb instead
> of libX11, batching requests for information to reduce waiting on round-trips
> in gathering the client information from the X server.   Testing over a
> high-latency connection from California to China and back resulted in an
> improvement from 8 minutes to 45 seconds to output the complete window tree
> via xwininfo -root -all of a GNOME desktop session with 114 windows.
>
> This release thus libxcb to build, (though it still requires some libX11
> headers as well).   It also requires a minimum xproto version of 7.0.17.
>
> Should anyone need to maintain the libX11 version, a 1.0.x branch can be
> created in git from the 1.0.5 release base as needed.
>
> This release also adds support for reporting some EMWH window manager hints,
> including UTF-8 localized window names from the _NET_WM_NAME property.
> (This version does not correctly display names for windows with the WM_NAME
> property set using the COMPOUND_TEXT encoding.   Most current desktops &
> toolkits will set the _NET_WM_NAME, which is used in preference to WM_NAME
> if it is set.)

Nice work :) Though, I have 2 remarks:

1) Why a file for strnlen that is used only once in xwininfo.c ?

2) You query at the beginning some netwm atoms. Just after, line 548, you 
can exit because the window with a name is not found. You should here get 
the replies of the requested atoms. If I'm not mistaken, you have to get 
the replies to free the memory in the server.

3) You can speed up things even more. As you know that shape extension has 
to be initialized, you can query it at the very beginning. The 
initialization can then be done like that:

a) create the connection
b) First round trip:
  * you request the atoms
  * you prefetch the shape extension data if needed
  * you do some thing that takes time here (get the screen number,
    verify the window, etc...)
  * you get the atoms
  * you ask for the shape extension data if needed
c) Second round trip:
  * you request the QueryVersion for the shape data (if needed),
    GetGeometry, and other requests if any
  * you do some things that take time here and can be done in the first
    round trip (if any)
  * you get the reply of the QueryVersion (if needed) and GetGeometry
    requests etc..

It's a micro optimisation of course, but why not being optimal ?

best regards

Vincent