[Xcb] XCB naming conventions (progress)

[Vincent Torri]

>
> This enumeration is used similarly to XCBMapIndex.  Perhaps we could name it 
> XCBButtonIndex.

yes

>
> My convention was to name the enumerations so that the generated names 
> matched the X.h names as closely as possible to ease migration. (Almost all 
> of the enumerations, including XCBButton, match X.h but with the "XCB" 
> prefix.) I had to change some enumeration names to avoid conflicts with the 
> error numbers, which don't otherwise have a distinguishing suffix (a bug, in 
> my opinion).
>
> (This brings up another quibble. Why do we have a separate named structure 
> for every error returned when they are all structurally identical? I propose 
> a single XCBCoreError structure instead.)
>
>> 
>> 2) same problem with XCBHOST and XCBHost. Although I don't have an idea for 
>> the enum name. X.h does not describe it well.
>
> This for the "mode" member of the XCBChangeHosts structures and requests.
>
> One solution is to leave the enumerations unnamed, to avoid polluting the 
> namespace. This has precedent in Apple's Carbon and pre-Carbon APIs. Nothing 
> else in XCB refers to them. However, this closes the door on future 
> type-safety and protocol documentation work.
>
> Another solution is to reuse the XCBSetMode enumeration already used for 
> XCBChangeSaveSet. This works nicely because it matches the "mode" member for 
> a bit of self-documentation.  (I think this is my preference.)
>
> Another solution is to break with X.h and try instead to match the member 
> name where the enumeration is used. In this case, that would be XCBHostMode { 
> XCBHostModeInsert, XCBHostModeDelete }.  This may make the most sense, since 
> this whole naming change will completely break with X.h (which uses 
> StudlyCaps thoughout).
>
> You suggested another solution, use a different suffix for enumerations, _e.

I wait for others' opinion

>> 
>> 3) I have a technical problem with XSLT : some requests ask for pointer and 
>> its length. I automatically add '_t' to the name of the type, but there is 
>> a problem in case the type is char and void. The xsl code is :
>>
>>      <xsl:attribute name="type">
>>        <xsl:text>const </xsl:text>
>>        <xsl:call-template name="canonical-type-name" />
>>        <xsl:text>_t *</xsl:text>
>>      </xsl:attribute>
>> 
>> So I would like to test the value returned by the template and add if only 
>> if the value of canonical-type-name is different from char and void
>> 
>> Does someone have an idea on how to do that ?

it's solved

>> 
>> Remarks:
>> 
>> 1) in xproto.xml, there is the structure SetupReq. Shouldn't iit be renamed 
>> as SetupRequest ?
>
> Yes. I think Jamey also wanted to expand all "Req" to "Request" and all "Rep" 
> to "Reply" as well.

ok

>> 
>> 2) for enum dans define values, I use upper case letter, with words 
>> separated with underscores. Is it ok for everybody ?
>
> I'm not  sure what you mean here. Could you give an example?

instead of :

#define XCBTotoTata

I propose

#define XCB_TOTO_TATA

same for enum

> Another thing: once renaming in xproto is complete, will we want to use the 
> same naming conventions on the symbols in xcb.h?

I would like to. In fact, i've already done it :) I think that xcb api 
must be consistent with the protocol one. It would be strange to have :

XCBConnect (c);
w = xcb_window_new (c);

imho.

I've open a blocker bug in bugzilla, about that naming convention stuff.

Vincent