Pressing delete key when editing keyframes has unexpected results

Suggestion
1

What is your operating system?
Windows 10

What is your Shotcut version (see Help > About Shotcut)? Is it 32-bit?
21.03.21

Can you repeat the problem? If so, what are the steps?
(Please be specific and use the names as seen in Shotcut, preferably English. Include a screenshot or screen recording if you can. Also, you can attach logs from either View > Application Log or right-click a job and choose View Log.)

  1. Edit manual keyframes on a track or clip. I tested for size and position.
  2. Select a keyframe point that you wish to remove.
  3. Press the delete key

Expected outcome: the keyframe point is removed.
Actual outcome: the clip that the keyframe belongs to is removed from the timeline.

I’d guess this is a case of the keypress falling through the keyframes panel and being caught and acted on by the timeline panel. Adding a handler for the keyframes panel would add a nice quality-of-life improvement and also fix the unexpected behaviour.

2

The Shotcut UI has multiple panels and each panel can have various things selected at the same time. Shotcut does not have a concept of an “active” or “selected” panel. As in your example, you would have a keyframe and a timeline clip selected at the same time. How is Shotcut to know which you want the keyboard shortcuts to apply to? As a result, in order to be unequivocal about keyboard shortcuts, Shotcut does not have any context sensitive key shortcuts. As you can see, “Del” is always “lift”:
https://shotcut.org/howtos/keyboard-shortcuts/

Perhaps we could add a shortcut specifically to delete keyframes.

1 Like
3

That is interesting… Context-sensitive keyboard shortcuts could be a good idea though, since as the application grows and becomes more complex, issues with this sort of behaviour will become more frequent and confusing.

4

This is a duplicate of the below with much discussion

1 Like
5

That is a very interesting read, thanks for the link! I’m especially intrigued by the comparison to Firefox removing the backspace key overload. I feel that it might be better considered under the perspective of “what would produce less unexpected results, including in accidental cases”, rather than “what would require the least explicit complexity (eg in the manual)”.

In Firefox, like other web browsers, it is possible to accidentally deselect a text box, and realising that one has done so is sometimes challenging. If this happens and the user hits backspace, it will go back to the previous page and discard all their typing, which is pretty annoying for users.

Contrastingly, considering a hypothetical Shotcut with contextual keybinds, if a user accidentally deselected something, the worst that would happen would be that nothing gets deleted, which is far less of an issue.

Now looking at Firefox without the contextual keybind, the worst that can happen if the user accidentally deselects a text box is that the text they entered isn’t removed, which is easily corrected by the user.

In comparison, a user of Shotcut may try to remove something from it using the delete key, and the last selected playlist track will be removed from the timeline. This action does take the user back to the timeline, but if the clip is less noticeable, they may not realise that it has been deleted. This will cause a lot of headaches down the track when they realise that somewhere along the line they have lost a clip from their playlist.

So put simply, I think it’s a matter of choosing a design that is easiest for the user to understand. Obviously it is very possible to have a chaotic mess of overloaded hotkeys, but with some good design, it’s very much possible to hugely simplify the mental model that users have to build of the software. Instead of learning all the different keyboard shortcuts for removing any type of thing from anywhere, it’s far easier for a user to learn that the delete key will remove whatever they selected last. This works similarly for Ctrl+C and Ctrl+V, which are heavily overloaded in basically every program that exists. The user just has to know that they will copy whatever they have selected, and paste the last thing they copied at the point they have chosen respectively.

I hope my line of reasoning make sense. Sorry for the essay response, I just wanted to help clarify my views on what would be easiest for users (including myself) to understand and learn. Let me know what you think, since I’m really interested to learn more about the UI design process (it’s looking more and more like a field I want to get myself into).

Thanks again for your clarifications.