I'm no authority and don't have any Cocoa knowledge, but I do have two things to say:
1. Thank you so much for doing this! 2. Do the least amount of work possible to get it working. For now, it sounds like that means disallowing mixed fullscreen/non windows. Keep at it, and send a build my way if you need testing done. I'm using Leopard on a Core 2 Duo MBP. On Sep 12, 11: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. > > -- > Tristam MacDonaldhttp://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 -~----------~----~----~----~------~----~------~--~---
