osara icon indicating copy to clipboard operation
osara copied to clipboard

Suggestion for solve of issues with ctrl+windows keyboard shortcuts

Open tbdalgaard opened this issue 3 years ago • 17 comments

This is for the keymap group, but hope it's ok I post here.

Since Windows-ctrl-c doesn't work on all systems I thought the following change could be a long term solution.

  1. Change shortcut for action ID: 40014
    Item: Copy selected area of items from Windows-ctrl-c to ctrl-shift-c.
  2. Change shortcut for action ID 40916
    Item: Cut selected area of items from ctrl-windows-x to ctrl-shift x.
  3. Change shortcut for action ID 40057
    Edit: Copy items/tracks/envelope points (depending on focus) within time selection, if any (smart copy)
  4. Change the shortcut for action ID: 40059
    Edit: Cut items/tracks/envelope points (depending on focus) within time selection, if any (smart cut)

Originally the ctrl-c and ctrl-x commands ignore time selection if any is present,, and I have thought of different cases where this could be useful, but haven't found any case where I really need to ignore a time selection. It looks like OSARA can do some magic behind the seens, so even if a time selection is present, but an item is selected outside the time selection, the time selection is ignored by pressing ctrl-shift-x, so basically some shortcuts could be changed, and the user experience would be the same, because OSARA takes context sensitivity to the next level.

Please let me know your thoughts on this, and sorry if this is the wrong place to bring these things up. I am not sure what the best way to approach the keymap group is, so thought Github could be a good starting point.

tbdalgaard avatar Jan 29 '22 22:01 tbdalgaard

Something I learned from working on NVDA is that the situation is pretty inconsistent across systems in terms of which complex keystrokes work and which don't. I've never heard of Windows+control+c not working, but I've heard of many other arbitrary things not working on various systems, particularly laptops. While it'd be ideal if we came up with a key map where every command works on every system, the reality is that trying to solve for this is likely to be a never ending battle we can't win. We might change a bunch of things to accommodate two people's systems, only to realise we broke something else for twenty other people.

jcsteh avatar Jan 29 '22 22:01 jcsteh

Ctrl+windows+C doesn't work here. It's not my keyboard though because NVDA recognises it. It must be Windows or something else intercepting it. Nothing obvious happens when it is pressed.

RDMurray avatar Feb 07 '22 12:02 RDMurray

Thanks for confirming this @RDMurray I think that @ScottChesworth once said on RWP that this was related to some Windows contrast shortcuts, therefor my suggestion of changing the keystrokes.

tbdalgaard avatar Feb 07 '22 13:02 tbdalgaard

I want to double-check that I've understood the proposal:

  1. We'd un-assign Control+Win+C because Windows hogs it, moving that and the associated cut action onto Control+Shift+C and X respectively (Control modifier for items, Shift modifier because we're dealing with a selected area).
  2. The Smart Copy functionality that's currently on the Control+Shift modifiers moves to plain old Control+C and Control+X.
  3. The copy/cut actions that are currently bound to Control+C and Control+X (which don't factor in time selection if present) would no longer be included on the key map.

Is that all correct? If so, I'd be happy to go with it.

ScottChesworth avatar Feb 07 '22 13:02 ScottChesworth

Yes, that was my thoughts. Nice recap!

tbdalgaard avatar Feb 07 '22 13:02 tbdalgaard

Okie dokie. Let's let this sit for a couple of days then, just to check there aren't any strong objections or things we've overlooked. If nothing shows up, we can add it to this month's key map revision.

ScottChesworth avatar Feb 07 '22 13:02 ScottChesworth

Is there a good reason that the commands currently on ctrl+x and ctrl+c should be the ones to go? Personally they are the only ones that I have ever used. What advantage does "item: copy selected area of items" have over smart copy, which actually does the same thing if Reaper's focus is items?

RDMurray avatar Feb 07 '22 14:02 RDMurray

When you use ctrl-c or ctrl-x now they will copy/cut whatever focus is at or what you have selected. The same is true for ctrl-shift-c and ctrl-shift-x, with the important exception: If a time selection is present the time selection will be used as a reference for copy/cut, but we can still copy tracks, envelope points with these keystrokes if a time selection isn't present.

On the other hand: There might be cases where areas of items are the only thing one need to copy, therefor my suggestion on ctrl-shift so we could remove references to the ctrl-windows keys which may not function correct on Windows 10 anymore.

So if this change is incorperated into the keymap, you will probably not notice a change in your work except if you have a time selection active, but I have yet to find a situation where one creates a time selection without using it for anything, and therefor my suggestion, since the difference will be quite small for most people. @ScottChesworth please correct me, if I got this all the wrong way. :)

