On 12 Dec 2009, at 03:53, Greg Ewing wrote: > Dan Villiom Podlaski Christiansen wrote: > >> 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 :) > > Not sure what you mean by that. My point is that Tkinter is in > the stdlib despite requiring a library (tcl/tk) that isn't bundled > with all versions of Python and isn't necessarily available on > all systems. More recently there's sqlite.
What I was referring to is that Tkinter isn't a Python library and doesn't require Python to compile. PyObjC and the other wrappers, however, do. >> Or to put it another way; accessing Objective-C using ctypes is possible in >> theory, but not in practice :) > > Hmm. Maybe some of the chores of selecting the right functions > to call could be taken care of by a wrapper layer? It could; Objective-C is quite dynamic and reflective. There is the problem of *types*, though: All Objective-C method selectors contain an encoded type signature. It would be necessary to find a way to convert structures, strings, data and whathaveyou to/from the two implementations. However, such an implementation would likely also to require a rewrite of most of the current implementation. I don't see what the advantage to that would be? From my perspective, writing the wrapper directly in Objective-C doesn't seem that much harder :) >> I've begun implementing the Events module as an Objective-C extension; > > although I haven't tested it yet, it seems doable to me. > > The Events module is probably one of the easier ones, since the > Event class is pretty self-contained. Some other parts may be > trickier -- there are some places where I've made use of the > ability to subclass an Objective-C class in Python and override > its methods. You may need to do that as an extension type > wrapping an Objective-C subclass of the relevant NS class. ‘_PyGui_NSApplication’ is an example of this, right? > If you're interested, I could look into extending Pyrex with > some syntax for making Objective-C method calls. I'm not terribly familiar with Pyrex myself, but I'm sure other people would appreciate such support :) >> 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: > > I think dropping UCS-4 capability for this reason at this stage > would be premature optimisation. I can't really see passing strings > being a performance bottleneck in most situations. Good point. Fortunately, I figured out how to create an NSString that would refer to the buffer of a PyUnicodeObject in a way that *should* work with both kinds of build. If you're interested, I put what I have so far here: <https://bitbucket.org/danchr/pygui/src/tip/GUI/Cocoa/> -- 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
