Skip to content

PluginTriggerAction: copy enabled status in copy constructor - #1326

Open
alxvth wants to merge 1 commit into
masterfrom
feature/CopyEnablePluginTriggerAction
Open

PluginTriggerAction: copy enabled status in copy constructor#1326
alxvth wants to merge 1 commit into
masterfrom
feature/CopyEnablePluginTriggerAction

Conversation

@alxvth

@alxvth alxvth commented Aug 26, 2026

Copy link
Copy Markdown
Contributor

We should copy the "enabled" status in the copy constructor of PluginTriggerAction.

There are plugins that should be not opened via the main menu bar, e.g. the JupyterLauncher, but there might be other cases, e.g. when a view plugin must be opened with a dataset.

Currently, afaik, all view plugins are listed in the menu and the"enabled" status is not respected.

New possibility, e.g. with ManiVaultStudio/JupyterPlugin#71:
image

There are more members of the PluginTriggerAction which are not copied in the copy-constructor, but that might be intentional?

Related: #1327


Some additional context:

The JupyterLauncher plugin factory sets the maximum number of plugins instances to 1. In PluginManager::privateRequestPlugin, there is a check for pluginFactory->mayProduce() which returns _numberOfInstances < _maximumNumberOfInstances, and will throw if true. This means, currently, when first opening the JupyterLauncher via the view menu, nothing happens since the plugins want to be opened via the status bar, and the second opening causes a crash.

Alternatively, instead of throwing when mayProduce() returns true, the respective plugin trigger action could be disabled.

@alxvth
alxvth requested a review from ThomasKroes August 26, 2026 15:41
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.

1 participant