Support "native" shortcut editing (single, not multi, aka. "key sequences")

Discussion from: https://codereview.qt-project.org/c/qt/qtbase/+/411646

 
Here is what I suggest for a cleaner QtWidgets architecture and software design instead of a maxKeyCount property on QKeySequenceEdit (although it could still be useful for QKeySequenceEdit if one wants, just not needed for a typical shortcut editor and I would personally never want to use it):

QKeySequence -> QKeySequenceEdit (we have this today)

QKeyCombination -> QShortcutEdit (we should have this <strikethrough>today</strikethrough> ASAP)

QKeySequence is already a wrapper around QKeyCombination introduced in Qt 6. This opens up the door towards QShortcutEdit not having to worry about sequences, but rather, be based on a QKeyCombination. Basically, QShortcutEdit would really follow the design of QKeyCombination. And consistency is good!

QKeyCombination is well-articulated semantically what it is meant to be. It is not really a QKeySequence set to one the way you use it as an API user. It also did not limit QKeySequence to arbitrary and artificial maximum lengths. But you use a singular QKeyCombination if you want only a key combination, and you do not want to worry about key sequences. And really, a typical shortcut is just a key combination.

I would have probably preferred to call the QKeyCombination class as QKeyShortcut, but that is not a big deal. The concept of singularity over plurality is still well-communicated semantically through this API.

Go ahead with a QShortcutEdit prototype. Once the prototype is functional, look into sharing between QKeySequenceEdit and QShortcutEdit. It is ok if nothing, but also ok if possible to share.

It is possible that QKeySequence and QKeySequenceEdit could become a wrapper around QKeyCombination and QShortcutEdit respectively to share the functionality. This needs a spike to investigate.

It looks like QKeySequence is already a wrapper around QKeyCombination, so maybe QKeySequenceEdit and QShortcutEdit could relate to each other like an array and an element as an analogy for the software design. I.e. when you just want to work with a number, you do not really want to look at arrays. But you can include an int in your array. This is practically how QKeySequence and QKeyCombination already relate to each other, so this would be a consistent mapping to the widget-based graphical user interface.

This way, a typical shortcut editor implementation would not have to worry about what a "key sequence" is. A typical shortcut is only a key combination after all. This way, geeky applications using QKeySequenceEdit would be clear that they are key sequence editors, not typical shortcut editors that the majority of applications are. So, they would also benefit from the clarity of the new proposed API.

I already had a "What!" moment with customers when trying to explain what key sequence is and why it is like that in a typical shortcut editor. I share their confusion.

I feel like this design would put QtWidgets to the next level, unforeseen, to offer native keyboard shortcut editing support for the majority of the applications out there without only being able to retrofit this common need.

It is certainly questionable, in my views at least, when one would like to set a different key sequence limit other than 4, like 2 or 3, that has never been needed and there is still no use case raised for that. So, this is already alarming to me, personally that we are trying to retrofit by suboptimal compromises. Retrofitting the maxKeyCount does not sound like a good idea to me also because of this.

What we need is 1 or 4. Actually, what we really need is not even cryptic 1 or 4, but clear shortcut or key sequence, rather than the zoo of 1, needless 2 and 3, and finally 4. It is just semantically more correct to articulate shortcut or key sequence. And those semantics should be reflected natively in the API, rather than hiding those real needs behind cryptic and retrofitted numbers. It is really about singularity versus plurality rather than arbitrary integer numbers.

One could argue that this could be a boolean property of QKeySequence rather than an int property. Whilst this would certainly be a better software design decision in my views, it would still suffer from the semantical issue that you need to deal with "key sequence" at the api level when you do not actually care about key sequences.

It is a bit like that you want to work with an integer in a method, but you are forced to define an array of integers just to be able to use an integer. Why do I even have to worry about an array when all I want is an int? I think this analogy is representative of the issue. It is just the wrong thing to wrap an integer in that analogy around an array of integers as opposed to actually wrapping an integer array around integers as it rightfully happens. So, clear semantical separation is still helpful in my views.

Also, this design extension proposal would not introduce any inconsistency between QKeySequence and that of QKeySequenceEdit like the "maxKeyCount" proposal. No need to worry about truncate or getting out of sync, etc. All these are just consequences of retrofitting rather than having a clear design upfront.

Furthermore, this would mitigate any risks of potential regressions to QKeySequenceEdit as the separation would be semantically and logically clear. That is another advantage of this software design change.

Inspired by these and other similar third-party solutions and explanations: 

https://github.com/zealdocs/zeal/blob/master/src/libs/ui/widgets/shortcutedit.cpp

https://github.com/missdeer/cjlv/blob/master/shortcutedit.cpp

https://www.ranorex.info/difference-between-key-sequence-and-key-shortcut-t8864.html

 https://github.com/lpapp/examples/tree/main/qt-hotkey-editor
 
REPLY