[Pygui] Native wrappers?

[Dan Villiom Podlaski Christiansen]

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
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/20091213/b0f83bfb/attachment.bin>