Compile keymap into OSARA to replace Reaper default shortcuts #728
Conversation
|
If anyone wants to try this out, please only install it in a portable Reaper that doesn't already have OSARA installed. Currently all of the shortcuts that are the same as the reaper defaults, such as 's' are missing. |
|
Build failed! Build osara pr728-898,8e8ff27d failed (commit 8e8ff27d24 by @RDMurray) |
RDMurray
force-pushed
the
embeddedKeyMap
branch
from
f817ee3
to
a31b5cb
Compare
|
Build succeeded! Build osara pr728-1013,84c3e31c completed (commit 84c3e31cc3 by @RDMurray) |
What happens if we do this before SWS loads? Is the problem that SWS adds some default bindings, overriding ours?
I wonder if it specifically only works in the plugin entry point or whether it's just that we don't have a way to do this before the key map loads. What happens if you modify the defaults after the key map has loaded? |
It's because we need to change the default bindings for SWS actions but the action ids are dynamic. The load order seems to depend on the file name but that might not be reliable.
I think it's that the plugin entry point is called before the key map is loaded. I remember that it breaks if the defaults are changed after the key map. The key map file only contains entries that have been changed from the defaults so I think the defaults have to be in place before it is loaded. |
|
Am I right that the next step to take would be to ask Cockos for an API endpoint that gets called as soon as all plugins are loaded as disccussed above to simplify our process here? I'd guess @ScottChesworth needs to ask for this, just wanted to make sure that I could follow you :). |
|
One other concern here is how we migrate existing users who might have key maps that heavily deviate from the OSARA key map. I guess that's mostly only problematic if their key maps rely on defaults that REAPER has that OSARA overrides, and there probably aren't that many of those, if any. Still, it's a risk that's hard to reason about. I feel like we discussed some other issues on a Zoom call, but now i can't remember and for some reason I didn't document the discussion like i normally do. @ScottChesworth, @RDMurray, do you recall any other outstanding concerns here? |
|
Hi guys, I'm one of those users, I've been updating my key map since I've been using reaper, and I've added my own or custom actions that differ significantly or completely from the osara map. I don't think I would ever be able to do it again because I have many actions also integrated into my custom menu in reaper. |
|
This would only change what REAPER considers the "default" key bindings. If you've overridden those, you'll be fine. The question is whether there are any key bindings in REAPER that your map has that OSARA doesn't. I doubt it, but if there are, that could cause problems. @RDMurray, as I understand it, default bindings aren't saved to the key map. I just want to double check: if you change a binding, then change it back to the default, does REAPER remove the entry from the key map again? |
Would scripts from ReaPack or elsewhere be examples of that? OSARA isn't gonna know about those. |
|
Those should be fine because they're never default bindings as far as REAPER is concerned. But honestly, all of this is untested in practice, which makes me nervous at best. I think we'd need a few test subjects with wildly altered key maps who would be willing to take this for a spin in a portable copy or something and see what breaks before I'd be remotely comfortable merging this, other issues aside. |
|
Derp, I missed the default bindings part. Gotcha. I know a slim handful of folks who have gone hardcore customizing, should be fine to get them testing and reporting back whenever this is ready. |
|
Ah, now I remember the other problem I thought of. If/when we switch to this builtin key map, users who installed before that change will have the OSARA key map in reaper-kb.ini. That's all fine until we change one of the bindings inside OSARA. At that point, the old reaper-kb.ini entry will override, meaning that this new change won't apply. If the user makes some change to the key map, I think it should remove the defaults (but see my question above about that) which will resolve this problem, but we can't know if or when a user will do that. |
|
Now that Reaper is supporting multiple key maps, I wonder if some of the issues people have raised could be addressed by not touching the default keymap that comes with Reaper, and adding an alternate keymap for people using Osara. So we could use as much of the default Reaper keymap as we want and add or override some of the hotkeys with actions specific to Osara in the alternate keymap. If working with a sighted person, one could switch to the Reaper default keymap, and, if using Osara, one could switch to the Osara keymap.
I don’t know how these alternate keymaps are intended to work and I haven’t played around with them, but just throwing out this idea as a thought provoker if it is helpful.
…--Pete
From: James Teh ***@***.***>
Sent: Sunday, May 26, 2024 6:05 AM
To: jcsteh/osara ***@***.***>
Cc: Subscribed ***@***.***>
Subject: Re: [jcsteh/osara] Compile keymap into OSARA to replace Reaper default shortcuts (PR #728)
Ah, now I remember the other problem I thought of. If/when we switch to this builtin key map, users who installed before that change will have the OSARA key map in reaper-kb.ini. That's all fine until we change one of the bindings inside OSARA. At that point, the old reaper-kb.ini entry will override, meaning that this new change won't apply. If the user makes some change to the key map, I think it should remove the defaults (but see my question above about that) which will resolve this problem, but we can't know if or when a user will do that.
—
Reply to this email directly, view it on GitHub <#728 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADEPTJMATAXDDH6N3NNZ6ELZEHFYFAVCNFSM5RFLANT2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJTGIYTSNJSGAYA> .
You are receiving this because you are subscribed to this thread. <https://github.com/notifications/beacon/ADEPTJPNETVZ34IZNNBLF5LZEHFYFA5CNFSM5RFLANT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOP4LLPAA.gif> Message ID: ***@***.*** ***@***.***> >
|
Doesn't the keymap get overidden by REAPER whenever you update that anyway? Couldn't we just ask them to do so? I mean, obviously thats a hack, but REAPER keeps old versions around don't they, so people could just install the version they're currently using again if they don't want to update and revert back to the default REAPER keymap, except if they are using a heavily customized one, in which the previously discussed problems come up anyway. |
It isn't supporting multiple key maps. Cockos implemented layers for the Main section, but it's still one key map, with all sections and layers stored in a single file.
No, that wouldn't solve any of the challenges here.
One can already import the default to a layer if one wants to. I'm yet to meet one who would do that (including sighted ones), because the default key map is... er... how can I put it... not one of REAPER's stronger suits. Sighted folk who have any interest in driving with keystrokes end up obliterating the defaults before long anyway. |
I assume you mean OSAR, not REAPER? REAPER never touches the key map unless you make changes to it. OSARA's installer does ask the user to overwrite, yes.
We'd have to instead ask them to remove the existing key map. If a user has customised it slightly, they might choose not to for a while, which causes problems for any changes we make. But I guess you're right: we have that problem with overwriting it right now anyway. Yuck. This whole key map situation is so damned ugly. |
As discussed in #715
There are still multiple issues with this, including that it relies on a really ugly hack to make it load after SWS, and modifies the built-in "accel_section" structs, which only works in the plugin entry point.
If we decide to go with this, it would be good if Cockos could provide a documented way to modify the default shortcuts that wouldn't have the risk of breaking in the future.
To get round the load order problem, perhaps they could allow a callback to be registered that would be called after all plugins have been loaded, but before Reaper initializes the keymap. They already have this for customizable menus.