I'm using pyglet 1.1.4 with 32-bit python 2.7 (for compatibility with
a specific app). I have a mac with 10.8.2 with retina display.
On the mac, I just updated the firmware this morning. After the
update, using full-screen mode had several notice-able issues:
- the top and bottom edges of the screen were black, as if cropped
- the mouse position was no longer in sync with the screen
coordinates. clicking the mouse worked but was reporting different
coordinates (based on the discrepancy between mouse position and
screen display changes that depend on the mouse, like clicking in a
box).
- after quitting the pyglet-based app (PsychoPy), back in the mac's
Finder, I could no longer use the mouse to activate hot-corners of the
screen. if I go into system preferences and reset the hot-corners it
works, or reboot. so it seems like the mouse-position mismatch is
carrying over into the finder after using pyglet.
I'm amazed you can get 1.1.4 working on OS-X at all. I've never gotten it to work. It is _very_ old.
I'm also surprised you're using 32-bit python. Any reasons? I'm using 64-bit with pyglet with no issues (using my steps above). I'm sure the steps will still work for 32-bit if you have dependencies that require it.
That being said, I tried Rabbyt with Pyglet 1.2 (from repository) on OS-X and had the mouse co-ordinate issue you mention. This wasn't present on Windows (although I tried it a while before trying on OS-X, so it may be present on both). Probably good to raise it as an issue, as I didn't.
On Sunday, September 23, 2012 1:51:33 AM UTC+10, Jeremy Gray wrote:
> I'm using pyglet 1.1.4 with 32-bit python 2.7 (for compatibility with > a specific app). I have a mac with 10.8.2 with retina display.
> On the mac, I just updated the firmware this morning. After the > update, using full-screen mode had several notice-able issues: > - the top and bottom edges of the screen were black, as if cropped > - the mouse position was no longer in sync with the screen > coordinates. clicking the mouse worked but was reporting different > coordinates (based on the discrepancy between mouse position and > screen display changes that depend on the mouse, like clicking in a > box). > - after quitting the pyglet-based app (PsychoPy), back in the mac's > Finder, I could no longer use the mouse to activate hot-corners of the > screen. if I go into system preferences and reset the hot-corners it > works, or reboot. so it seems like the mouse-position mismatch is > carrying over into the finder after using pyglet.
basically its 32-bit python for compatibility / dependencies with
various packages required for the main app I work on (PsychoPy). maybe
its time to revisit that, and see if we can move to a more recent
version of pyglet. I'll put that forward to see what the lead dev
thinks of it.
anyway, it seems like I should first move away from pyglet 1.1.4 and
only then file a mouse issue if it still persists for me.
thanks much,
--Jeremy
On Sep 22, 11:49 pm, Adam Griffiths <adam.lw.griffi...@gmail.com>
wrote:
> I'm amazed you can get 1.1.4 working on OS-X at all.
> I've never gotten it to work. It is _very_ old.
> I'm also surprised you're using 32-bit python. Any reasons?
> I'm using 64-bit with pyglet with no issues (using my steps above).
> I'm sure the steps will still work for 32-bit if you have dependencies that
> require it.
> That being said, I tried Rabbyt with Pyglet 1.2 (from repository) on OS-X
> and had the mouse co-ordinate issue you mention.
> This wasn't present on Windows (although I tried it a while before trying
> on OS-X, so it may be present on both).
> Probably good to raise it as an issue, as I didn't.
> Hope that helps,
> Adam
> On Sunday, September 23, 2012 1:51:33 AM UTC+10, Jeremy Gray wrote:
> > I'm using pyglet 1.1.4 with 32-bit python 2.7 (for compatibility with
> > a specific app). I have a mac with 10.8.2 with retina display.
> > On the mac, I just updated the firmware this morning. After the
> > update, using full-screen mode had several notice-able issues:
> > - the top and bottom edges of the screen were black, as if cropped
> > - the mouse position was no longer in sync with the screen
> > coordinates. clicking the mouse worked but was reporting different
> > coordinates (based on the discrepancy between mouse position and
> > screen display changes that depend on the mouse, like clicking in a
> > box).
> > - after quitting the pyglet-based app (PsychoPy), back in the mac's
> > Finder, I could no longer use the mouse to activate hot-corners of the
> > screen. if I go into system preferences and reset the hot-corners it
> > works, or reboot. so it seems like the mouse-position mismatch is
> > carrying over into the finder after using pyglet.
I'm interested if you see the mouse issue still. I have a feeling there's a regression there. When I used Rabbyt, I found the Y axis was inverted; dragging GUI elements down, moved them up. And it was also using relative values instead of absolute. Moving the mouse beyond the window extents would continue moving the GUI elements around.
I'd move away from 1.1.4. I didn't have to do anything for the migration. But yes, your 3rd party libs would be the deciding factor.
On Monday, September 24, 2012 11:00:59 PM UTC+10, Jeremy Gray wrote:
> thanks Adam and Nathan, lots to chew on here.
> basically its 32-bit python for compatibility / dependencies with > various packages required for the main app I work on (PsychoPy). maybe > its time to revisit that, and see if we can move to a more recent > version of pyglet. I'll put that forward to see what the lead dev > thinks of it.
> anyway, it seems like I should first move away from pyglet 1.1.4 and > only then file a mouse issue if it still persists for me.
> > I'm amazed you can get 1.1.4 working on OS-X at all. > > I've never gotten it to work. It is _very_ old.
> > I'm also surprised you're using 32-bit python. Any reasons? > > I'm using 64-bit with pyglet with no issues (using my steps above). > > I'm sure the steps will still work for 32-bit if you have dependencies > that > > require it.
> > That being said, I tried Rabbyt with Pyglet 1.2 (from repository) on > OS-X > > and had the mouse co-ordinate issue you mention. > > This wasn't present on Windows (although I tried it a while before > trying > > on OS-X, so it may be present on both). > > Probably good to raise it as an issue, as I didn't.
> > Hope that helps, > > Adam
> > On Sunday, September 23, 2012 1:51:33 AM UTC+10, Jeremy Gray wrote:
> > > I'm using pyglet 1.1.4 with 32-bit python 2.7 (for compatibility with > > > a specific app). I have a mac with 10.8.2 with retina display.
> > > On the mac, I just updated the firmware this morning. After the > > > update, using full-screen mode had several notice-able issues: > > > - the top and bottom edges of the screen were black, as if cropped > > > - the mouse position was no longer in sync with the screen > > > coordinates. clicking the mouse worked but was reporting different > > > coordinates (based on the discrepancy between mouse position and > > > screen display changes that depend on the mouse, like clicking in a > > > box). > > > - after quitting the pyglet-based app (PsychoPy), back in the mac's > > > Finder, I could no longer use the mouse to activate hot-corners of the > > > screen. if I go into system preferences and reset the hot-corners it > > > works, or reboot. so it seems like the mouse-position mismatch is > > > carrying over into the finder after using pyglet.
> I'm interested if you see the mouse issue still. I have a feeling there's a regression there.
your instructions were great and the install seemed fine, but there
are just too many things that will need updating. so I can't tell if
there's a mouse issue or not because I can't run the app at all.
> When I used Rabbyt, I found the Y axis was inverted; dragging GUI elements
> down, moved them up.
> And it was also using relative values instead of absolute. Moving the mouse
> beyond the window extents would continue moving the GUI elements around.
good to know...
> I'd move away from 1.1.4. I didn't have to do anything for the migration.
agreed, and its in the plan. its basically possible to envision such a
move now, now that there's an official tagged release point (albeit
currently alpha...).
<adam.lw.griffi...@gmail.com> wrote:
> I'm interested if you see the mouse issue still.
> I have a feeling there's a regression there.
> When I used Rabbyt, I found the Y axis was inverted; dragging GUI elements
> down, moved them up.
I think this is a Mac OS X thing - I've got pyglet 1.2a1 running on
both Mac OS X and Linux (centos 6.2) and the coordinates I get out of
the mouse events on OS X are inverted in Y. I recall from another
project I was involved with (Blender), I think this was something
happening on the OS level, it's just a difference in the coordinate
system that Cocoa uses for mouse events compared to other OSes.
What I've been doing in my pyglet script is:
if platform.system() != 'Darwin': dy = -dy
where I need to query mouse y values. It probably would be a lot nicer
to have this compensated for within pyglet though...
On Tuesday, September 25, 2012 10:05:42 AM UTC+10, Matt Ebb wrote:
> On Mon, Sep 24, 2012 at 11:32 PM, Adam Griffiths > <adam.lw....@gmail.com <javascript:>> wrote: > > I'm interested if you see the mouse issue still. > > I have a feeling there's a regression there. > > When I used Rabbyt, I found the Y axis was inverted; dragging GUI > elements > > down, moved them up.
> I think this is a Mac OS X thing - I've got pyglet 1.2a1 running on > both Mac OS X and Linux (centos 6.2) and the coordinates I get out of > the mouse events on OS X are inverted in Y. I recall from another > project I was involved with (Blender), I think this was something > happening on the OS level, it's just a difference in the coordinate > system that Cocoa uses for mouse events compared to other OSes.
> What I've been doing in my pyglet script is: > if platform.system() != 'Darwin': dy = -dy > where I need to query mouse y values. It probably would be a lot nicer > to have this compensated for within pyglet though...
On Tuesday, September 25, 2012 4:13:46 PM UTC+10, Adam Griffiths wrote:
> I'll knock up a simple Rabbyt example and post a bug on the issues list.
> Cheers for confirming =) > Adam
> On Tuesday, September 25, 2012 10:05:42 AM UTC+10, Matt Ebb wrote:
>> On Mon, Sep 24, 2012 at 11:32 PM, Adam Griffiths >> <adam.lw....@gmail.com> wrote: >> > I'm interested if you see the mouse issue still. >> > I have a feeling there's a regression there. >> > When I used Rabbyt, I found the Y axis was inverted; dragging GUI >> elements >> > down, moved them up.
>> I think this is a Mac OS X thing - I've got pyglet 1.2a1 running on >> both Mac OS X and Linux (centos 6.2) and the coordinates I get out of >> the mouse events on OS X are inverted in Y. I recall from another >> project I was involved with (Blender), I think this was something >> happening on the OS level, it's just a difference in the coordinate >> system that Cocoa uses for mouse events compared to other OSes.
>> What I've been doing in my pyglet script is: >> if platform.system() != 'Darwin': dy = -dy >> where I need to query mouse y values. It probably would be a lot nicer >> to have this compensated for within pyglet though...
On Tuesday, September 25, 2012 4:17:32 PM UTC+10, Adam Griffiths wrote:
> Correction, it was Kytten, not Rabbyt =P
> On Tuesday, September 25, 2012 4:13:46 PM UTC+10, Adam Griffiths wrote:
>> I'll knock up a simple Rabbyt example and post a bug on the issues list.
>> Cheers for confirming =) >> Adam
>> On Tuesday, September 25, 2012 10:05:42 AM UTC+10, Matt Ebb wrote:
>>> On Mon, Sep 24, 2012 at 11:32 PM, Adam Griffiths >>> <adam.lw....@gmail.com> wrote: >>> > I'm interested if you see the mouse issue still. >>> > I have a feeling there's a regression there. >>> > When I used Rabbyt, I found the Y axis was inverted; dragging GUI >>> elements >>> > down, moved them up.
>>> I think this is a Mac OS X thing - I've got pyglet 1.2a1 running on >>> both Mac OS X and Linux (centos 6.2) and the coordinates I get out of >>> the mouse events on OS X are inverted in Y. I recall from another >>> project I was involved with (Blender), I think this was something >>> happening on the OS level, it's just a difference in the coordinate >>> system that Cocoa uses for mouse events compared to other OSes.
>>> What I've been doing in my pyglet script is: >>> if platform.system() != 'Darwin': dy = -dy >>> where I need to query mouse y values. It probably would be a lot nicer >>> to have this compensated for within pyglet though...
