On Sat, Sep 12, 2009 at 9:01 AM, Tristam MacDonald <[email protected]> wrote: > 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.
I don't know Cocoa (maybe someday I'll have time to learn), and I have very little time, but I might be able to pitch in some testing time when you get close. My department is running Snow leopard on 13"/15" MBPros and SL Server on an Xserve already. ~ Nathan --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
