[Xcb] Re: Update for RandR 1.2 name changes.

[Jamey Sharp]

On Nov 30, 2006, at 5:07 PM, Jamey Sharp wrote:
> Oops, these are API changes. For libxcb, at least, we're committed to
> not doing that. libxcb-randr is more acceptable to me, but if we can
> make things work without API changes I'll be happier.

On Thu, Nov 30, 2006 at 07:30:01PM -0800, Barton C Massey wrote:
> I guess I've been assuming that the only things that are at
> 1.0 and thus "sacrosanct" are XCB, Xlib, the XCB core
> protocol description, and perhaps some of the most ancient
> extensions.  Is this not a viable way to proceed?

I'd rather treat all the extensions as unfinished, for the reasons Ian
and Jeremy mention. But I didn't think I could get away with that.

This is why the extensions still have a library major version of 0, by
the way, as a fairly widely-accepted indication that the API is not
stable.

However, we never really said any of this "in public" before, and it may
surprise some of the five developers currently using XCB. ;-)

On Thu, Nov 30, 2006 at 05:41:04PM -0800, Ian Osgood wrote:
> Oh, boy. I figured only the non-generated code is actually set in  
> stone. I sincerely hope we are not setting the extension and core  
> protocol symbols in stone, because there has never been a review for  
> consistency across extensions, or even within the same extension.   
> Hell, most of the core protocol and extensions haven't ever been tested!

True. Josh and I tried to split the core protocol out of libxcb so we
could version it separately (I still have that commit on a branch
locally), but Bart wouldn't let us get away with that. So the core
protocol is API and ABI frozen now. The extensions aren't under the same
constraint though.

They are, however, published as part of a "1.0" release, and we really
shouldn't let them live much longer if they aren't actually correct.

> Also, I mistakenly named the field "mmHeight" expecting it to expand
> to "mm_height" in the C code. I will go back and substitute
> underscores for caps.

I would be happy to have the XSLT apply camel-case to underscore
conversion in field names too. It would make it easier to copy-paste
from Xlib headers and such. We just have to make sure that it doesn't
make any difference to the core protocol API and ABI.

> If these are the types of things that will become set in stone, then  
> it is high time for us to review the existing extensions.

Yes, pretty please?

> Consistent naming is very important if you don't want to be vilified
> by the next 20 years of X programmers.

Heh. It's true, nobody wants that. :-)

--Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20061201/8f88d82b/attachment.pgp