[Xcb] Re: Branch 'xspec' - xcb-proto
alp at atoker.com
Wed Mar 15 12:58:49 PST 2006
Jamey Sharp wrote:
> On Wed, Mar 15, 2006 at 12:01:19PM -0500, Jeremy A. Kolb wrote:
>> onnoff is the name given in the headers, Since we want to be true to the
>> protocol shouldn't this name remain unchanged?
> Yes. The XML files are supposed to be a representation of the wire
> protocol: if a particular binding, like XCB or XNB, needs different
> naming conventions etc. it's expected to provide them in its code
The string "onoff" is never sent down the wire. A boolean value is sent,
and that boolean value describes whether event notification is enabled.
"enabled" seems to be an accurate description of the field while "onoff"
looks like a mistake in the spec. I have a more complete justification
in my previous message. If I'm missing the point here, would be quite
willing to revert the change.
> Alp, you're doing a lot of work to change things that I'm not sure
> should be changed: XML-XCB attribute names (opcode->number), type names
> (WINDOW->Window), and occasional field names (onoff->enabled). Remember
> that XCB needs to use the same files, so if you ever want to merge your
> changes you need to be talking to the rest of us. What's your plan here?
The opcode -> number change was made to remove the need for a special
case in server code. I'm quite surprised that you don't appreciate the
simplification for the C server binding generator. It's no great deal,
but it makes life just a little bit easier at no extra cost. Again,
would be quite happy to revert this if I've got things wrong.
As far as the naming changes go, the rationale is that you can easily go
from GContext to GCONTEXT, but not the reverse. It seems that without
the changes I've made in the xspec branch, replacing the protocol header
files will be quite unintuitive. If you don't replace them, you're still
left maintaining a minimum of two copies of the protocol for another 20
Perhaps for you this is less of an issue, but non-C language bindings
can't depend on anything in /usr/include/X11
You'll find that other changes I've made actually _remove_ xlibisms that
have crept into the XCB protocol spec and have replaced or am in the
process of replacing them with the actual name from the protocol
For example, "DontPropagate" doesn't look good to me, but it starts to
look even worse when you realise that it was actually meant to be
"DoNotPropagateMask" all along. They got it right, then you got it wrong
when you decided to copy-and-paste from xlib instead of working from the
X11 protocol documentation.
I'm working on identifying patterns to simplify bitmasks and valueparams
right now. Replacing the union element with something closer to the
desired type model is on my todo list; any extension is free to create a
new xid type that is also a Drawable, and unions, while they might be a
handy way of representing that relation in C, are certainly not what the
X11 protocol specs have in mind and don't seem to belong in a protocol
description. It just doesn't click.
Isn't XCB a great opportunity to get these things right?
More information about the Xcb