tbdalgaard avatar Feb 07 '22 17:02 tbdalgaard

I have played with this a bit, and still can't find a situation where "Item: Copy selected area of items" would be necessary. The smart copy command always works, whether you select items first and then the time selection or the other way round.

I can't see a convincing reason to change this one to be honest.

RDMurray avatar Feb 08 '22 10:02 RDMurray

@RDMurray The other commands on ctrl-x and ctrl-c will still work as expected, if a time selection is not present, so you might not notice any difference in most cases. On the other hand if you make a time selection and select another track the smart cut/copy will not function as expected, since a track has focus instead of the seelcted items. Here the commands for copy/cut selected area of items saves the user to redo this selection again. Because even if the time selection is focused by pressing home/end the track will still be the thing that gets copied by smart cut/copy. But the thing is: you don't miss out any functionality by this change. you can do the same thing as if you used ctrl-c and ctrl-x as the actions are now. Therefor the change is likely to go unnoticed for most users. But we get an issue out of the way, where users can't get keystrokes to work due to changes in the Windows operative system.

tbdalgaard avatar Feb 11 '22 17:02 tbdalgaard

It would mean that users would always have to clear the time selection to get the old behaviour. It's a big change to a common command, which probably wouldn't be popular with those making training material. @ScottChesworth ?

RDMurray avatar Feb 12 '22 13:02 RDMurray

The time selection only needs to be cleared if items inside set selection is selected. You can actually have a time selection active, and still select items and tracks outside the selection, and copy those. Yesterday I managed to copy a track because focus was at the track not the item and time selection. I think we are overthinking this, and that most users won't have too much trouble with this change. But I think more experienced people like @ScottChesworth and others may have stronger opinions about this. I just thought this could free up some keystrokes that conflicted with Windows itself, and that most users wouldn't mind this. The two sets of commands does almost the same, the difference is when a time selection is active, and the user selects the area inside the time selection, else everything I have tested works like the old behaviour. But I really like that we are trying to find all cases where changes could cause trouble.

tbdalgaard avatar Feb 12 '22 13:02 tbdalgaard

@RDMurray We might take this suggestion to the RWP-list to get more thoughts on this. I will try to make a post shortly. If users think this is a bad idea we can just close this.

tbdalgaard avatar Oct 11 '22 19:10 tbdalgaard

Just wanted to follow-up on this issue.

There is a good conversation over at RWP where this is discussed some more. Here are my last comment in that thread just for context:

The standard copy/paste method is good for new users, since it makes sense that if you select anything inside a Reaper project it can be copied. At least in 9 out of 10 times it is possible. So CTRL + C and CTRL + X must remain as they are...

Now for the other part about smart cut/copy. You are exactly right about these commands and what most users are used to if they are coming from other editors, and for the most of the work I do, this method works great. However what confused me somehow was that if I selected one or more tracks and used the smart copy after a time selection was established, I still got the entire track copied, ignoring the time selection. So I went back and tried a few more things until I found out that: Smart copy and smart cut needs to have items selected, before they will work as I expected them to. Therefor I was very happy to find some custom made actions from Chris Belle called block copy and block cut. These two actions have that in common, that they select all items on selected track(s) in the active time selection first, and then do the copy/cut. That saves me for quite some gotcha moments, where I forgot to select items om the selected tracks. These actions respect ripple as well, which is very useful.

I think a better suggestion is to implement the block copy/block cut actions into the default keymap, and perhaps suggest an extension to the action Item: Remove selected area of items so this action takes the items and selected track(s) before doing the deletion.

End of quote.

I have since created the action where the items in time selection are selected and then the removal of the area of selected items will take place. This was much inspired by the actions I referenced above.

Perhaps this should do it for another issue, if you want I will be happy to submit my suggestion with the actions, both the two that Chris Belle have created and the last I created inspired from his work. I think these actions will help new users who know how to work the timeline, but may find the splitting items-concept a little tricky to get at first.

My suggestion is to replace smart cut and smart copy with block copy and block cut instead. Unless this conflicts with something interesting regarding envelopes that I haven't figured out myself as of yet. Please let me know what you think.

tbdalgaard avatar Dec 17 '22 21:12 tbdalgaard

