Mercurial > hg > svapp
changeset 384:ad33fdc4ad92 tonioni
OS/X: When augmenting a single-key shortcut associated with an action with a global shortcut, leave the shortcut attached to the original action as well if it is a menu action with no toolbar button. Do not augment toolbar actions with global shortcuts. Aims to fix #1009 (single-key shortcuts work, but do not appear in menu)
author | Chris Cannam |
---|---|
date | Fri, 18 Jul 2014 13:25:11 +0100 |
parents | 681447b07142 |
children | d1abf593dfaf 08a45e4cf1b1 |
files | framework/MainWindowBase.cpp |
diffstat | 1 files changed, 28 insertions(+), 12 deletions(-) [+] |
line wrap: on
line diff
--- a/framework/MainWindowBase.cpp Fri Jul 18 11:07:51 2014 +0100 +++ b/framework/MainWindowBase.cpp Fri Jul 18 13:25:11 2014 +0100 @@ -294,7 +294,8 @@ // See https://bugreports.qt-project.org/browse/QTBUG-38256 and // our issue #890 http://code.soundsoftware.ac.uk/issues/890 -- // single-key shortcuts that are associated only with a menu - // action do not work with Qt 5.x under OS/X. + // action (and not with a toolbar button) do not work with Qt 5.x + // under OS/X. // // Apparently Cocoa never handled them as a matter of course, but // earlier versions of Qt picked them up as widget shortcuts and @@ -303,17 +304,24 @@ // dialog (https://bugreports.qt-project.org/browse/QTBUG-30657). // // This workaround restores the single-key shortcut behaviour by - // searching for single-key shortcuts in menus and replacing them - // with global application shortcuts that invoke the relevant - // actions, testing whether the actions are enabled on invocation. - // As it happens, it also replaces some shortcuts that were - // working fine (because they were also associated with toolbar - // buttons) but that seems to be OK so long as we remove the - // shortcuts from the actions as well as adding the new global - // shortcuts, to avoid an ambiguous shortcut error. + // searching in menus for single-key shortcuts that are associated + // only with the menu and not with a toolbar button, and + // augmenting them with global application shortcuts that invoke + // the relevant actions, testing whether the actions are enabled + // on invocation. // - // If the Qt developers ever fix this in Qt (I couldn't think of - // an obvious fix myself) then presumably we can remove this. + // (Previously this acted on all single-key shortcuts in menus, + // and it removed the shortcut from the action when it created + // each new global one, in order to avoid an "ambiguous shortcut" + // error in the case where the action was also associated with a + // toolbar button. But that has the unwelcome side-effect of + // removing the shortcut hint from the menu entry. So now we leave + // the shortcut in the menu action as well as creating a global + // one, and we only act on shortcuts that have no toolbar button, + // i.e. that will not otherwise work. The downside is that if this + // bug is fixed in a future Qt release, we will start getting + // "ambiguous shortcut" errors from the menu entry actions and + // will need to update the code.) QSignalMapper *mapper = new QSignalMapper(this); @@ -321,12 +329,20 @@ this, SLOT(menuActionMapperInvoked(QObject *))); foreach (QAction *a, menu->actions()) { + QWidgetList ww = a->associatedWidgets(); + bool hasButton = false; + foreach (QWidget *w, ww) { + if (qobject_cast<QAbstractButton *>(w)) { + hasButton = true; + break; + } + } + if (hasButton) continue; QKeySequence sc = a->shortcut(); if (sc.count() == 1 && !(sc[0] & Qt::KeyboardModifierMask)) { QShortcut *newSc = new QShortcut(sc, a->parentWidget()); QObject::connect(newSc, SIGNAL(activated()), mapper, SLOT(map())); mapper->setMapping(newSc, a); - a->setShortcut(QKeySequence()); // avoid ambiguous shortcut error } } #endif