[Xcb] Thomas Coppi's Objective-C binding

[Thomas Coppi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

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

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.

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

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

>> I don't think that simply leaving events out in the open is an
>> acceptable way of handling this.
> 
> That depends on what you're trying to do. Remember that XCB is not
> intended for most programmers to use directly: we expect toolkits and
> libraries to be layered on top to ease common tasks. The guiding
> principle is that if something can be done using only existing public
> XCB functions, then no new code should be added to XCB to support it. So
> "leaving events out in the open" is absolutely acceptable for XCB and
> ObjXCB: an event loop can be built separately.

Thanks for clearing this whole thing up.
> 
> --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

iD8DBQFEZJjplU6kaExSKKoRAiKIAKChxak6f494q63R9d5W2vte7cJGTACgi/hr
VNpHFv2hoaJIlf1qMB7qtAU=
=HN+6
-----END PGP SIGNATURE-----