Indeed - I was hoping to use something use a common subclass already inside Pyglet like BaseWindow, but because it uses a metaclass and so does Gtk3 (gobject), they wouldn't mix.
Instead I tried creating my own event dispatcher and hooking up render->on_draw and resize->on_resize https://github.com/stuaxo/embed-pyglet/blob/develop/glem/pyglet/gtk3/__init__.py Will have to see what this looks like when more events are hooked up. Pyglet has a thing called "platform_events" - should I be using this, I couldn't work out what they do / how to use them ? Gtk GlArea seems to only want ModernGL, so I get messages like "operation not permitted", is there an example somewhere to draw a cube using modern gl? If not, I was going to write something similar to https://github.com/tartley/gloopy/blob/master/gloopy/shapes/cube.py#L34 which is the closest to how I think already. On Wednesday, August 30, 2017 at 2:00:05 AM UTC+1, Benjamin Moran wrote: > > Looking at the code you linked earlier, the dummy context is one part that > we may be able to tweak on pyglet's side. If you try binding other > frameworks (such as GTK) and come across a similar requirement, let us > know. I haven't looked at this code in a while, but it might be something > that's reasonable for us to do in pyglet. > > > On Wednesday, August 30, 2017 at 8:45:46 AM UTC+9, Stu.Axon wrote: >> >> OK, great .. doing this outside makes sense. >> >> If I make any progress I'll come back with some questions, it would be >> good to build things in a pyglet-esque kind of way. >> >> >> >> On Tuesday, August 22, 2017 at 5:56:07 AM UTC+1, Benjamin Moran wrote: >>> >>> I like that idea as well. It probably would avoid code stagnation that >>> way as well. >>> >>> >>> On Monday, August 21, 2017 at 5:53:56 PM UTC+9, Rob wrote: >>>> >>>> It could also be a separate package in the cheese shop. But indeed, >>>> somebody needs to be able to maintain it. >>>> >>>> Rob >>>> >>>> On 21 August 2017 at 09:58, Benjamin Moran <[email protected]> wrote: >>>> >>>>> Hi Stu, >>>>> A lot of the code seems to be glue to match up the methods. It doesn't >>>>> seem like there is any way around it, because the pyglet methods need to >>>>> be >>>>> called in order to update some internal things, in this case by the >>>>> coresponding QT methods. The dummy context is Since it's so specific, It >>>>> wouldn't make much sense to include this inside the main pyglet codebase. >>>>> >>>>> It might be useful to have this type of shim code in the /contrib folder >>>>> on >>>>> BitBucket, however, if someone wants to write and contribute it. >>>>> >>>>> >>>>> >>>>> >>>>> On Friday, August 18, 2017 at 8:58:30 AM UTC+9, Stu.Axon wrote: >>>>>> >>>>>> Hi, >>>>>> I wonder if Window could be changed to make embedding it in Qt, >>>>>> Gtk or anything that has an existing GL context easier. >>>>>> >>>>>> I looked at how QPygletWidget [1] works, and a fair bit it seems to >>>>>> be mocks and stubs. >>>>>> >>>>>> Are there any changes that could be made on pyglets end to make these >>>>>> stubs and workarounds unnecessary ? >>>>>> >>>>>> >>>>>> [1] QPygletWidget by ColinDuquesnoy >>>>>> >>>>>> https://github.com/ColinDuquesnoy/QPygletWidget/blob/master/qpygletwidget.py >>>>>> >>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "pyglet-users" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To post to this group, send email to [email protected]. >>>>> Visit this group at https://groups.google.com/group/pyglet-users. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> > -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
