[Xcb] naming convention (finished)

[Jamey Sharp]

On Sun, Sep 17, 2006 at 11:38:04AM +0200, Vincent Torri wrote:
> Hey,
> I have finally beaten that xsl stylesheet.

Hi Vincent! Very nice work!

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.

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.

>3) for defines and enum values, instead of TotoTata, I use TOTO_TATA.

Good.

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.

> >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.
> 
> 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.

> 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.

> 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.

> In xcb_in.c, XCBReply and XCBError should be changed to XCB_REPLY and  
> XCB_ERROR.

Yes (but again, my script handles that).

> 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. 

On Mon, Sep 18, 2006 at 12:05:53AM +0200, Vincent Torri wrote:
> I'll let the others modify xcl ;)

Yup, don't worry about that. :-)

> 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.

--Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20060918/6741137d/attachment-0001.pgp