Re: Thomas Coppi's Objective-C binding

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.

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

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.

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.

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

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

--Jamey

signature.asc
Description: Digital signature

_______________________________________________
Xcb mailing list
Xcb-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@xxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/xcb