[Xcb] Few questions about the X selections

[Barton C Massey]

In message <200801271629.03078.maximlevitsky at gmail.com> you wrote:
> 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, 
> > 
> > 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.
> 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.

My apologies.  I assumed someone besides me had tried to
compile util from scratch since I revamped the image library
a while back.  All of the build bugs you reported were
real---some of them were ugly.  I think I have them all
fixed, or at least kludged, and committed.  Please pull and
try again.

Thanks much for the clear bug reports.

> > > 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.

Another part of XCB's philosophy is to re-invent other
people's working wheels as little as possible.  I've looked
at it more and I'm definitely convinced that if you want to
support ISO-2022 compound text, libiconv is the way to go.

> 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.

Just keep the predefined atoms in the gperf table, the
client-created atoms in your table, and do lookups in both
tables.

    Bart