Disabling window management code

[luper]

Pyglet is currently not working on Mac OSX Snow Leopard, because of a
compatibility issue [1] between carbon and 64 bit python, and cocoa
support doesn't seem to be on the way.

In my case, I don't need the window and context management, because I
use pyglet in a PyQt application, just for its OpenGL bindings and the
buffers/texture/etc.. abstraction library.

Would that be possible to add an option to completely disable the
window and context management in pyglet without breaking everything ?
I have some time to contribute a patch, but I would like to know if
this is a silly idea first.

[1] http://groups.google.com/group/pyglet-users/browse_thread/thread/4968e9ab69a6661c

--
Lup

[Richard Jones]

On Fri, Feb 26, 2010 at 12:05 PM, luper <luper...@gmail.com> wrote:
> Pyglet is currently not working on Mac OSX Snow Leopard, because of a
> compatibility issue [1] between carbon and 64 bit python, and cocoa
> support doesn't seem to be on the way.

pyglet works on Snow Leopard using a 32-bit Python. I'm currently
using 2.6.4 from ActiveState.

Richard

[luper]

On 26 fév, 10:28, Richard Jones <r1chardj0...@gmail.com> wrote:

> On Fri, Feb 26, 2010 at 12:05 PM, luper <luper.ro...@gmail.com> wrote:
> > Pyglet is currently not working on Mac OSX Snow Leopard, because of a
> > compatibility issue [1] between carbon and 64 bit python, and cocoa
> > support doesn't seem to be on the way.
>
> pyglet works on Snow Leopard using a 32-bit Python. I'm currently
> using 2.6.4 from ActiveState.
>
>       Richard

Yes I'm aware of that, but I actually need a 64 bits Python for this
app.

[Florian Bösch]

Where's the cocoa effort concentrated?

[Tristam MacDonald]

On Fri, Feb 26, 2010 at 5:02 AM, Florian Bösch <pya...@gmail.com> wrote:

Where's the cocoa effort concentrated?

It isn't.

I wrote a first stab implementation, which has most of its features working, but needs a lot of tender loving care.

I am happy to send the files to whoever can further develop them, but I don't have access to a Mac anymore.

--
Tristam MacDonald
http://swiftcoder.wordpress.com/

[Bruce Smith]

On Thu, Feb 25, 2010 at 5:05 PM, luper <luper...@gmail.com> wrote:

....

Would that be possible to add an option to completely disable the
window and context management in pyglet without breaking everything ?
I have some time to contribute a patch, but I would like to know if
this is a silly idea first.

I think an option to disable initializations which get in the way of using pyglet in existing OpenGL contexts, if implemented cleanly, would be a good idea.

- Bruce

[Tristam MacDonald]

Keep in mind that pyglet's font renderer (and thus all text capabilities) are also tied to Carbon, so you would have to throw all that functionality out as well.

I have a basic Cocoa font renderer as part of the port effort, but again, it requires some major tweaking and polishing for production use.

 

[Florian Bösch]

On Feb 26, 1:12 pm, Tristam MacDonald <swiftco...@gmail.com> wrote:
> I am happy to send the files to whoever can further develop them, but I
> don't have access to a Mac anymore.

This could be opened as a branch to pyglet mainline, so it can be
improved by whoever has access to a mac.

[luper]

On Feb 27, 11:39 am, Florian Bösch <pya...@gmail.com> wrote:
> This could be opened as a branch to pyglet mainline, so it can be
> improved by whoever has access to a mac.

I've implemented the option by avoiding a few imports here and there,
my app starts, but then even basic things like creating textures are
broken because they are tied in some way to context management
(getting GL version, etc...).

So, it seems implementing this option can't be done the quick and
dirty way, I'd rather be working on a cocoa port. Tristam could you
send me your patches, or perhaps create the branch so I can work on
it ?

Thanks

[Tristam MacDonald]

On Mon, Mar 1, 2010 at 8:15 PM, luper <luper...@gmail.com> wrote:

On Feb 27, 11:39 am, Florian Bösch <pya...@gmail.com> wrote:
> This could be opened as a branch to pyglet mainline, so it can be
> improved by whoever has access to a mac.

I've implemented the option by avoiding a few imports here and there,
my app starts, but then even basic things like creating textures are
broken because they are tied in some way to context management
(getting GL version, etc...).

If you are in a 64-bit app, you can't make any calls to Carbon's 32-bit AGL library - and that is pretty much everything in OpenGL.

 

So, it seems implementing this option can't be done the quick and
dirty way, I'd rather be working on a cocoa port. Tristam could you
send me your patches, or perhaps create the branch so I can work on
it ?

I am a bit hesitant to create a new branch without a maintainer, so I will send to you, and leave that up to your discretion. 

[Florian Bösch]

On Mar 2, 2:30 am, Tristam MacDonald <swiftco...@gmail.com> wrote:
> I am a bit hesitant to create a new branch without a maintainer, so I will
> send to you, and leave that up to your discretion.

Well, we're anyway operating on the principle that whoever gets stuff
done does "maintain" something, so if the source to that branch is
"query it from Tristam" that pretty much ensures almost nobody will
check it out just to see how things are, and decide to take it up. It
really is a 1:1 thing, and that's not good in a distributed source
control, where things should be n:m.

[Richard Thomas]

I'd like to help with this effort. If there was a real branch for it I
would try and work on it. If the branch doesn't get to production
quality then so be it but we need to have it if we're going to be able
to discuss it and work on it.

Chard.

[Tristam MacDonald]

All right then. Attached is what I believe to be the most recent version, and it should be enough to run the hello_world.py included. Unfortunately, this was rescued off a backup drive, and I have no Mac available to test it.

Note that I have enabled the cocoa backend only for 64-bit machines, by testing the value of sys.max_int wherever platform specific files are imported.

Briefly then - what works:

• The window creation code is pretty solid, though we never found a truly solid solution for multiple fullscreen windows.
• Font rendering is working, but needs some tweaking of kerning, etc.
• Basic input events are there, but not any of the window status events.

Feel free to commit it to a branch, etc.