[Xcb] Thomas Coppi's Objective-C binding

[Thomas Coppi]

-----BEGIN PGP SIGNED MESSAGE-----
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

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

iD8DBQFEZRX8lU6kaExSKKoRAmUEAJ9Dt+3K4kNjkKUOcN08bwEBFp8+yACg02Rs
Rty5ieP/2raPFBbBu9MKTaY=
=U7/9
-----END PGP SIGNATURE-----