[Development] QKeySequenceEdit questions

[Volker Hilsheimer]

> On 18 May 2022, at 10:09, Laszlo Papp <lpapp at kde.org> wrote:
>> On Wed, May 18, 2022 at 9:03 AM Volker Hilsheimer <volker.hilsheimer at qt.io> wrote:
>> Have you ever used vim? :P Deleting until the end of the line, or deleting the next word, are all multi-chord key sequences.
> 
> Sure, but in this context, we were discussing shortcut editors that was linked in KDE.
>  
>> > The current proposal is to make QKeySequenceEdit be able to behave like a QShortcutEdit by adding a property. But for keyboard shortcuts, "key sequence" does not make all that much sense. We are just retrofitting it for that purpose, I feel.
>> 
>> You are not forced to use key sequences with more than one chord, but in some applications, such as IDEs, multi-chord shortcuts are pretty common, even without using vim mode.
> 
> We have actually done thorough investigation on this, and the fact is that the vast majority of the applications (in fact, everything we could find ourselves) use single combination shortcut. It is not really common or even practical to have sequences for shortcuts. Please refer to for example this for further information:
> 
> https://www.ranorex.info/difference-between-key-sequence-and-key-shortcut-t8864.html


That’s one way of defining these terms. VSCode calls things “key combination” and “chords”, and “key bindings". Qt calls them key sequence and shortcut.

In Visual Studio Code, which I’d consider to be a rather popular application, you open the Keyboard Shortcut editor with a sequence of Cmd+K, Cmd+S. The “testing.cancelRun” command is then by default (I think, mine is somewhat heavily customized, but I don’t think I touched that one) bound to the key sequence Cmd+;, Cmd+X, or the “Add Line Comment” command is bound to Cmd+K, Cmd+C. Many of the extensions for VSCode use key sequences, like “jump to previous bookmark" when you install that extension is Cmd+K, J (toggling it is Cmd+K,K).

And you can edit the key sequences there, and end the sequence input via Return; which makes it impossible to use Return in a sequence, but you can’t have it all, I suppose.


>> > For a truly clean solution and design, we would need to decouple the two, I feel.
>> > 
>> > Anyway, hopefully, if QKeySequenceEdit becomes potent to behave like a QShortcutEdit widget, that is fine for now. Maybe, KDE could then drop its own solution in favor of what is available in Qt.
>> 
>> 
>> The status quo is: QKeySequenceEdit records a key, then gives you a second to press another key. If you don’t, then you have a one-chord key sequence. This repeats for up to four keyboards chords, which is probably more than anyone ever needs (or can remember).
>> 
> This is also a questionable decision for a keyboard shortcut edit actually. Quite often, shortcut editors would terminate the shortcut after you entered it or with return if they do not want to allow that shortcut. I have actually never seen a shortcut edit which terminates by some artificial time. Frankly, once you type in a shortcut, it is clear that you want that. No need to wait. And even if you had to wait, there should be a backdoor not to annoyingly wait, like return.

See above.

> This is why I am claiming that this is retrofitting, not a clean solution.
> 
> The bottom line: the ideal and current shortcut editor behaviour in most apps that I have seen is not based on a timer. So, even if we add a property, the timer still gets in the ideal way, although it will be better than what we have now. It will not still be ideal though.

I’m sure there are ways to build a better user experience than what we have today, if you accept certain limitations (like “Return key can’t be part of a recorded sequence”).

QKeySequenceEdit is 330 lines of code, so writing your own that is ideal for your use case might sometimes be the best option. And if you have ideas on how we can make QKeySequenceEdit more user-friendly without categorically constraining existing use cases (Perhaps a property that allows defining a “finish editing” key? And/or adding a protected finishEditing function that would allow a subclass to handle a specific key event to finish editing), then patches welcome.

Cheers,
Volker