[Xcb] Thomas Coppi's Objective-C binding

Thomas Coppi thisnukes4u at gmail.com
Fri May 12 16:10:52 PDT 2006

Hash: SHA1

Jamey Sharp wrote:
> 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.

Sorry, I must have misunderstood.

>>> 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.

I've read CDuce's homepage, and I'm going to give it a try.  But for
now, I think perl should be expressive enough, and I am comfortable with
it, versus learning a new language.  Although I doubt perl would be any
more readable than c-client.xsl is.

> 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.

That sounds reasonable.

> 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.

Probably should be available in ObjXCBConnection.

> 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.

I'm not sure what is meant by a "lazy object."  Do you mean return an
object that forwards all messages it receives to another "real" object
that then gets the reply?

> 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.

I don't think that exposing the xids inside the Objects is a good idea.
 That would defeat the purpose of an Objective-Oriented layer.

> --Jamey
> ------------------------------------------------------------------------
> _______________________________________________
> Xcb mailing list
> Xcb at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xcb

Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the Xcb mailing list