Skip to content

CSSTUDIO-2037 Target the current DockPane when opening applications from the context menu#2943

Merged
abrahamwolk merged 7 commits into
masterfrom
CSSTUDIO-2037
Feb 15, 2024
Merged

CSSTUDIO-2037 Target the current DockPane when opening applications from the context menu#2943
abrahamwolk merged 7 commits into
masterfrom
CSSTUDIO-2037

Conversation

@abrahamwolk

Copy link
Copy Markdown
Collaborator

This PR changes the behavior when right-clicking on a PV in an OPI and, e.g., opening a DataBrowser when using SplitPanes: currently, the DataBrowser would be launched in the top-left-most Pane of the window. This PR changes the behavior so that the DataBrowser is launched in the same pane as the OPI itself.

@kasemir kasemir left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unclear if this is the final solution.

It should work for the context menu of displays, where it will now force the 'active' stage to be the one that holds the widget.

But it removes the more generic code that was supposed to support any "parent_node", not just display builder widgets.

Still, if this gives more reliable results from widget context menus, which I'd say is the most frequent use case, then overall this would still be an improvement

…elper.addSupportedEntries() to "Runnable setFocus".
@abrahamwolk

abrahamwolk commented Feb 9, 2024

Copy link
Copy Markdown
Collaborator Author

But it removes the more generic code that was supposed to support any "parent_node", not just display builder widgets.

I have now changed ContextMenuHelper.addSupportedEntries() to take as an argument Runnable setFocus, which is then called when the action corresponding to a menu entry is called.

All calls except the one in display.builder.runtime.app.ContextMenuSupport.handleContextMenu() to ContextMenuHelper.addSupportedEntries() implement the same logic as before: DockStage.setActiveDockStage() is called on the window of the corresponding node.

The one exception now is display.builder.runtime.app.ContextMenuSupport.handleContextMenu, where a call to DockPane.setActiveDockPane() is made instead.

This should give the old behavior for context menus outside of the DisplayRuntime, while it fixes the bug this PR intends to fix.

Do you think this is a better solution?

@shroffk

shroffk commented Feb 9, 2024

Copy link
Copy Markdown
Member

#2947

@abrahamwolk abrahamwolk merged commit f46b95f into master Feb 15, 2024
@abrahamwolk abrahamwolk deleted the CSSTUDIO-2037 branch February 15, 2024 07:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants