[Xcb] XML description of GLX conditional reply lists
Jeremy A. Kolb
jkolb at brandeis.edu
Wed Nov 29 11:19:38 PST 2006
On Wed, 29 Nov 2006, Jamey Sharp wrote:
> On Wed, Nov 29, 2006 at 08:07:40AM -0500, Jeremy Kolb wrote:
> > Jamey,
>
> Hi Jeremy!
>
> > I hate those requests so much.
>
> Hehe. I'm composing a mail about XKB; GLX is nothing. ;-)
>
> > As far as I know they're the only ones with this format... I'm not
> > sure we want to change the XML just for these functions.
>
> What do we want the XML to do? I think right now we want it to describe
> the protocol as fully as needed to generate C code, because we don't
> have anyone actively contributing requirements here on anything but the
> C binding. Currently the XML can't correctly describe GLX: it claims
> there's one list element when there isn't. However, the XML is still
> quite flexible, so maybe all we want is something like a
> stupidglxgetlistfromfield="datum" attribute on the list element.
>
> And how much convenience should the C binding provide? Bart generally
> argues that XCB should support common C idioms and feel reasonably
> natural to C programmers. I'm not opposed to that policy, but it's more
> important to me that it support direct and predictable access to the
> protocol, and that its interface is minimal and orthogonal. In this
> case, making the list return more natural doesn't in any way prevent
> directly examining the protocol response and doesn't really change the
> API, so I'm for it.
>
In the case of these requests what do you want the C code we generate to
look like? Are you thinking that we'd always return the list and that XCB
would add the one reply value to the list if need be? I'm just not sure
how common this case is.
> Randr1.2 was a different case, in my mind, because the protocol could be
> adequately described for a sufficient C binding already. As we add more
> language bindings, I expect the XML will grow accordingly, and we may
> add things like subevent codes then.
>
> > A glx utility library might be a nice thing to have for these and
> > other functions...
>
> I think currently that library is called "Mesa". ;-)
>
Haha no Mesa is WAY more complicated. ;) I was thinking more along the
lines of a few convenience functions... but I don't think the need is that
dire.
> --Jamey
>
Jeremy
More information about the Xcb
mailing list