| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 1 | |
I'm trying to enable user-defined application shortcuts for any combination of keys. The focus for keyboard input is typically on a QLineEdit. They shortcuts work fine if the focus isn't on a QLineEdit (such as the QMainWindow itself). However, if the QLineEdit has the focus, then shortcuts aren't triggered (such as SHIFT+S). A combination such as SHIFT+S doesn't add an "S" to the QLineEdit, though, so it seems to be registering somewhere. Does anyone have any suggestions on how I could register and trigger shortcuts in a global fashion, even if a QLineEdit has focus? I'm willing to override something in QLineEdit if that's necessary, but I'm not sure what needs to be done. I also wasn't sure if there was a better way to approach this, so that I wouldn't have to worry about making sure each widget that can accept focus is able to register any shortcut. Here's an example of what I'm doing. QLineEdit* lineEdit = new QLineEdit(); QShortcut* shortcut = new QShortcut( QKeySequence( "SHIFT+S" ), lineEdit ); shortcut->setContext( Qt::ApplicationShortcut ); connect( shortcut, SIGNAL( activated() ), this, SLOT( setActivated() ) ); Setting the parent of the shortcut to the window or some other widget does not seem to have an effect, either. -- [ signature omitted ]
Shortcuts are only considered, if a widget doesn't use the keyboard event. For a QLineEdit, this obviously doesn't apply, since it will grab the shift-s. I have two ideas for you to try: The first is to set a QValidator that won't allow "S" on the QLineEdit. It might be that QLineEdit won't eat the key in this case. If not, you probably have to do this by subclassing QLineEdit and overriding the keyPressEvent. In this, you only allow key event if the keypress is not one of your global shortcuts. However, another idea might be to not have such an important key on Shift-S, but instead put it on Alt-S or Ctrl-S, in which case you won't have a problem. Bo. On lørdag den 5. Januar 2008, Roy Donaldson wrote: > I'm trying to enable user-defined application shortcuts for any > combination of keys. The focus for keyboard input is typically on a > QLineEdit. They shortcuts work fine if the focus isn't on a QLineEdit > (such as the QMainWindow itself). However, if the QLineEdit has the > focus, then shortcuts aren't triggered (such as SHIFT+S). A > combination such as SHIFT+S doesn't add an "S" to the QLineEdit, > though, so it seems to be registering somewhere. > > Does anyone have any suggestions on how I could register and trigger > shortcuts in a global fashion, even if a QLineEdit has focus? I'm > willing to override something in QLineEdit if that's necessary, but > I'm not sure what needs to be done. I also wasn't sure if there was a > better way to approach this, so that I wouldn't have to worry about > making sure each widget that can accept focus is able to register any > shortcut. > > Here's an example of what I'm doing. > > QLineEdit* lineEdit = new QLineEdit(); > QShortcut* shortcut = new QShortcut( QKeySequence( "SHIFT+S" ), lineEdit ); > shortcut->setContext( Qt::ApplicationShortcut ); > connect( shortcut, SIGNAL( activated() ), this, SLOT( setActivated() ) ); > > Setting the parent of the shortcut to the window or some other widget > does not seem to have an effect, either. > > -- > To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with > "unsubscribe" in the subject or the body. List archive and information: > http://lists.trolltech.com/qt-interest/ -- [ signature omitted ]
Thanks for the suggestions. I opted to go ahead and override the keyPressEvent in my QLineEdit to check if the key combination is one of my shortcuts. If it is, then I use QMetaObject::invokeMethod() to activate it. It works perfectly, now! On Jan 5, 2008 5:48 AM, Bo Thorsen <bo@xxxxxxxxxxxxxxxxxxxxx> wrote: > Shortcuts are only considered, if a widget doesn't use the keyboard event. For > a QLineEdit, this obviously doesn't apply, since it will grab the shift-s. > > I have two ideas for you to try: > > The first is to set a QValidator that won't allow "S" on the QLineEdit. It > might be that QLineEdit won't eat the key in this case. > > If not, you probably have to do this by subclassing QLineEdit and overriding > the keyPressEvent. In this, you only allow key event if the keypress is not > one of your global shortcuts. > > However, another idea might be to not have such an important key on Shift-S, > but instead put it on Alt-S or Ctrl-S, in which case you won't have a > problem. > > Bo. > > > On lørdag den 5. Januar 2008, Roy Donaldson wrote: > > I'm trying to enable user-defined application shortcuts for any > > combination of keys. The focus for keyboard input is typically on a > > QLineEdit. They shortcuts work fine if the focus isn't on a QLineEdit > > (such as the QMainWindow itself). However, if the QLineEdit has the > > focus, then shortcuts aren't triggered (such as SHIFT+S). A > > combination such as SHIFT+S doesn't add an "S" to the QLineEdit, > > though, so it seems to be registering somewhere. > > > > Does anyone have any suggestions on how I could register and trigger > > shortcuts in a global fashion, even if a QLineEdit has focus? I'm > > willing to override something in QLineEdit if that's necessary, but > > I'm not sure what needs to be done. I also wasn't sure if there was a > > better way to approach this, so that I wouldn't have to worry about > > making sure each widget that can accept focus is able to register any > > shortcut. > > > > Here's an example of what I'm doing. > > > > QLineEdit* lineEdit = new QLineEdit(); > > QShortcut* shortcut = new QShortcut( QKeySequence( "SHIFT+S" ), lineEdit ); > > shortcut->setContext( Qt::ApplicationShortcut ); > > connect( shortcut, SIGNAL( activated() ), this, SLOT( setActivated() ) ); > > > > Setting the parent of the shortcut to the window or some other widget > > does not seem to have an effect, either. > > > > -- > > To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with > > "unsubscribe" in the subject or the body. List archive and information: > > http://lists.trolltech.com/qt-interest/ > > > > -- > > Thorsen Consulting ApS - Qt consulting services > http://www.thorsen-consulting.dk > > -- > To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body. > List archive and information: http://lists.trolltech.com/qt-interest/ > > -- [ signature omitted ]
Roy Donaldson wrote: >Thanks for the suggestions. I opted to go ahead and override the >keyPressEvent in my QLineEdit to check if the key combination is one >of my shortcuts. If it is, then I use QMetaObject::invokeMethod() to >activate it. It works perfectly, now! How does one type a capital S in your line edits now? -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
On Sat, 2008-01-05 at 13:51 -0200, Thiago Macieira wrote: > Roy Donaldson wrote: > >Thanks for the suggestions. I opted to go ahead and override the > >keyPressEvent in my QLineEdit to check if the key combination is one > >of my shortcuts. If it is, then I use QMetaObject::invokeMethod() to > >activate it. It works perfectly, now! > > How does one type a capital S in your line edits now? > I think the answer hovers somewhere around "They don't" :) Stephan -- [ signature omitted ]
On Jan 5, 2008 11:06 AM, Stephan Rose <kermos@xxxxxxxxxx> wrote: > > On Sat, 2008-01-05 at 13:51 -0200, Thiago Macieira wrote: > > Roy Donaldson wrote: > > >Thanks for the suggestions. I opted to go ahead and override the > > >keyPressEvent in my QLineEdit to check if the key combination is one > > >of my shortcuts. If it is, then I use QMetaObject::invokeMethod() to > > >activate it. It works perfectly, now! > > > > How does one type a capital S in your line edits now? > > > > I think the answer hovers somewhere around "They don't" :) > Good question :) However, I'm not defining any of the macros myself. A macro of Shift+S would be defined by the user... so if they do that, then they apparently don't need to type a capital S, heh. But the problem occurs with other keys using shift as a modifier, such as Shift+End or Shift+Delete. Rather than worry about which keys should be legal, which keys shouldn't, and which keys are consumed by the line edit, I opted to allow any key combination, and the user could decide which to use and which to avoid (such as Shift+S). -- [ signature omitted ]
Hi, > Good question :) However, I'm not defining any of the macros myself. A > macro of Shift+S would be defined by the user... so if they do that, > then they apparently don't need to type a capital S, heh. But the > problem occurs with other keys using shift as a modifier, such as > Shift+End or Shift+Delete. Rather than worry about which keys should > be legal, which keys shouldn't, and which keys are consumed by the > line edit, I opted to allow any key combination, and the user could > decide which to use and which to avoid (such as Shift+S). Even if you manage to solve this specific Shift+S problem, your users may define other shortcuts that cause similar problems (system-wide shortcuts such as Alt+Tab under the KDE window manager for example). -- [ signature omitted ]
Dimitri wrote: >Hi, > >> Good question :) However, I'm not defining any of the macros myself. A >> macro of Shift+S would be defined by the user... so if they do that, >> then they apparently don't need to type a capital S, heh. But the >> problem occurs with other keys using shift as a modifier, such as >> Shift+End or Shift+Delete. Rather than worry about which keys should >> be legal, which keys shouldn't, and which keys are consumed by the >> line edit, I opted to allow any key combination, and the user could >> decide which to use and which to avoid (such as Shift+S). > >Even if you manage to solve this specific Shift+S problem, your users > may define other shortcuts that cause similar problems (system-wide > shortcuts such as Alt+Tab under the KDE window manager for example). Global shortcuts should be eaten by the global shortcut handler before they reach your application. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
I've given all shortcuts an application-context, so that keys that don't reach my line edit are executed as normal, application shortcuts. Anything that doesn't register as an application shortcut should be handled by one of two widgets that are able to have focus by checking in their keyPressEvent functions. Anything that is a system/OS shortcut and doesn't reach my application what-so-ever, I guess, does not register. I use a customized QLineEdit to let the user define shortcuts (which is separate from the line edit that actually registers/checks if a key press is a shortcut). Each key press sets the line edit's text to the current key-combination (ex: pressing ctrl, alt, E would set the line edit's text to Ctrl+Alt+E), and saves the key sequence. In this manner, I'm assuming that the line edit will not be able to record any system shortcuts because it would execute system commands rather than passing the key presses to the line edit to be recorded. Thus, no shortcuts can be defined that are already defined by the system. Granted, this does not take in to account a shortcut that is present in one OS but not present in another (or vice versa), but I doubt there's much I can do about that. Does this sound reasonable? On Jan 5, 2008 4:58 PM, Thiago Macieira <thiago.macieira@xxxxxxxxxxxxx> wrote: > Dimitri wrote: > >Hi, > > > >> Good question :) However, I'm not defining any of the macros myself. A > >> macro of Shift+S would be defined by the user... so if they do that, > >> then they apparently don't need to type a capital S, heh. But the > >> problem occurs with other keys using shift as a modifier, such as > >> Shift+End or Shift+Delete. Rather than worry about which keys should > >> be legal, which keys shouldn't, and which keys are consumed by the > >> line edit, I opted to allow any key combination, and the user could > >> decide which to use and which to avoid (such as Shift+S). > > > >Even if you manage to solve this specific Shift+S problem, your users > > may define other shortcuts that cause similar problems (system-wide > > shortcuts such as Alt+Tab under the KDE window manager for example). > > Global shortcuts should be eaten by the global shortcut handler before > they reach your application. > > > -- > Thiago José Macieira - thiago.macieira AT trolltech.com > Trolltech ASA - Sandakerveien 116, NO-0402 Oslo, Norway > -- [ signature omitted ]
Hi, > Global shortcuts should be eaten by the global shortcut handler before > they reach your application. That's exactly my point. Users may define an application-wide shortcut identical to a system-wide shortcut. The application won't work and users will wonder why... -- [ signature omitted ]
Which is something that I hadn't considered. But, I think that by providing them with a custom widget to record their key-presses when making shortcuts, those system shortcuts will never be defined in the application (since the widget will never get those key presses ). On Jan 6, 2008 11:06 AM, Dimitri <dimitri@xxxxxxxxxxxxx> wrote: > Hi, > > > Global shortcuts should be eaten by the global shortcut handler before > > they reach your application. > > That's exactly my point. Users may define an application-wide shortcut > identical to a system-wide shortcut. The application won't work and users will > wonder why... > > > -- > Dimitri > > -- > To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body. > List archive and information: http://lists.trolltech.com/qt-interest/ > > -- [ signature omitted ]