[Xcb] Thomas Coppi's Objective-C binding

[Jamey Sharp]

On Fri, May 12, 2006 at 08:17:29AM -0700, Josh Triplett wrote:
> Thomas Coppi wrote:
> > You mentioned something about xml files containing the descriptions of
> > XCB's core functions?

If so, I didn't mean to. :-) The XML files describe everything *but* the
19 core functions, and a small handful of core types.

> > I would probably need to use something other than xslt, such as
> > perl, for processing the files, since xslt doesn't look very
> > conductive to outputting Objective-C, and a quick google search
> > hasn't turned up any equivalents.
> 
> Well, XSLT doesn't seem any less conducive to outputting Objective-C
> than C. :)

If you don't like XSLT for this -- for which I can't blame you -- my
favorite would probably be HaXML or CDuce. (I have yet to actually try
either, but they look awesome.) But do whatever works for you.

XSLT can output any text you want, even getting perfect indentation and
everything. But it may happen that nobody can read the XSLT stylesheet
when you're done. :-)

> The main problem here probably lies in expressiveness of the XML
> protocols; for example, making CreateWindow, MapWindow, and the
> xidtype WINDOW all part of the same class would require more grouping
> information than we currently provide.

I'm not convinced it's hard. Define a class for every xidtype, and use
the first xidtype in the request fields to decide which class to place
that request in.

In some cases, there's no xidtype in the request. InternAtom and
GetSelectionOwner are examples. (Note that an atom is not an XID.) I
think it's reasonable that these functions not be in any class, unless
perhaps it's the objectificated XCBConnection class.

Cases like DRAWABLE are a little tricky. This isn't an xidtype: it's
notionally a superclass of severall xidtypes. Treating it as a
pseudo-xidtype for the purposes of assigning methods to classes, and
getting inheritance declarations right, should suffice.

With those rules, at least the first dozen or two X requests should be
handled pretty nicely. I haven't checked further.

> Some language bindings may well need to provide add-on functionality
> in order to fit well with the language.  For example, any language
> with a concept of lazy objects, which can get evaluated when accessed,
> should probably hide the cookie mechanism behind a call that returns a
> proxy object and forces the reply when it needs to provide the data of
> that object.

The ObjXCB binding could do this too. Whether it should is an
interesting question.

> Similarly, I can imagine that in languages having a higher degree of
> type safety than C, the WaitForEvent and PollForEvent calls will need
> to figure out what event they have and construct the corresponding
> object, rather than returning an XCBGenericEvent pointer that requires
> casting.

This is probably a good idea, but quite tricky when dealing with
extensions. It may be impossible if the ObjXCB binding allows calling
directly down to XCB.

--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/20060512/7ee41a02/attachment.pgp