search

jcsteh / osara

OSARA: Open Source Accessibility for the REAPER Application
GNU General Public License v2.0
127 stars 46 forks source link

Focus change bug when nudging volume of master track #77

Closed ScottChesworth closed 8 years ago

ScottChesworth commented 8 years ago

Steps to reproduce:

  1. Make your master track visible.
  2. Create a new track.
  3. Whilst focused on your new track, invoke either Track: nudge master volume up or Track: nudge master volume down.
  4. Rinse and repeat without master track visible.

In both scenarios here, the focus jumps when these actions are triggered, and it shouldn't. When the master track is visible, focus is reset to be on that master track. Without the master track being visible things get a little more random, but I'm usually refocused on either track 1 or in no man's land above it.

Anything that can be done to prevent this?

jcsteh commented 8 years ago

This is a REAPER issue, but arguably, it's intentional on their part. Basically, after you mess with the master volume, REAPER reports (at least via the API) that the last touched track is the master. I guess that kinda makes sense; it was the last track you "touched".

I guess this isn't what users will expect, but I'm always dubious about overriding behaviour that was intended by the app. It's also going to be a bit tricky to fix--I'm basically going to have to fight with REAPER--but I'll see what I can do.

ScottChesworth commented 8 years ago

Sure, if you've actually moved a mouse to grab and drag a fader then the master track is indeed the last thing you touched, but I think this being the case with actions triggered via the API is a dodgy bit of UX from them. Shout if it gives you major fits to hack around it and I'll attempt to argue the case with Cockos hq instead.

On 2/22/16, James Teh notifications@github.com wrote:

This is a REAPER issue, but arguably, it's intentional on their part. Basically, after you mess with the master volume, REAPER reports (at least via the API) that the last touched track is the master. I guess that kinda makes sense; it was the last track you "touched".

I guess this isn't what users will expect, but I'm always dubious about overriding behaviour that was intended by the app. It's also going to be a bit tricky to fix--I'm basically going to have to fight with REAPER--but I'll see what I can do.

Reply to this email directly or view it on GitHub: https://github.com/nvaccess/osara/issues/77#issuecomment-186948724

jcsteh commented 8 years ago

Those master volume actions are internal REAPER actions; we're not even triggering them from the API. Just to be sure, see if you can check if they screw with the last touched track with OSARA removed. If so, I'd suggest first tackling Cockos about this, since it's surely got to annoy sighted keyboard users as well. If Cockos refuse to play ball, I'll try to hack around it.

ScottChesworth commented 8 years ago

Oki doke, I'll verify and attempt to reach Cockos.

On 2/22/16, James Teh notifications@github.com wrote:

Those master volume actions are internal REAPER actions; we're not even triggering them from the API. Just to be sure, see if you can check if they screw with the last touched track with OSARA removed. If so, I'd suggest first tackling Cockos about this, since it's surely got to annoy sighted keyboard users as well. If Cockos refuse to play ball, I'll try to hack around it.

Reply to this email directly or view it on GitHub: https://github.com/nvaccess/osara/issues/77#issuecomment-186954314

jcsteh commented 8 years ago

After some dialog with Cockos, this is fixed in REAPER 5.20pre11.

chrisbelle2015 commented 8 years ago

Nice.

On 2/25/2016 10:35 PM, James Teh wrote:

After some dialog with Cockos, this is fixed in REAPER 5.20pre11.

— Reply to this email directly or view it on GitHub https://github.com/nvaccess/osara/issues/77#issuecomment-189110138.