[Xcb] Few questions about the X selections

[Maxim Levitsky]

On Sunday, 27 January 2008 00:49:54 Barton C Massey wrote:
> 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.

Nope, I still get same errors.

I used
git://anongit.freedesktop.org/git/xcb/util

I did more testing, and found:

*only xcb-image is affected, other libraries compile fine.
*the xcb-image needs the xcb-aux installed

xcb_pixel.h includes the <xcb/xcb_image.h> while it isn't yet installed,
don't know how to fix this yet, I just removed the include to compile the library,

* the test programs are a bit broken:

test_formats.c: In function 'main':
test_formats.c:126: error: 'xcb_visualtype_t' has no member named 'visual_class'

It should be _class I think, and this helps

Finally I get this:

test_bitmap.c:9:20: error: test.xbm: No such file or directory
test_bitmap.c: In function 'main':
test_bitmap.c:83: error: 'test_width' undeclared (first use in this function)
test_bitmap.c:83: error: (Each undeclared identifier is reported only once
test_bitmap.c:83: error: for each function it appears in.)
test_bitmap.c:84: error: 'test_height' undeclared (first use in this function)
test_bitmap.c:116: error: 'test_bits' undeclared (first use in this function)
make: *** [test_bitmap-test_bitmap.o] Error 1

There is no test.xbm, thus I can't fix this.
But anyway I think it would be better to make test programs to be separate target.


> 
> > 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.
Well, I think that everything has its limits.
I feel that putting single .c source files into separate libraries
is a bit of too much... just my opinion, I probably will get used to this.


> 
> > 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 still don't fully understand the compound text spec, so it is hard to say
anything, but this library should help.
On the other hand, I don't like dependencies, just for that compound text.
Maybe it is better to look at xlib, and adopt/translate its code for xcb-util?
I take a look at this.

> 
> > 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.
Yes, thanks, but this is a bit hard for me.

I implemented a generic hash table, not something very fast/with small memory footprint:

/* this is embedded into hashed structure*/
struct hash_entry {
	uint32_t 		hash;
	struct hash_entry* 	next; /* for collisions*/
};

struct hash_table {
	int			min_order;			/* minimal order (2^order) of the hash table*/
	int			max_order;			/* maximum size of hash table*/

	/* returns 32-bit hash value for user defined data*/
	uint32_t 		(*hash_func) (void* data);
	/* returns '1' if hash entry 'e' really contains the data 'data'*/
	int	 		(*validate_func) (struct hash_entry* e, void* data); 	

	/* private*/
	int 			order;
	int 			count;
	struct	hash_entry      **hash;
};

Don't think that it is good to include it in xcb-utils.

I just fill it with predefined atoms, and then forget about those atoms, just look everything in that table.
the table is only for string->atom lookups, I didn't yet decided whenever it is good to have a reverse table as well.
(For predefinded atoms it is trivial, just an array lookup, but for others I will need another hash table)

the xcb-atom uses gperf now, but I think (although I heve never used it) it can't be used as generic growable hash table.

I don't yet see a simple solution, maybe use one hash table for everything instead of gperf fixed table?
maybe, but this will slow the startup a bit since the standard atoms need to be filled in the table dynamicly like I do,
don't know.


> 
> > 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.
I agree with that, but I have long way until I need those.
> 
> > 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?
Some standards has deprecated parts, and X has plenty of those.
For example most of the drawing today is done with XRENDER which I still has to learn,
and write my own tessellation engine....
The fonts aren't anymore rendered by X, but by freetype, and put on screen with XRENDER.
To use keyboard I can't use standard key-mappings, because they are obsolete, I again need to use the XKB.

Even the use of window per widget is considered a bit obsolete, I have seen suggestions to create just the
top level windows, and draw all widgets on them, but I won't do this, regardless of the performance gains I might
achieve, I just don't like this - child windows are the core of windowing concept, and this is it.

Thus I thought that maybe the ICCCM has some deprecate parts as well, now I know that it hasn't,
Only additions to it are described in EWMH.

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

Thanks a lot,
	Best regards,
		Maxim Levitsky