[Xcb] naming convention (finished)

[Vincent Torri]

On Mon, 18 Sep 2006, Jamey Sharp wrote:

> I've pushed a simple Perl script and a trivial XSLT stylesheet that
> together may be used to migrate any source code to the new API. There
> are some corner cases it doesn't convert correctly yet, but it gets most
> things right.
>
> Anyway, between your work and mine, we're almost done. I'm so pleased!
>
> I notice that the new XSLT generates names like xcbBigRequests_init for
> the deprecated XCB*Init functions (that I never actually marked
> deprecated, oops). These should just be removed anyway.

ok

> Other than that difference and some minor disagreements on where to put
> underscores, your XSLT and my Perl seem to largely agree. I think that's
> good. :-)

:)

>> 2) we should change the name of XCBSetupReq in xproto.xml to
>> XCBSetupRequest, imho.
>
> Yes.
>
> On Sun, Sep 17, 2006 at 01:03:55PM -0700, Ian Osgood wrote:
>> On Sep 17, 2006, at 2:38 AM, Vincent Torri wrote:
>>> 1) we must change the name of XCBButton and XCBHost in xproto.xml,
>>> otherwise, the compilation will fail.
>>
>> xcb_button_index and xcb_host_mode were my suggestions.
>
> OK, I'll accept that.

I'll update xproto.xml this evening

>
>>> 4) Because of their name in xproto.xml, some enum values are not
>>> very good, like XCB_CWBACK_PIXEL. Maybe we should change the name
>>> so that we obtain XCB_CW_BACK_PIXEL. It's easy to do in xproto.xml
>>> (changing CW to Cw).
>>
>> Agreed. Josh should look at this; I think we should be able to handle
>> it programatically.

I also think so, even if I have currently no idea on how to do it.

>> Also XIDRange to xid_range instead of xidrange.
>
> My Perl script produces the nice name in both these cases, so apparently
> there exists a consistent rule that produces the output we want. :-) Now
> it's a matter of implementing that rule in XSLT...
>
>>> 7) I've also changed the naming convention of the xcb api. I think
>>> that it's better to have a consistent scheme.
>>
>> I suggest converting BYTE to uint8_t, and possibly do the same for BOOL.
>
> Yes for both. I don't want these byte8_t and bool8_t typedefs.

ok. It's an easy change.

>> Do we actually need <type name="XID" newname="xid" />? I don't see
>> any XID types remaining in the protocol files. I think XID was an
>> Xlib client-only type that we got rid of in XCB.
>
> I think you're right: that line can disappear.

i'll remove it.

>> Symbols mentioned in the comments also need to be converted.
>
> My Perl script does this pretty well. (Some might argue that's a bug,
> but it's pretty selective about what it edits.)
>
> Vincent, don't worry about editing any of the hand-written C code: we'll
> port XCB's insides with the same tool we use to port everyone else's
> source code.

I've already edited it. I had to edit it, though, as I wanted to test the 
new api on small programs.

>> In xcb_in.c, XCBReply and XCBError should be changed to XCB_REPLY and
>> XCB_ERROR.
>
> Yes (but again, my script handles that).

done

>> Possibly move them to xcbint.h.
>
> Mmmm... no reason to at this point, I think.
>
> On Sun, Sep 17, 2006 at 01:38:44PM -0700, Barton C Massey wrote:
>> In message <0FD6BDF9-12FB-4E7A-8E29-15423EAF1372 at quirkster.com> you wrote:
>>> What does everyone else think about switching the prefix from "xcb_"
>>> to simply "x_" as Bernardo suggested?
>>
>> I'm for it.  The XCB prefix was chosen specifically because
>> I didn't want to collide with existing prefixes.  At this
>> point, I think we can safely expect other things to get out
>> of our way. :-)
>
> I'm OK with it, I guess.

Ok, I'll modify that too.

> On Mon, Sep 18, 2006 at 12:05:53AM +0200, Vincent Torri wrote:

>> As I'm changing the files, I can also clean up a bit the files. Adding
>> some new lines, and doing some indentation, like :
>
> Please don't right now. In fact, I'd appreciate it if you'd (at least
> temporarily) undo the minor formatting changes you made to c-client.xsl,
> such as renaming the parameter R to r, and adding a comment on the
> closing #endif in each header file. These changes clutter the diff when
> I'm trying to check that the XSLT agrees with my script, which would be
> a sign that both are probably correct.

ok

I'll send another diff this evening.

Vincent