[Pygui] Native wrappers?

[Dan Villiom Podlaski Christiansen]

On 11 Dec 2009, at 22:48, Greg Ewing wrote:

> Dan Villiom Podlaski Christiansen wrote:
> 
>> The current implementations, however, use third party wrappers for platform
>> specific frameworks. Wouldn't this prevent PyGUI from being considered for
>> inclusion?
> 
> Well, that doesn't seem to have stopped Tkinter from being included,
> so I wouldn't say it's impossible, but I agree that it's not an
> ideal situation, and I'd like to get away from all third-party
> dependencies eventually.

Isn't the dependancy of Tkinter on a non-Python library? I can image that Python depending on Python libraries would create all sorts of nasty bootstrapping issues :)

> It would be nice if it could be done purely in python, using ctypes.
> For gtk and win32 this would be straightforward, since the interfaces
> are all plain C calls (although some work would be needed to rebuild
> the MFC framework functionality I'm currently relying on).
> 
> I'm not sure what to do about Cocoa, though. It's not obvious how
> to access objective-C functionality through ctypes, if it's even
> possible at all.

Technically, it *is* possible, as all Objective-C method calls are implemented as function calls to objc_msgSend, objc_msgSendSuper and specialised versions of them for methods returning struct or floating point values. (This is probably why Apple claims that Objective-C calls are ‘only’ twice as slow as C calls; every ObjC call *is* in fact two C calls.) However, I *really* don't think following that path is a good idea, as you'd have to re-implement parts of the Objective-C runtime, and which function calls to use even depend on architecture. (For example, ‘objc_msgSend_fpret’ isn't used on PowerPC.)

Or to put it another way; accessing Objective-C using ctypes is possible in theory, but not in practice :)

>> For what it's worth, my brief experience with PyObjC is that it's
> > *very* slow to just import;
> 
> Yes, I've noticed that too, and it's a nuisance. I think PyObjC is
> going to a lot of trouble to make things look nice to the Python
> programmer, and it has a cost. PyGUI doesn't need any of that -- it
> doesn't matter if the interface is ugly, since the user of PyGUI
> isn't going to see any of it.
> 
> Another possibility of course is to write an extension module that
> exposes the needed parts of Cocoa.

I think implementing all (or most) of the wrapper in Objective-C is the past of least resistance. So far, I've begun implementing the Events module as an Objective-C extension; although I haven't tested it yet, it seems doable to me.

Eventually, it might be feasible to create some utility functions/classes to ease the implementation of wrappers.

>> I've checked the source code, and it seems that the starting point
> > for implementing a native Cocoa wrapper would be Applications and Events
> > modules. Is this correct?
> 
> Yes, that's probably about right. Essentially you should just work
> your way numerically through the tests, implementing what you need
> to make each one work. You may need to stub some things out in the
> early stages, e.g. menus, since the core of the framework is
> fairly intertwined.

Cool!

One thing, though; Apple's Foundation and CoreFoundation libraries use 16-bit characters for their string implementations. Would it be valid to only support UCS-2 builds, or should both kinds of build be supported?

If supported, UCS-4 builds would incur a performance penalty: strings would have to be translated when passed between Python & Objective-C. For UCS-2 builds, however, NSStrings can be created from unicode objects with neither copying nor converting them. (I once wrote a bit of code doing this, for a dummy Objective-C loader. The loader itself never got very far; I stalled at decoding Objective-C type encodings. But the simple string converter, I did write…)

>> I might toy around a bit with writing it :)
> 
> That would be interesting, and very useful if you succeed.
> Good luck!

Thanks :)

--

Dan Villiom Podlaski Christiansen
danchr at gmail.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1943 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pygui/attachments/20091211/391bc303/attachment.bin>