[Xcb] Few questions about the X selections

[Barton C Massey]

In message <200801262117.28887.maximlevitsky at gmail.com> you wrote:
> Btw the xcb-utils library somehow doesn't compile on my system, 
> 
> xcb_image.c:32:25: error: xcb/xcb_aux.h: No such file or directory
> In file included from xcb_image.c:35:
> xcb_pixel.h:31:28: error: xcb/xcb_bitops.h: No such file or directory
> xcb_pixel.h:32:27: error: xcb/xcb_image.h: No such file or directory
> xcb_image.c: In function 'xcb_create_pixmap_from_bitmap_data':
> xcb_image.c:793: error: 'xcb_params_gc_t' undeclared (first use in this function)
> xcb_image.c:793: error: (Each undeclared identifier is reported only once

You need to get top-of-tree and re-run autogen.sh for util,
is probably all.  My new image library is quite a bit
different from the old one.  If that doesn't fix your
problem, drop me some email and I'll try to replicate it.

> Speaking of this library I have few comments about it , it
> is actually a collection of very small libraries, maybe it
> is better to make them a single library?

Part of the XCB philosophy is to try to keep separable
functionality in separate libraries.  There are some great
software engineering reasons why this works better, as I'm
sure you can imagine.  The only reasons that these libraries
are all in the same repository are that Git isn't very good
at dealing with structured repositories, and that much of
the code in util is really not quite ready for release yet.

> And there is no yet support for the COMPOUND_TEXT <-> UTF8
> conversion.  and this thing is not that easy - I will
> probably implement it if there is need for that.

That would be great.  I agree that this is a hole.  It looks
like libiconv has some ISO-2022 support; maybe that's the
place to put this conversion?

> I currently see the need in that type only in WM_NAME, but
> I can implement the _NET_WM_NAME, and ignore old wm
> managers which doesn't see it. (I will set the WM_NAME
> too, but set its type to STRING)

Yeah, there's a point of diminishing returns in supporting
every combination of "legacy" and "unusual" that comes by.

> The ICCCM says that clients can cache that atoms thus I
> implemented a hash table, and populated it with predefined
> atoms, and put there all new atoms that were requested.
> The xcb-utils uses hash table only for predefined atoms.

You should hack intern_atom_fast() in util/atom.c to use
your code for non-predefined atoms.  Such a patch would be
greatly appreciated.

> Actually I don't yet use xcb-utils at all, but I will use
> it if necessary.

Use it or not as you like, but understand that currently
it's of quite varying quality and usefulness.

> As for the selections, I think they are quite ok, but the
> ICCCM misses one thing, the targets that I need to
> support.  (On the other hand I probably only need to
> support the 'TEXT' target, since the text it what the
> toolkit manages. For the rare case of image cut&paste I
> don't yet know what formats I will be expected to convert
> to by modern toolkits like QT & GTK.

Non-text targets are a big concern of mine; see my previous
message on that subject.

> Besides all the information about the parts of ICCCM
> that are still relevant, and those that I can ignore
> is welcome.

I'm not understanding all this talk of "relevant parts" of
ICCCM.  Parts of it have been superseded by EWMH, but other
than that everything goes AFAIK?

What are folks' thoughts on the current state of Jamey's XCB
ICCCM library in util?

    Bart