On 27/03/2009, at 8:15 AM, Bruce Smith <[email protected]> wrote:
> > > On Thu, Mar 26, 2009 at 1:23 PM, Alex Holkner > <[email protected]> wrote: > ... > 1. Let the toolkit create the OpenGL context, and trick pyglet into > using that context without creating its own. > ... > It sounds like you want (1), and it's probably the easiest. The main > issue is getting pyglet to believe there is already a valid context > bound. Disable the shadow window, because you won't be needing it. > Then set a mock context object for pyglet.gl._current_context (you'll > have to write the class for this mock object yourself). > > Right, this is what Crispin wanted and what I got halfway working > (with debug_gl disabled rather than the mock context). > > If we end up with a clean version of this kind of example, where is > the best place to put it so the next developers don't have to search > the archives again? > We used to have community pages for this sort of thing, but we were forced to close them due to spam. We don't have anything comparable at the moment. > These are all very much hacks because integration with other toolkits > was never a design goal of pyglet (in the original discussions Richard > and I shared, I don't think it was even brought up as a possibility!). > > > Another use case would simply be to let pyglet windows and other- > toolkit windows coexist in the same application, but with no > interaction or relation between them. I just tried "Bruce the > presentation tool" and I think it did something like this, since it > put up a Tk file chooser to get going. But this was entirely > "serial" rather than "parallel" -- I guess it would be harder to > support both windowing toolkits at once, since the two "event loops" > would have to coexist. But for letting a pyglet program access a > file chooser or color picker from the OS, it might be easy enough > and useful (since we can stand suspending pyglet while the > specialized dialog is up). (So my question about where to put > examples of this kind of thing, if we write any, applies to this too.) > Actually in these cases it would be much simpler to expose the platform's dialogs as additional pyglet features. > == > > I made some headway into refactoring the context, window and a new > canvas class in pyglet-1.2dev (SVN trunk), but this is not in a > releasable state. > > Is this what I see in the svn trunk right now? I assumed that was > essentially identical to the 1.1.3 release. The 1.1.3 release is from the pyglet-1.1-maintenance branch. The trunk contains an ambitious refactoring of pyglet that attempts to retain backward compatibility while supporting some new features that weren't possible in the old design. It's unlikely to be released, however. Alex. > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
