Re: [Development] QKeySequenceEdit questions
> On 18 May 2022, at 11:50, Laszlo Papp wrote: >> >> >> >> On Wed, May 18, 2022 at 9:50 AM Volker Hilsheimer >> wrote: >> > On 18 May 2022, at 10:09, Laszlo Papp wrote: >> >> On Wed, May 18, 2022 at 9:03 AM Volker Hilsheimer >> >> 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
Re: [Development] QKeySequenceEdit questions
On Wed, May 18, 2022 at 10:50 AM Laszlo Papp wrote: > 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. > 5. Property to cancel the shortcut (do not confuse it with clearing the line edit whilst in edit). ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QKeySequenceEdit questions
On Wed, May 18, 2022 at 9:50 AM Volker Hilsheimer wrote: > > On 18 May 2022, at 10:09, Laszlo Papp 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. > 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
Re: [Development] QKeySequenceEdit questions
On 2022 May 18, at 11:21, Eike Ziller mailto:eike.zil...@qt.io>> wrote: 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.) We don’t have a Qt Quick Controls alternative to QKeySequenceEdit, so I suppose that would be desirable at some point. Not sure if KDE has one. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QKeySequenceEdit questions
> On 18 May 2022, at 10:09, Laszlo Papp wrote: > > > > On Wed, May 18, 2022 at 9:03 AM Volker Hilsheimer > 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@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
Re: [Development] QKeySequenceEdit questions
> On 18 May 2022, at 10:09, Laszlo Papp wrote: >> On Wed, May 18, 2022 at 9:03 AM Volker Hilsheimer >> 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 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QKeySequenceEdit questions
> > 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. > This could probably be mitigated by disabling the timer when the maxKeyCount equals to one. I think that would be a fair decision to make. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QKeySequenceEdit questions
On Wed, May 18, 2022 at 9:03 AM Volker Hilsheimer 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. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QKeySequenceEdit questions
> On 18 May 2022, at 09:45, Laszlo Papp wrote: > > As a datapoint > https://api.kde.org/frameworks/kguiaddons/html/classKeySequenceRecorder.html > (which > supports single letter shortcuts, used by KShortcutsDialog and co.). > > Thanks for sharing that. > > I do not know where the idea of "key sequence" comes from, but it does look > like what we are looking for in practice is a "QShortcutEdit". Presumably, > that is what KDE would also appreciate. Have you ever used vim? :P Deleting until the end of the line, or deleting the next word, are all multi-chord key sequences. > 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. > 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). Making QKeySequenceEdit consider the sequence complete after the nth key (rather than the hardcoded 4th) without waiting for that one second is probably all you need to do. No need for a whole new widget class. QShortcut is then a programmatic construct that ties a QKeySequence into the event handling process and the signal/slot mechanism do that applications can respond to the key sequence being pressed. You never need the user to edit one of those. In very early Qt versions, QShortcut only stored a single key chord. QKeySequence was added later (Qt 3 maybe?) to be able to express multi-chord shortcuts, IIRC because we needed it in Qt Creator or even Qt Designer. Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QKeySequenceEdit questions
> > As a datapoint > https://api.kde.org/frameworks/kguiaddons/html/classKeySequenceRecorder.html > (which > supports single letter shortcuts, used by KShortcutsDialog and co.). > Thanks for sharing that. I do not know where the idea of "key sequence" comes from, but it does look like what we are looking for in practice is a "QShortcutEdit". Presumably, that is what KDE would also appreciate. 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. 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. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QKeySequenceEdit questions
On 16/5/22 19:12, Laszlo Papp wrote: On Mon, May 16, 2022 at 2:57 PM Volker Hilsheimer wrote: On 11 May 2022, at 16:02, Laszlo Papp wrote: Hi, 1. I would like QKeySequenceEdit to block the processing of hotkeys while recording, so that the new hotkey being recorded is not getting handled (e.g. cmd+q does not close the Qt app in this mode). Is this already possible to achieve? I think that modal dialogs work ok for example. But in my case, I am not using a model dialog. Here is a testbed where you can reproduce the issue: https://github.com/lpapp/examples/tree/main/qt-hotkey-editor Hi Laszlo, I’ll have to look a bit more, but looking at the code I see that QKeySequenceEdit accepts both the ShortcutOverride and the Shortcut event, so it should take precedence over any application-defined shortcut. If/since that doesn’t work, But since you write cmd+q (and considering your recent patches) I think that perhaps you are on macOS, and it might be that our macOS shortcut code doesn't respect the focus widget’s override for application level shortcuts. Bottom line anyway: this should already work, so if it doesn’t, I’d consider that a bug. Yes, it seems to work on Windows and Mac. I have not noticed until you mentioned it. Thanks for pointing that out. 1. Is there an easy workaround until this gets fixed in Qt? 2. Where would I need to look if I wanted to help you out by sending a patch for Qt so that future versions will work on Mac? 2. Is it possible to configure QKeySequenceEdit not to support multiple keypresses as a shortcut for an action? It seems to be the default behaviour and it feels a bit odd at first. At least, not how we would like to use this. I am referring to the "A, B, C" setup that is possible. If not, is this something that should be configurable? Making it possible to configure the max length of the recorded QKeySequence could be a useful feature addition. I don’t see that this is possible today, but implementing it might not require much more than replacing the use of QKeySequencePrivate::MaxKeyCount with a property. So, you would propose to do that in QtGui::QKeySequence then, I assume, rather than QtWidgets::QKeySequenceEdit, right? Thanks. As a datapoint https://api.kde.org/frameworks/kguiaddons/html/classKeySequenceRecorder.html (which supports single letter shortcuts, used by KShortcutsDialog and co.). Best regards Ahmad Samir ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QKeySequenceEdit questions
> > > 2. Is it possible to configure QKeySequenceEdit not to support multiple > keypresses as a shortcut for an action? It seems to be the default > behaviour and it feels a bit odd at first. At least, not how we would like > to use this. I am referring to the "A, B, C" setup that is possible. If > not, is this something that should be configurable? > > > Making it possible to configure the max length of the recorded > QKeySequence could be a useful feature addition. I don’t see that this is > possible today, but implementing it might not require much more than > replacing the use of QKeySequencePrivate::MaxKeyCount with a property. > https://codereview.qt-project.org/c/qt/qtbase/+/411646 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QKeySequenceEdit questions
> On 16 May 2022, at 19:44, Laszlo Papp wrote:
>
>
>
> I’ll have to look a bit more, but looking at the code I see that
> QKeySequenceEdit accepts both the ShortcutOverride and the Shortcut event, so
> it should take precedence over any application-defined shortcut. If/since
> that doesn’t work,
>
> But since you write cmd+q (and considering your recent patches) I think that
> perhaps you are on macOS, and it might be that our macOS shortcut code
> doesn't respect the focus widget’s override for application level shortcuts.
>
> Bottom line anyway: this should already work, so if it doesn’t, I’d consider
> that a bug.
>
> Yes, it seems to work on Windows and Mac. I have not noticed until you
> mentioned it. Thanks for pointing that out.
>
> 1. Is there an easy workaround until this gets fixed in Qt?
> 2. Where would I need to look if I wanted to help you out by sending a patch
> for Qt so that future versions will work on Mac?
>
> Just to be clear on this, even a simple main.cpp reproduces this issue:
>
> #include
> #include
>
> int main(int argc, char *argv[])
> {
> QApplication app(argc, argv);
> QKeySequenceEdit keySequenceEdit;
> keySequenceEdit.show();
> return app.exec();
> }
That example is a bit contrived because you don’t create a menu bar with your
own actions, so you get the default actions from macOS that Qt has
(practically) no control over. So for anything to be possible, you need to
create a QMenuBar with the respective actions added.
And this works for most actions in most menus, i.e. in the following example,
Cmd+T and Ctrl+D do what they should, i.e. record the key with the editor, and
not trigger the shortcut:
#include
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
QMainWindow window;
QMenu *fileMenu = window.menuBar()->addMenu("");
fileMenu->addAction("", []{
qDebug() << "Quit shortcut triggered";
});
fileMenu->addAction("T", QKeySequence(Qt::ControlModifier|Qt::Key_T), []{
qDebug() << "Ctrl+T";
});
QMenu *editMenu = window.menuBar()->addMenu("");
editMenu->addAction("E", QKeySequence(Qt::MetaModifier|Qt::Key_E), []{
qDebug() << "Meta+E";
});
QKeySequenceEdit keySequenceEdit;
window.setCentralWidget();
QShortcut sc = QShortcut(QKeySequence(Qt::AltModifier | Qt::Key_D),
, []{
qDebug() << "Alt+D";
});
window.show();
return app.exec();
}
The Cmd+Q however will trigger the shortcut and execute the lambda (which does
not quit the application).
From what I see, the problem here is limited to the shortcuts for menu entries
that live in the macOS application menu. That menu gets created as a plain
NSMenu in qcocoamenuloader.mm, so our delegate that is responsible for
respecting the ShortcutOverride handling of the focus widget doesn’t get
called. I think that’s easily fixed:
https://codereview.qt-project.org/c/qt/qtbase/+/411608
Volker
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QKeySequenceEdit questions
I’ll have to look a bit more, but looking at the code I see that
>> QKeySequenceEdit accepts both the ShortcutOverride and the Shortcut event,
>> so it should take precedence over any application-defined shortcut.
>> If/since that doesn’t work,
>>
>> But since you write cmd+q (and considering your recent patches) I think
>> that perhaps you are on macOS, and it might be that our macOS shortcut code
>> doesn't respect the focus widget’s override for application level shortcuts.
>>
>> Bottom line anyway: this should already work, so if it doesn’t, I’d
>> consider that a bug.
>>
>
> Yes, it seems to work on Windows and Mac. I have not noticed until you
> mentioned it. Thanks for pointing that out.
>
> 1. Is there an easy workaround until this gets fixed in Qt?
> 2. Where would I need to look if I wanted to help you out by sending a
> patch for Qt so that future versions will work on Mac?
>
Just to be clear on this, even a simple main.cpp reproduces this issue:
#include
#include
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
QKeySequenceEdit keySequenceEdit;
keySequenceEdit.show();
return app.exec();
}
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QKeySequenceEdit questions
On Mon, May 16, 2022 at 2:57 PM Volker Hilsheimer wrote: > > > > On 11 May 2022, at 16:02, Laszlo Papp wrote: > > > > Hi, > > > > 1. I would like QKeySequenceEdit to block the processing of hotkeys > while recording, so that the new hotkey being recorded is not getting > handled (e.g. cmd+q does not close the Qt app in this mode). > > > > Is this already possible to achieve? I think that modal dialogs work ok > for example. But in my case, I am not using a model dialog. > > > > Here is a testbed where you can reproduce the issue: > https://github.com/lpapp/examples/tree/main/qt-hotkey-editor > > > > Hi Laszlo, > > > I’ll have to look a bit more, but looking at the code I see that > QKeySequenceEdit accepts both the ShortcutOverride and the Shortcut event, > so it should take precedence over any application-defined shortcut. > If/since that doesn’t work, > > But since you write cmd+q (and considering your recent patches) I think > that perhaps you are on macOS, and it might be that our macOS shortcut code > doesn't respect the focus widget’s override for application level shortcuts. > > Bottom line anyway: this should already work, so if it doesn’t, I’d > consider that a bug. > Yes, it seems to work on Windows and Mac. I have not noticed until you mentioned it. Thanks for pointing that out. 1. Is there an easy workaround until this gets fixed in Qt? 2. Where would I need to look if I wanted to help you out by sending a patch for Qt so that future versions will work on Mac? > > 2. Is it possible to configure QKeySequenceEdit not to support multiple > keypresses as a shortcut for an action? It seems to be the default > behaviour and it feels a bit odd at first. At least, not how we would like > to use this. I am referring to the "A, B, C" setup that is possible. If > not, is this something that should be configurable? > > Making it possible to configure the max length of the recorded > QKeySequence could be a useful feature addition. I don’t see that this is > possible today, but implementing it might not require much more than > replacing the use of QKeySequencePrivate::MaxKeyCount with a property. > So, you would propose to do that in QtGui::QKeySequence then, I assume, rather than QtWidgets::QKeySequenceEdit, right? Thanks. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QKeySequenceEdit questions
> On 11 May 2022, at 16:02, Laszlo Papp wrote: > > Hi, > > 1. I would like QKeySequenceEdit to block the processing of hotkeys while > recording, so that the new hotkey being recorded is not getting handled (e.g. > cmd+q does not close the Qt app in this mode). > > Is this already possible to achieve? I think that modal dialogs work ok for > example. But in my case, I am not using a model dialog. > > Here is a testbed where you can reproduce the issue: > https://github.com/lpapp/examples/tree/main/qt-hotkey-editor > Hi Laszlo, I’ll have to look a bit more, but looking at the code I see that QKeySequenceEdit accepts both the ShortcutOverride and the Shortcut event, so it should take precedence over any application-defined shortcut. If/since that doesn’t work, But since you write cmd+q (and considering your recent patches) I think that perhaps you are on macOS, and it might be that our macOS shortcut code doesn't respect the focus widget’s override for application level shortcuts. Bottom line anyway: this should already work, so if it doesn’t, I’d consider that a bug. > 2. Is it possible to configure QKeySequenceEdit not to support multiple > keypresses as a shortcut for an action? It seems to be the default behaviour > and it feels a bit odd at first. At least, not how we would like to use this. > I am referring to the "A, B, C" setup that is possible. If not, is this > something that should be configurable? Making it possible to configure the max length of the recorded QKeySequence could be a useful feature addition. I don’t see that this is possible today, but implementing it might not require much more than replacing the use of QKeySequencePrivate::MaxKeyCount with a property. Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] QKeySequenceEdit questions
Hi, 1. I would like QKeySequenceEdit to block the processing of hotkeys while recording, so that the new hotkey being recorded is not getting handled (e.g. cmd+q does not close the Qt app in this mode). Is this already possible to achieve? I think that modal dialogs work ok for example. But in my case, I am not using a model dialog. Here is a testbed where you can reproduce the issue: https://github.com/lpapp/examples/tree/main/qt-hotkey-editor 2. Is it possible to configure QKeySequenceEdit not to support multiple keypresses as a shortcut for an action? It seems to be the default behaviour and it feels a bit odd at first. At least, not how we would like to use this. I am referring to the "A, B, C" setup that is possible. If not, is this something that should be configurable? Thanks. Kind regards, László ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
