[Development] QKeySequenceEdit questions

[Eike Ziller]

> 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

We have several multiple-chord shortcuts in Qt Creator, at least for code pasting, test integration, version control system integration, and editor splitting/navigation.
At some point the space for single chord shortcuts simply becomes much too small.

(Qt Creator also has its own shortcut editor. Our “Record” button doesn’t stop recording automatically, but when you click somewhere. Pure text input is supported too.)

Br, Eike

>  
>> > 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.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.ziller at qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B