[Xcb] Few questions about the X selections

[Maxim Levitsky]

On Sunday, 27 January 2008 22:10:02 Barton C Massey wrote:
> 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.
Everything compiles now, I compiled the test programs too, and they work fine too.
Thanks a lot.


If I find more bugs or if I write something useful to add to xcb-utils I post it there.
> 
> > > > 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.
Yes, I probably use it, thanks.

> 
> > 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.
I thought about this, and I agree that this is what I probably will do.
Meanwhile I realized that mostly I don't need a hash table at all, 
since in most cases I know the atom name, and I need ether to compare it to 
the atom number I got or sent this number.

I can't think about a case in which I get an arbitrary atom name, and need to translate it
to its id, probably the opposite, sometimes (mostly in selections, maybe some debugging) I could need
to get the atom name, although this will be rarely, thus I can just ask the server about it.

Instead I created a global array,  and I fill it with atoms on start.

Then I just use this array like this:
#define WM_DELETE_WINDOW	global_atoms[2]

I don't have any more questions now, thanks again.

> 
>     Bart
> 

Best regards,
	Maxim Levitsky