[Xcb] Few questions about the X selections
Barton C Massey
bart at cs.pdx.edu
Sun Jan 27 12:10:02 PST 2008
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
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
More information about the Xcb