New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Return key doesn't open Register Editor #600

Open
10110111 opened this Issue Sep 11, 2017 · 3 comments

Comments

Projects
None yet
2 participants
@10110111
Contributor

10110111 commented Sep 11, 2017

Due to Follow menu item's shortcut (Return key) in CPU view, Register view doesn't receive Return key press events. The shortcut for the Follow menu item is set via QAction::setShortcut. Looks like the QAction's shortcuts are global for all the main window, not only for the focused widget, so I'm not sure how this should be fixed.

@eteran

This comment has been minimized.

Show comment
Hide comment
@eteran

eteran Sep 12, 2017

Owner

So, we had a similar "issue" with the "Goto" shortcut if I recall correctly. The solution was relatively simple.

We simply made the global handler test which widget had focus, and would delegate to the appropriate one as needed.

see: Debugger::goto_triggered() for relevant code.

Owner

eteran commented Sep 12, 2017

So, we had a similar "issue" with the "Goto" shortcut if I recall correctly. The solution was relatively simple.

We simply made the global handler test which widget had focus, and would delegate to the appropriate one as needed.

see: Debugger::goto_triggered() for relevant code.

@10110111

This comment has been minimized.

Show comment
Hide comment
@10110111

10110111 Sep 12, 2017

Contributor

Doesn't seem too easy. I've tried this approach, but it results in ugly coupling between handlers of Key_Return in main window and register view. Another option I tried, QAction::setShortcutContext, appears to require moving logic of Follow item from Debugger to QDisassemblyView, otherwise it doesn't have any effect (the associated widget is still the main window). Yet another option, simulation of QKeyEvent via QCoreApplication::postEvent, appears to lead to infinite loop of recurring event for some reason.

Contributor

10110111 commented Sep 12, 2017

Doesn't seem too easy. I've tried this approach, but it results in ugly coupling between handlers of Key_Return in main window and register view. Another option I tried, QAction::setShortcutContext, appears to require moving logic of Follow item from Debugger to QDisassemblyView, otherwise it doesn't have any effect (the associated widget is still the main window). Yet another option, simulation of QKeyEvent via QCoreApplication::postEvent, appears to lead to infinite loop of recurring event for some reason.

@eteran

This comment has been minimized.

Show comment
Hide comment
@eteran

eteran Sep 15, 2017

Owner

So, here's how I think I would handle it (untested)

I would have a global handler like we do, then I would use qobject_cast to get which specific widget has the focus, so we know which widget we want to get the event.

If it is one of the primary UI widgets, like the disassembler, data, or stack panes. then we know what to do and perform the action.

For the "unknown" case. We simulate a keyPressEvent(QKeyEvent *event) directly for the target widget there is likely a way to avoid infinite loops when doing this. My gut would have been postEvent, but I believe that there are other options as well, I will explore a little bit.

Owner

eteran commented Sep 15, 2017

So, here's how I think I would handle it (untested)

I would have a global handler like we do, then I would use qobject_cast to get which specific widget has the focus, so we know which widget we want to get the event.

If it is one of the primary UI widgets, like the disassembler, data, or stack panes. then we know what to do and perform the action.

For the "unknown" case. We simulate a keyPressEvent(QKeyEvent *event) directly for the target widget there is likely a way to avoid infinite loops when doing this. My gut would have been postEvent, but I believe that there are other options as well, I will explore a little bit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment