On Fri, Sep 11, 2009 at 1:08 PM, Tristam MacDonald <[email protected]>wrote:
> As some of you know, the release of Snow Leopard signals the end of Carbon > development on the Mac, and pyglet's reliance on Carbon prevents us from > running pyglet on a stock Snow Leopard install. > The solution to this is to write a new platform backend in Cocoa, but > unfortunately this is going to be a fair amount of work. I have had this in > private development for a while, and in terms of a functioning alpha, past > the 50% mark. However, development is fairly slow, so if there are any > others here with the requisite knowledge, skills and time, I would like to > open it up for collaboration... > > Here is a brief overview of the current status: > > - windowing: basic window and fullscreen working > - events: cocoa event loop hijacked successfully, but not yet piped > into pyglet events > - fonts: not implemented - using buggy freetype fonts via the installed > freetype library for X11 > - codecs: quicktime codec disabled - needs to be adapted to newer > QuickTime API > > Challenges: > > - PyObjC: the Python <--> Objective-C language bridge is confusing, > badly documented, and has missing functionality in places > - Cocoa: the framework is designed to manage its own run loop, thus we > have to subvert a lot of functionality (and guess at how it is > implemented). > Luckily the SDL project (and myself) pioneered a this a few years back. > > So, if you have really deep knowledge of Cocoa (and plentiful free time, of > course) I could use your help right away - let me know, and we can figure > out collaboration. > > If you don't know Cocoa that well, but do know your way around the > debugger, stay tuned, because this is going to require a horrendous amount > of testing before we approach a release... > First off, a brief status update: I now have a functioning (albeit basic) Cocoa font renderer, and pyglet-cocoa can now execute the hello_world.py, although event handling is still entirely missing. Now, a question for the design/architecture committee (I guess that would be Alex). How is pyglet's multiple window support intended to interact with fullscreen support? i.e. should it be legal for an application to have multiple windows, of which some are fullscreen and some are not (particularly in multiple monitor/GPU setups)? The reason I ask is that there are some very thorny issues related to event handling in this situation. As long as all windows are *not* fullscreen, we can retrieve each window's event queue separately - but as soon as one window becomes fullscreen, we have to retrieve events application-wide, and manually handle hit detection and event dispatch for the window system. -- Tristam MacDonald http://swiftcoder.wordpress.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~----------~----~----~----~------~----~------~--~---
