On Thu, Mar 26, 2009 at 2:30 PM, Alex Holkner <[email protected]> wrote: > > > 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
Are the ambitions of the features begun in the trunk documented anywhere? I'm inclined to help, but I only have the vaguest notion as to what is needed. I'd hate to see the project start to die on the vine due to lack of available developer time. -Casey --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
