[Xcb] XCB naming conventions

[Vincent Torri]

On Wed, 13 Sep 2006, Barton C Massey wrote:

> I'm willing to delay the release another week if everyone
> agrees a name change is needed, so that we can get it all
> straightened out.

If Josh can't work on the xslt, I can try to modify it (i've already used 
xsl stylesheet). But it will take a long time.

If there is someone else that wants to work on it and better than me, 
he'll be able to finish that work on time. I can't.

Vincent

>
> Of course, we can open Pandora's box wider by asking about
> the structure-based typing (e.g. cookie types); there's been
> some talk that this should go also... :-)
>
> 	Bart
>
> In message <20060913190453.GA30836 at id.minilop.net> you wrote:
>>
>> --===============0216440475==
>> Content-Type: multipart/signed; micalg=pgp-sha1;
>> 	protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr"
>> Content-Disposition: inline
>>
>>
>> --liOOAslEiF7prFVr
>> Content-Type: text/plain; charset=us-ascii
>> Content-Disposition: inline
>> Content-Transfer-Encoding: quoted-printable
>>
>> On Wed, Sep 13, 2006 at 02:19:05PM -0400, Jeremy A. Kolb wrote:
>>> xcb_window_new
>>> xcb_glx_create_context.
>>
>> I love this. But I still want to release on Friday, and I kind of hate
>> to break everyone's code just before release. Of course, we're not going
>> to break it afterwards, so now is the time if it's going to happen.
>>
>>> XcbWindow
>>> XcbGlxContext
>>
>> I don't love this quite as much. I'd be OK with following Cairo's
>> example of xcb_window_t or something.
>>
>> This should let us eliminate the distinction between *Rep, which is a
>> type, and *Reply, which is a function -- using *_reply_t and *_reply
>> would be nice. If there are more abbreviations in the auto-generated
>> names, we should eliminate those too: for example, *Req would become
>> *_request_t.
>>
>> Thoughts on CARD8 etc.? It would be good if we were using a different
>> name than Xlib uses: the current hack to make that work is painful.
>>
>>> We think this would be much easier to read.  What's everyone think?  This=
>> =20
>>> would require changes to ecore/x11/mesa/xcb-utils etc. But nothing a good=
>> =20
>>> sed script wouldn't be able to handle.
>>
>> If we have a prototype source conversion tool by, say, about 8am UTC
>> tomorrow, then I'd seriously consider this proposal.
>>
>> I also want feedback from others on how awful this mechanical change to
>> the API is for them though.
>>
>> It'd help a lot if someone also put together the patch to c-client.xsl
>> that generates the desired naming convention, and posted the
>> git-format-patch output to the list. Note a complete solution in the XSL
>> probably requires making sure it can find word boundaries in xcb-proto
>> names. That may require small changes to some xcb-proto declarations.
>>
>> --Jamey
>>
>> --liOOAslEiF7prFVr
>> Content-Type: application/pgp-signature; name="signature.asc"
>> Content-Description: Digital signature
>> Content-Disposition: inline
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.5 (GNU/Linux)
>>
>> iD8DBQFFCFZVp1aplQ4I9mURAua1AJ9WqLiT4rXLdRnw3c/14w4i7zkVNACfVd7Y
>> 0K8A2aBEdUXHEco535y+TU0=
>> =d9Zm
>> -----END PGP SIGNATURE-----
>>
>> --liOOAslEiF7prFVr--
>>
>> --===============0216440475==
>> Content-Type: text/plain; charset="us-ascii"
>> MIME-Version: 1.0
>> Content-Transfer-Encoding: 7bit
>> Content-Disposition: inline
>>
>> _______________________________________________
>> Xcb mailing list
>> Xcb at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/xcb
>> --===============0216440475==--
> _______________________________________________
> Xcb mailing list
> Xcb at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xcb
>
> -- 
> Ce message a été vérifié par MailScanner
> pour des virus ou des polluriels et rien de
> suspect n'a été trouvé.
> Message délivré par le serveur de messagerie de l'Université d'Evry.
>
>