> On 18 May 2022, at 11:50, Laszlo Papp <lp...@kde.org> wrote: >> >> >> >> On Wed, May 18, 2022 at 9:50 AM Volker Hilsheimer <volker.hilshei...@qt.io> >> wrote: >> > On 18 May 2022, at 10:09, Laszlo Papp <lp...@kde.org> wrote: >> >> On Wed, May 18, 2022 at 9:03 AM Volker Hilsheimer >> >> <volker.hilshei...@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. >> > The thing, emacs, vim, Visual Code or even QtCreator are development > environments. Most of the apps out there, like ours, are not geeky > development environments. I consider these sort of applications the minority > out there as far as applications go. This is not to invalidate them. I am > just saying that Qt designed this class for these minor use cases. I would > like them to become useful also by the majority.
I agree that most applications would not have or need multi-chord shortcuts _by default_. And most users will never change keyboard shortcuts of an application. But keyboard shortcut settings are supposed to cover unusual preferences by the user. It is an “expert" setting, and if you do not allow multi-chord shortcuts there even though the application in principle would support it, IMO you are arbitrarily restricting that “expert” setting to a “half-expert” setting. Why prevent an emacs user from setting their favorite multi-chord shortcut even in a different, more simpler application? Why prevent an emacs user from setting Ctrl+x,o as the shortcut for switching to the next tab in a browser? Or Ctrl+x,Ctrl+f for File > Open ? Br, Eike > >> 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. > > The list of properties that I think a generic hotkey editor would need: > > 1. Single combination > 2. Finishing character > 3. No timer! This could be done automatically for keyPressEvent timing. No > need to time again in a custom widget. > 4. Allowing Esc to be assigned like in some apps. > > I am happy to provide patches for these over some course of time as we have > got requests for all these. > > Thanks. > > _______________________________________________ > Development mailing list > Development@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.zil...@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 _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
