QAction shortcuts completely innaccessible when undocking a window
-
Hello,
I am posting this topic to ask for some support or insight on the issue I have been experiencing with our tool which UI is powered by Qt:
I have a window (Lets call it Explorer) that shows you a hierarchy tree of files. The window contains a QWidget which itself contains a QAbstractScrollArea. We have setup QActions both at the Widget level and at the MainWindow (The top level application). Shortcuts to these actions work as expected while the window is docked to the Editor. As soon as the window is undocked, shortcuts do not work anymore. Other windows are working fine however. I have been looking at discrepancies between this new window and the other windows that work, but at this point I am not sure of what I may be missing.
I would be interested on having an idea of what can cause a QAction to not get an event. I have been debugging our main eventFilter and when the window is docked, we get a Shortcut Event targeted to a QAction object. When undocked, QAction never gets to the eventFilter. Interesting enough, if I click the window itself (When undocked) the shortcuts work. When I click one of the items in the hierarchy list of the tree view, the shortcuts stop working.
I haven't been able to find good documentation of what can cause a QAction to stop receiving events. Any insight or advice will be highly appreciated.
Thanks,
Christian
-
Okay I may have found the culprit, I still do not understand why.
In the focused widget (TreeView), we are implementing the mouseReleaseEvent. I noticed that once I click in the hierarchy item, if we intercepted the tree view we accept the event (event->accept()) and we skip calling the base class's mouseReleaseEvent (QAbstractScrollArea::mouseReleaseEvent). If I ensure the latter is called, the shortcuts work fine when the window is undocked.
I still do not understand the following:
a) Why is this not affecting the shortcuts when the widget is docked to the main window of the application?
b) How would not calling mouseReleaseEvent of the base class somehow prevent the QActions to get triggered?
-
Hi and welcome to devnet,
So if understand you correctly, when undocked and out of focus, the actions associated to that widget aren't triggered, correct ?
-
Hi and welcome to devnet,
So if understand you correctly, when undocked and out of focus, the actions associated to that widget aren't triggered, correct ?
Hey SGaist,
When undocked, I click in one of the items of the file hierarchy and actions are not triggered (Not just the ones associated with the widget, but even those added to the Main Window)
Cheers,
Christian
-
Can you show how you setup your action ?
Depending on how you did that, it's the widget which has the keyboard focus that will handle the actions associated with it.
See the ShortcutContext enum.
-
Okay I may have found the culprit, I still do not understand why.
In the focused widget (TreeView), we are implementing the mouseReleaseEvent. I noticed that once I click in the hierarchy item, if we intercepted the tree view we accept the event (event->accept()) and we skip calling the base class's mouseReleaseEvent (QAbstractScrollArea::mouseReleaseEvent). If I ensure the latter is called, the shortcuts work fine when the window is undocked.
I still do not understand the following:
a) Why is this not affecting the shortcuts when the widget is docked to the main window of the application?
b) How would not calling mouseReleaseEvent of the base class somehow prevent the QActions to get triggered?
-
Not calling the base class implementation means that whatever the base class was doing does not happen. It could be focus handling.
When docked, your widget is in the same focus level as the others.
When undocked, it is separated thus handled separately.
-
Sounds good. Thanks for your replies SGaist!
