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 [email protected]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Pygui mailing list [email protected] http://mail.python.org/mailman/listinfo/pygui
