[Xcb] keysymdef.h
Ian Osgood
iano at quirkster.com
Wed Nov 8 10:33:58 PST 2006
---------- Original Message ----------------------------------
From: Vincent Torri <vtorri at univ-evry.fr>
Date: Wed, 8 Nov 2006 18:38:28 +0100 (CET)
>
>
>On Wed, 8 Nov 2006, Ian Osgood wrote:
>
>>
>> On Nov 7, 2006, at 11:25 PM, Vincent Torri wrote:
>>
>>>
>>> Hey,
>>>
>>> as we don't rely on X.h anymore, I suppose that we also don't rely on
>>> keysymdef.h. Shouldn't we provide an equivalent file for keysym codes ?
>>>
>>> Vincent
>>
>> The keysym utility library does rely on <X11/keysymdef.h>, as does pretty
>> much anything that uses it.
>>
>> Why bother with an equivalent file? It doesn't have any other dependencies,
>> and it would just be another duplication of code to maintain.
>>
>> I feel the same about the set of standard atoms. I think it was unwise to
>> duplicate them for util/atom. Better would be to split these into two
>> separate packages that could be installed underneath either libX11 or libxcb.
>
>Then why removing the X.h dependancy ? Following your idea, we should use
>what is defined in X.h.
>
>Such file would not be a pain to maintain. Once it's done, there's nothing
>to maintain at all. Keysyms are also described in the X protocol
>(according to keysymdef.h : appendix A)
>
>Vincent
Yeah, you convinced me. As part of the protocol, we really ought to be defining
these ourselves. Maintenance is still an issue: the keysyms have been one of the
most actively changing pieces of Xlib over the years (check gitweb and CVS). As
Xlib changes, we will need to keep XCB up to date.
There is another benefit to defining the keysyms in XML. There are multiple
targets: both the keysymdef.h file (and other headers like XF86keysym.h and
Sunkeysym.h) as well as hash-table source code that is generated at runtime
(currently created from the headers by the X11/util/makekeys utility). This really
should be done from a single source XML file by separate XSL scripts or build
stages, maybe similar to how we generate both headers and source for the
protocol definitions.
Ian
More information about the Xcb
mailing list