A very very simple improvement…
On Shotcut’s UI, there is a current position input control, where you can type things like 00:12:13;14. Or, you can type a frame number.
After you type something, I think it would be nice if the control released its focus, so you can continue editing and use, for example, keyboard shortcuts.
In my experience, the control works like this:
Type a number, hit ENTER: the playhead seeks to the position and the control maintains focus
Type a number, hit TAB: the playhead seeks to the position and the control releases focus
Does hitting TAB to apply the value give the behavior you want?
It almost does. The focus goes to the “up and down” button. So, the left and right shortcuts, that advance one frame, do not work. Lucky enough, one can use up and down, instead of right and left! 
Again… sorry for being pedantic… I do think, however, that the contexts where shortcuts are available could be more explicitly well defined. And, in the case where it is consciously active, it should take precedence.
For example, when you drag and drop a file from the playlist to the timeline, and then press page down, the current position advances one second, but also, there is this side effect of the playlist selection also goes “page down”.
Back to the case of the current position box, after pressing TAB, the focus goes to a controller that does not intercept most of the keys, so as a result of this side effect, shortcut keys partially work.
Another “solution” would be “explicitly” pressing ESC to loose focus. That would be more “semantically correct”, but not as efficient as simply using TAB. Visually, the UI behaviour for the ESC key is a bit strange, because focus looks like as if it was not lost… but the time is still highlighted, and the cursor keeps blinking. (when you type ENTER, it blinks before the text, and after you type ESC, it blinks after the text)
I do agree that someone might want to type a number, press enter, another one, enter again, and so forth. But I guess it would be more useful if current position was a control customized to some workflow. For example.
I know I am begin pedantic… I am very sorry! But I would like to propose the following “exercise”:
Now, do almost the same:
In my computer, up and down work as I expect… they set the position and increase or decrease it by one. And page up and page down do not do what I would expect. When I press page down:
Anyway… I am happy with TAB.
Thanks for that detailed analysis.
I made a change so that the time control will ignore more characters. It only accepts the characters that it absolutely needs to edit time.
With this change, you can do:
This seems to work pretty good, but I think there are some built-in shortcuts that are not being ignored. For example, you can not type CTL-Z to undo while the control has focus (even though the keypress event ignores it). There must be some other event in the QT control that is handling that sequence.
The change is here if you are interested:
Let me know if I missed any keys that should be handled.
There is a regression that this change seems to have done. If you press Delete or Backspace while in the timer under the player it won’t erase the numbers. It will instead eliminate clips in the timeline.
Great testing! Nothing gets by you
Fixed.
Let me know if you find any others.
Thanks. 
You should check all other shortcut keys actually for the timer like Cut and Paste because Copy is also messed up as I found out when testing the Notes panel.
By the way, is pressing the Tab button to go back to the timeline controls really the intuitive action? I would think everyone who naturally think to press Enter not Tab.
I agree!
But as a matter of fact, the TAB button doesn’t actually take you to the timeline. It takes you to the “up arrow control”, just after the “input control”. But on the “arrow control”, you can use the shortcuts.
A good alternative, in my opinion, is if you have a shortcut for the current position input control (something like Ctrl-c, for “current position”… kidding… sorry!!!). And ENTER loosing focus. Then, if you want to type multiple current positions, you could use the shortcut.
It used to work that way with Enter and someone reported it as a bug because in most form UIs Enter does not clear the focus on the current field or move to the next form; Tab does. Rather, Enter usually triggers some kind of OK or Submit action, but that does not really apply here. Enter should apply the change (because typing alone does and should not) but not change focus in case you want to make another change to the value. If you do not like Tab, the other published shortcut to clear focus or return it to the player video area is Shift+Esc. I am about to revert @brian’s changes because they do not belong. What about all of other input fields all throughout the UI? The simple rule is that if something smaller/finer has focus you cannot expect global shortcuts to work.
I think that applies here. TAB does not really make sense, because you are not filling a form.
When you press ENTER, you want to “submit”. That could mean, change current position and go to the timeline.
True, but in most UIs Tab also moves focus around. Going to the time spinner up button is the most logical and expected thing for Tab in this context too.
That could mean, change current position and go to the timeline.
But what about the use case that time is not finished editing? You would then need to press the Ctrl+T shortcut to give it focus, and it will be reported by someone as a bug because the user did not ask to change focus.
For example, in my text editor, when I type Ctrl+F to find text, the find field gets focus. I type the text, press Enter, and it looks for the text. Focus remains in the field and I can change what I am looking for and press Enter again to find. When I press Tab, focus moves to a button.
I do not disagree about the behaviour of the TAB button. Although, I do not think most people would navigate through the control interface… there must be accessibility issues that should be respected.
I was just commenting the suggested use of TAB, not to navigate through the interface, but to take advantage of the side effect that shortcut keys work when the focus is on a spinner button, makes me uncomfortable.
Honestly, I have some difficulty in finding this use case to be of any use.
You change current position to do something. When you use the input UI element, you want to go to a very specific location and do something there. Where? Where are you navigating through? You are navigating through the timeline!!!
Mine (gedit) works like this:
Ctrl-f and the dialog box (actually it is just an input field and two arrows) appears.Ctrl-g.Ctrl-f.I think that what I describe above is a nice and effective way to navigate.
There are other options. I don’t really like the idea, but for example, Shift-ENTER could mean move-and-loose-focus. Another option (I don’t like) is to make ESC loose focus.
Well, you can always get sued by anyone for any reason. Even if it is not reasonable. As long as you are confident about the choice that was made, I don’t see a problem. I really do not see any directive that says that, in using some UI, focus should be kept after you submit it. It is very odd, IMO, that someone expects focus to be kept. Unless, of course, you can continue editing in spite of the fact that focus is still in current position input field.
Of course, this is all just an opinion! Please, feel very comfortable to simply reject it.
This sounds somewhat similar to this suggestion regarding changing focus after clip renaming. Perhaps it encompasses the whole UI navigation ‘philosophy.’