[Development] QKeySequenceEdit questions

[Laszlo Papp]

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


> > 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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20220518/6c01b12b/attachment-0001.htm>