+1 on that. I also sometimes forget to select items before doing the smart cut and wind up cutting tracks. Fortunately Osara lets me know that the tracks were removed, so it is easy to quickly perform an undo with control+Z. But basically I like the idea of the block copy.

This seems similar to the recently added Reaper actions:

Time selection: Move contents of time selection to edit cursor (moving later items)

Time selection: Copy contents of time selection to edit cursor (moving later items)

Which currently don’t have hotkeys assigned. I need to remember to start using those actions myself but they aren’t ingrained yet!

--Pete

--Pete

From: Thomas Byskov Dalgaard @.> Sent: Saturday, December 17, 2022 2:41 PM To: jcsteh/osara @.> Cc: Subscribed @.***> Subject: Re: [jcsteh/osara] Suggestion for solve of issues with ctrl+windows keyboard shortcuts (Issue #660)

Just wanted to follow-up on this issue.

There is a good conversation over at RWP https://groups.io/g/rwp/topic/94133918#90521 where this is discussed some more. Here are my last comment in that thread just for context:

The standard copy/paste method is good for new users, since it makes sense that if you select anything inside a Reaper project it can be copied. At least in 9 out of 10 times it is possible. So CTRL + C and CTRL + X must remain as they are...

Now for the other part about smart cut/copy. You are exactly right about these commands and what most users are used to if they are coming from other editors, and for the most of the work I do, this method works great. However what confused me somehow was that if I selected one or more tracks and used the smart copy after a time selection was established, I still got the entire track copied, ignoring the time selection. So I went back and tried a few more things until I found out that: Smart copy and smart cut needs to have items selected, before they will work as I expected them to. Therefor I was very happy to find some custom made actions from Chris Belle called block copy and block cut. These two actions have that in common, that they select all items on selected track(s) in the active time selection first, and then do the copy/cut. That saves me for quite some gotcha moments, where I forgot to select items om the selected tracks. These actions respect ripple as well, which is very useful.

I think a better suggestion is to implement the block copy/block cut actions into the default keymap, and perhaps suggest an extension to the action Item: Remove selected area of items so this action takes the items and selected track(s) before doing the deletion.

End of quote.

I have since created the action where the items in time selection are selected and then the removal of the area of selected items will take place. This was much inspired by the actions I referenced above.

Perhaps this should do it for another issue, if you want I will be happy to submit my suggestion with the actions, both the two that Chris Belle have created and the last I created inspired from his work. I think these actions will help new users who know how to work the timeline, but may find the splitting items-concept a little tricky to get at first.

My suggestion is to replace smart cut and smart copy with block copy and block cut instead. Unless this conflicts with something interesting regarding envelopes that I haven't figured out myself as of yet. Please let me know what you think.

— Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/issues/660#issuecomment-1356477325 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ADEPTJMBWRUQU5NBLHMAOD3WNYXNLANCNFSM5NDNGX5Q . You are receiving this because you are subscribed to this thread.Message ID: @.***>

ptorpey avatar Dec 17 '22 23:12 ptorpey

I'm still up for rejigging the key map as per https://github.com/jcsteh/osara/issues/660#issuecomment-1031466889, but as much as I get the convenience, I'm less sure about shipping these block copy actions with OSARA. Kinda blurs lines around concepts that are fundamental to understand IMO.

ScottChesworth avatar Dec 18 '22 01:12 ScottChesworth

Hello

@ptorpey the actions for move or copy time selection moving later items are useful in some contexts. I have a hard time figurering out how to use these myself, mostly because they should not factor in the selected tracks if I understand the documentation correct.

@ScottChesworth I think you'll get bigger issues if we factored this in with reference to #660 because users will find that entire tracks can get copied when a time selection is active, because one forget to select item(s) first. As @ptorpey explains it in his comment. I do get why we want to stick to the core concepts here, and perhaps things have changed now that there are more training resources available than before, and that might change workflows for quite a few people.

Therefor I will change my suggestion to the following:

Remove the actions for copy selected area of items on ctrl-windows-c and cut selected area of items on ctrl-windows-x. My reasons are the following:

  1. I have not seen many on RWP use these commands. I have only seen them referenced in This episode of ReaProducer
  2. The few people who have explained why they used these actions have found that smart cut/copy did the same thing, which I have confirmed as well, so I wonder how relevant these actions are in 2022. I guess they might have had some impact for someone, so I hope somebody can share more background on this.

tbdalgaard avatar Dec 18 '22 15:12 tbdalgaard