search

jcsteh / osara

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

RFC: Including the keymap in code in order to end the problems users have with their customisations when updating. #715

Open RDMurray opened 2 years ago

RDMurray commented 2 years ago

A very common topic on RWP is the hassle of managing keymap customisations when updating Osara. This is especially troublesome if many scripts and custom actions are in use.

I propose including the default Osara key map in code, so that overwriting reaper-kb.ini is no longer necessary. This would make Osara key bindings replace the Reaper defaults. Customisations in reaper-kb.ini would persist during updates.

I have a hacky proof of concept working which relies on undocumented behaviour in Reaper. If you all think it is a good idea, maybe we could ask Cockos for a more official way to do this via the API.

What do you think?

ScottChesworth commented 2 years ago

I'd love to see this fly. It could potentially increase adoption of latest snapshots, would definitely decrease traffic and repetition on the support channels. If there's anything I can do to help re communication with Cockos, just shout.

mattymc2 commented 2 years ago

Big +1 on this one. My key map is so out of date

Sent from my iPhone

On 17 Mar 2022, at 8:11 am, ScottChesworth @.***> wrote:

 I'd love to see this fly. It could potentially increase adoption of latest snapshots, would definitely decrease traffic and repetition on the support channels. If there's anything I can do to help re communication with Cockos, just shout.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

jcsteh commented 2 years ago

In principle, I'm very keen to see this key map problem fixed. I've considered doing something like this before, but have never been able to work out a way to do it that doesn't have one problem or another. So, I'm generally for this idea, but I have some high level questions:

  1. Does a mapping in reaper-kb.ini always take precedence? That is, any key already assigned by the user would never be touched by OSARA?
  2. If a binding is removed from OSARA's key map, does that get handled? I assume your approach somehow adds bindings even for non-OSARA commands purely at runtime with no persistence?
  3. How do we deal with existing installs? Those will all have OSARA's reaper-kb.imi, potentially with customisations. But that means those bindings will all look like user bindings. How do we migrate users? A one-off manual migration is probbably okay, but we need to be very expicit about that if so.
  4. How will we maintain the key map? Right now, the key map can be maintained by non-C++ devs. Given there are relatively few of us, I worry this might become a bottleneck and a maintenance burden on us.
RDMurray commented 2 years ago

The main problem currently with my hack is that it changes data behind reaper's back in the plugin entry point, which just happens to work. It also requires renaming the DLL to make OSARA load after SWS. The fact that it works suggests that it wouldn't be too much work for Cockos to provide an API to register replacement default keyboard shortcuts.

1. Does a mapping in reaper-kb.ini always take precedence? That is, any key already assigned by the user would never be touched by OSARA?

Yes, exactly the way reaper-kb.ini works now with reaper's built-in shortcuts. Even deleting a built-in shortcut adds an entry to reaper-kb.ini

2. If a binding is removed from OSARA's key map, does that get handled? I assume your approach somehow adds bindings even for non-OSARA commands purely at runtime with no persistence?

I'm just replacing the reaper default bindings at runtime, nothing that isn't defined by the user gets stored in reaper-kb.ini

3. How do we deal with existing installs? Those will all have OSARA's reaper-kb.imi, potentially with customisations. But that means those bindings will all look like user bindings. How do we migrate users? A one-off manual migration is probbably okay, but we need to be very expicit about that if so.

It would probably need a one-time migration, otherwise the old reaper-kb.ini would override the built-in bindings. The simplest way, which I just tested as working, is to reset all shortcut bindings to factory defaults in the action list. This deletes all key entries from reaper-kb.ini.

4. How will we maintain the key map? Right now, the key map can be maintained by non-C++ devs. Given there are relatively few of us, I worry this might become a bottleneck and a maintenance burden on us.

I currently have an ugly python script to convert the keymap to a header file. The way I thought of to allow maintenance is to have an action that clears the default bindings in the built-in KbdSectionInfo structs, causing the complete keymap to be written when exported. (not fully tested)

Another thing: What do we do about the custom actions that are currently in the keymap? We could convert them to c++, but then users couldn't edit them or see how they work.

I've uploaded my hack in this branch. Ugly code warning!

TimNoonanVoice commented 2 years ago

Sorry, Slightly off-topic, but I am not seeing the revised keyboard mappings on Mac following Scott's last keymap and sorting changes.

I've tried deleting the key map ini file ahead of OSARA standard install and Yes to replace keyMap but when ever I press slash, it still reports as 'move edit cursor to play cursor'.

