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. 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.
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'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.
I might toy around a bit with writing it :)
That would be interesting, and very useful if you succeed. Good luck! -- Greg _______________________________________________ Pygui mailing list [email protected] http://mail.python.org/mailman/listinfo/pygui
