[Xcb] XCB naming conventions technical problems

[Josh Triplett]

Vincent Torri wrote:
>> What do import.py, size.py  and type.py do? They do not seem
>> to be called before the xsl processor gets called?
> 
> I don't know

Random experiments Jamey did in Python which you can safely ignore for now.

>> * Within the stylesheet there are a lot snippets like
>>
>> ..."XCB{$ext}Init"...
>>
>> If I transform them to
>>
>> ..."xcb_{$ext}_init"...
>>
>> and $ext is empty because it is an unqualified type the
>> result will be
>>
>> "xcb__init"
> 
> It's normal, as that string is present only in extension files. I have 
> solved that by changing in the extensions xml description the 
> extension-name field with _render instead of Render (for the render 
> extension), and use :
> 
> xcb{$ext}_init

Please don't do that; the extension name in the XML protocol
descriptions should continue to read "Render", or perhaps "render".
Instead, you should define a function to make a name.  You can define a
function with the EXSLT function extension like this:

<func:function name="xcb:struct-name">
  <xsl:param name="name" />
  <func:result>
    <xsl:text>xcb_</xsl:text>
    <xsl:if test="$ext">
      <xsl:value-of select="$ext" />
      <xsl:text>_</text>
    </xsl:if>
    <xsl:value-of select="$name" />
    <xsl:text>_t</xsl:text>
  </func:result>
</func:function>

You will need to declare the function extension and the function
namespace at the top of the xslt; add
xmlns:func="http://exslt.org/functions" and
xmlns:xcb="http://xcb.freedesktop.org" to the attributes on the
xsl:template root element, and add "func" and "xcb" to
extension-element-prefixes.  You can then call the function from an
attribute-value-template like this:

<something attr="{xcb:struct-name($name)}" />

The EXSLT function extension has implementations in various XSLT
processors, including xsltproc, and I believe we can safely use it.

>> * Renaming types e.g. from WINDOW to window_t can be done in
>> two places: In xproto.xml or by appending "_t" in various
>> places in c-clients.xsl.
> 
> definitely not in xproto.xml

No, definitely not.  If we need to change the protocol descriptions at
all, it would only consist of lowercasing names and using a separator
(space or dash or underscore), to make it easier to split words in
c-client.xsl.

>> After giving up (there were more problems), I did a small
>> xml->c converter for a subset in python which seems to me
>> simpler and better readable (although less error checking
>> presently). This raises the question: would a move from xsl
>> to python be viable or is python too much of a dependency?
> 
> I remember that someone (Josh, iirc) wanted to do something in python, but 
> I can't remember if it was for the generation of the header / source 
> files.

Both Jamey and I have talked about using the XML protocol descriptions
from Python; it makes some things easier and others harder.  I wouldn't
suggest it for before the release though.

- Josh Triplett


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20060914/7a08caa9/signature-0001.pgp