Are there any Mac users that can confirm before I do further testing?

Tim

On 17 Mar 2022, at 9:58 am, RDMurray @.***> wrote:

The main problem currently with my hack is that it changes data behind reaper's back in the plugin entry point, which just happens to work. It also requires renaming the DLL to make OSARA load after SWS. The fact that it works suggests that it wouldn't be too much work for Cockos to provide an API to register replacement default keyboard shortcuts.

  1. Does a mapping in reaper-kb.ini always take precedence? That is, any key already assigned by the user would never be touched by OSARA? Yes, exactly the way reaper-kb.ini works now with reaper's built-in shortcuts. Even deleting a built-in shortcut adds an entry to reaper-kb.ini

  2. If a binding is removed from OSARA's key map, does that get handled? I assume your approach somehow adds bindings even for non-OSARA commands purely at runtime with no persistence? I'm just replacing the reaper default bindings at runtime, nothing that isn't defined by the user gets stored in reaper-kb.ini

  3. How do we deal with existing installs? Those will all have OSARA's reaper-kb.imi, potentially with customisations. But that means those bindings will all look like user bindings. How do we migrate users? A one-off manual migration is probbably okay, but we need to be very expicit about that if so. It would probably need a one-time migration, otherwise the old reaper-kb.ini would override the built-in bindings. The simplest way, which I just tested as working, is to reset all shortcut bindings to factory defaults in the action list. This deletes all key entries from reaper-kb.ini.

  4. How will we maintain the key map? Right now, the key map can be maintained by non-C++ devs. Given there are relatively few of us, I worry this might become a bottleneck and a maintenance burden on us. I currently have an ugly python script to convert the keymap to a header file. The way I thought of to allow maintenance is to have an action that clears the default bindings in the built-in KbdSectionInfo structs, causing the complete keymap to be written when exported. (not fully tested)

Another thing: What do we do about the custom actions that are currently in the keymap? We could convert them to c++, but then users couldn't edit them or see how they work.

I've uploaded my hack in this branch https://github.com/RDMurray/osara/tree/embeddedKeyMap. Ugly code warning!

— Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/issues/715#issuecomment-1069723003, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGNKY226WJ2CABMWM3GEDNLVAJRS5ANCNFSM5Q4HKTEA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you are subscribed to this thread.

ScottChesworth commented 2 years ago

I am not seeing the revised keyboard mappings on Mac following Scott's last keymap and sorting changes.

Hmmm, I don't have a clue what's going on there, sorry Tim. Just booted into Mac to fix some other stuff earlier today and the changes were as they should be with a fresh install here. Is it possible that you've got more than one version of Reaper installed? Maybe the version you're running has a different resource path? Try going to the Options top menu, hit "Show resource path in Explorer/Finder" and make sure that's where you think it is.

ScottChesworth commented 2 years ago

Turns out it was me with the multiple Reapers. DOH! Update to the latest snapshot and you should be good @TimNoonanVoice.

TimNoonanVoice commented 2 years ago

Perfect :)

On 20 Mar 2022, at 7:51 am, ScottChesworth @.***> wrote:

Turns out it was me with the multiple Reapers. DOH! Update to the latest snapshot and you should be good @TimNoonanVoice https://github.com/TimNoonanVoice.

— Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/issues/715#issuecomment-1073085247, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGNKY23MGK6ZL3XUCK7V3GTVAY44DANCNFSM5Q4HKTEA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.

LeonarddeR commented 2 years ago

One additional benefit of this feature is that we can easily distribute OSARA using ReaPack, as we no longer have to prompt for the keymap.

MatejGolian commented 2 years ago

Perhaps you are aware of it, but to me it reads like the latest pre-release version includes some improvements in this regard. The key info is in post number 4 by Justin: https://forum.cockos.com/showthread.php?t=272322

MarcoZehe commented 1 year ago

Perhaps this would also get rid of some of the massive problems REAPER is having on Mac with non-English keyboard layouts. On Windows, this is not so much of a problem, since REAPER manages to map sensible defaults for, for example, German key maps on Windows. But on Mac, this is a real nightmare, since there are key bindings that don't map at all if the layout isn't English. An example is Time Selection Start/Time Selection end/Nudge Time Selection start and end forward and backwards, etc. So, maybe getting a solution that would work with non-English keyboards on Mac would be appreciated.

I see that the pull request by @RDMurray hasn't been touched in a while. So, is this still a thing, or has the ball been dropped on this alltogether?