[Xcb] XML description of GLX conditional reply lists

[Jeremy A. Kolb]

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