[Xcb] Bug 6254: remove XCB's xproto/X11 dependency

[Ian Osgood]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Mar 14, 2006, at 12:08 AM, Jamey Sharp wrote:

> On Mon, Mar 13, 2006 at 09:30:29PM -0500, Jeremy Kolb wrote:
>>> The <enum> construct generates very wordy symbols. (Example: enum  {
>>> XCBWindowClassInputOutput = 1 } XCBWindowClass; where previously   
>>> one
>>> only had to deal with InputOutput). You could argue that this is  a
>>> feature, though perhaps not for masks. Maybe an option to prefix   
>>> the
>>> members just with "XCB" and not the full name of the enumeration?
>>
>> I really think we need a better way of handling enums.  The names are
>> way too unwieldly.  Vincent and I have talked about this but we  
>> couldn't
>> come up with a good solution.  I really think it needs to be changed
>> though, not developer friendly at all.
>
> I like "developer-friendly" where possible, but one response to  
> this is
> that I don't expect many people to program directly to XCB. Usually  
> some
> toolkit is preferable; only the authors of toolkits, and some  
> libraries
> like Cairo and libGL, should care much about XCB's API. My preference
> would be an API that closely reflects the protocol documentation. A  
> bit
> of typing won't kill anyone.

The problem is the documentation for the constants uses their short  
names,
and many of the constants are used in multiple requests.  What would you
name the enum that contains XCBNone?  Does the XSLT have a function
to define an arbitrary XCB namespace constant as an alternative?

Personally, I am easily persuaded that XCBWindowClassInputOutput is
a good thing: self-documenting and avoids name conflicts. Code should
be written to aid the reader, not the writer.  Those who want shorter or
more traditional names know where to find X.h.

>
> That said, I'll take patches for a pretty wide variety of  
> approaches at
> this point, partly because I don't feel strongly about this part of  
> the
> API design and partly because I don't want to go very long without a
> solution.
>
> --Jamey

(BTW: I'd like to try my hand at this XSLT stuff with a better construct
for bitmask constants.  <op="&lt;&lt;"> is 1) ugly 2) repetitious 3)  
C-specific.
We should strive to be language-neutral in the protocol definitions,  
right?)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEFvebHDwFgzc3zyIRApDoAJ9GhFc1CfG+ZYVEqWfjBgS/9E5DHQCggLLY
y2FR9I5C/SoAqiHSZmlkZoQ=
=WuoX
-----END PGP SIGNATURE-----