[Xcb] Thomas Coppi's Objective-C binding

[Josh Triplett]

Thomas Coppi wrote:
> Jamey Sharp wrote:
>>> Hi Thomas!
>>>
>>> On Tue, May 09, 2006 at 07:24:11PM -0700, Thomas Coppi wrote:
>>>> ... Objective-C can function as C for all intents and purposes ...
>>>> The bindings to Objective-C would therefore consist of mostly an
>>>> encapsulation of core XCB functions and routines into Objects that
>>>> hide the complexity of calling the functions directly, and simplify
>>>> the usage of them as common functions with similar functionality or
>>>> scope can be grouped together.
>>> Now I'm confused about what you hope to accomplish. I'm inclined to say
>>> that there are two sensible design options for your Objective-C binding.
>>>
> What I was trying to say is that Objective-C doesn't need a glue layer
> between it and calling the XCB functions directly.  For example, in
> perl, there would need to be .XS files that told perl how to interact
> with the XCB library.  In Objective-C, that isn't needed, because it
> basically is C.

That does make sense, yes.  Even if you want to make a wrapper, you
could always make it call the C API rather than reimplementing the C API.

>>> It could closely follow XCB's API but provide a better fit to object
>>> oriented idioms. A Java binding, for example, would provide
>>> implementations of the standard java.lang.Iterator interface for each of
>>> XCB's iterators. It might also be reasonable to provide a Window class
>>> where creating a new instance allocates an XID, and then methods support
>>> the CreateWindow, MapWindow, and other related calls. The binding should
>>> also handle memory management, placing XCB's malloc'ed responses under
>>> the care of the garbage collector.
> 
> Yes, that is pretty much what I had in mind.
> 
>>> All of this code should be
>>> auto-generated if possible, because it should express general rules for
>>> "object-izing" the X protocol and should work for all extensions as
>>> well.
> 
> Ok, now I see what you meant by auto-generating.  I agree, this is
> definitely necessary for completion in a timely manner, as well as for
> extensions in the future.  I didn't do something like this for the
> sample code because I was pressed for time.

Of course; you definitely want to experiment with a few functions first,
before attempting to autogenerate full bindings.

> You mentioned something about xml files containing the descriptions of
> XCB's core functions?  I have found ones for extensions and
> xcb_types.xml and xproto.xml, but maybe I just wasn't looking in the
> right place.  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. :)  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.

>>> On the other hand, you could provide a higher-level interface. From our
>>> point of view, though, anything higher-level then XCB is either a
>>> utility library or a toolkit. Toolkits are large, complicated, and
>>> difficult to design and build -- too big for a summer. Utility libraries
>>> are built for a single purpose, such as event handling, and any one
>>> library is probably too small for a summer.
> 
> Understood.

And in any case, a full language binding to XCB will almost always make
for sufficient work for a summer, if not more. :)

>>> It seems to me that you've tried to go somewhere between these schemes:
>>> mostly provide the XCB API directly, but add some stuff here and there.
>>> I bet everyone will be happy if you provide one library that follows the
>>> first approach, and later provide separate libraries for exploring
>>> things like event handling.
>>>
>>> I think for Summer of Code you probably have time to build a
>>> straight-forward ObjXCB binding and at least one utility library, such
>>> as the event loop you want.
> 
> That seems like the best way to proceed.
> 
>>>> My biggest question about how to proceed is how to interface with
>>>> events.  I would like there to be an event-loop system if possible,
>>>> similar to Gtk+, so that there is less complexity to the user
>>>> application, but it should also be able to handle interfacing with
>>>> network sockets.  It also must be asynchronous to properly deal with XCB
>>>> replys.  I probably need some sort of internal queue to deal with that
>>>> correctly.  I have edited my application to reflect some time at the
>>>> beginning to research ways to do this.
>>> I gather you're trying to design some combination of the event and reply
>>> libraries in xcb-util, while adding file-descriptor monitoring. That's
>>> ambitious, but OK. :-) Provide a direct interface to XCB's event
>>> handling first, and as you're building the simple binding we can discuss
>>> what an event-loop library in Objective-C should look like.
> 
> Yes, that is an accurate description of my thinking.  But I agree, that
> really doesn't have a place in a simple language binding.

Well, it depends.  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.  So the concept of a "language
binding" doesn't always preclude additional functionality.

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.

- Josh Triplett

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20060512/560fc2ca/signature.pgp