fix(toolbox): persist config on dialog close regardless of accept/reject#54
Merged
Merged
Conversation
Introduces ToolboxSession, which encapsulates the lifecycle of a single toolbox plugin instance inside pj_proto_app. Contents: - toolbox_session.hpp / toolbox_session.cpp: new ToolboxSession QObject that binds toolbox host, runtime host and config, and exposes runDialog() - runDialog() reads kToolboxCapabilityNonModalDialog from the plugin's capability flags and sets DialogEngineConfig::non_modal accordingly, so plugins that declared non-modal capability get a non-blocking dialog automatically - Runtime host vtable wired via captureless static lambdas; dataChanged() signal emitted when the plugin calls notify_data_changed
Toolbox dialogs are persistent workspaces — closing with X or Cancel should not discard the plugin's configuration. Move loadConfig and flushPending before the rejected-early-return so config is always saved after the dialog closes, not only when the user clicks OK.
Collaborator
Author
|
Okay. We accept this since we want to have the same PJ 3.x behavior. |
pabloinigoblasco
changed the base branch from
feat/toolbox-session
to
development
…ox-config-persistence # Conflicts: # pj_proto_app/src/toolbox_session.cpp
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
Toolbox plugins (FFT, Quaternion, ColorMap, etc.) are persistent workspaces — unlike file-open dialogs where Cancel means "don't load", a toolbox dialog is a work area where the user configures parameters, selects fields, adjusts settings, and may run computations. Closing the dialog (whether with OK, Close, or the X button) should not discard that work.
The bug: In the current code,
loadConfig(which persists the plugin's state) only runs if the user clicks OK. If the user clicks Close or the X button,runDialogreturns early before saving, and the plugin's configuration is lost. The next time the user opens the toolbox, it starts from scratch.In PJ 3.x, toolbox panels were permanently visible in the main window — there was no "close and lose state" problem. In the new SDK, toolboxes open as dialogs that can be closed, so we need to explicitly persist state on every close.
Concrete example: The FFT toolbox lets the user select fields, toggle "Remove DC", choose "All data" vs "Only zoomed area", and set a suffix for saved curves. If the user configures all of this, runs an FFT, then closes the dialog to look at the chart, they expect to reopen the FFT dialog and find everything as they left it — not a blank slate.
Summary
loadConfigandflushPendingbefore the rejected-early-return so config is always saved after the dialog closesrunDialogstill distinguishes accept vs reject for callers that careTest plan