You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A new option in the meta info of a plugin could control if the plugin was intended to use as contex based command.
That way the standard UI could make the initiation easier.
For this type of plugin, the static options dialog will not come up by default, as no command should take additional parameters that are not controlled by the context.
The text was updated successfully, but these errors were encountered:
Why won't the options dialog come up when running a plugin from the context menu? Is it safe to say that this information is specific to the composition/model editor? It would be nice if there was a better way to handle visualizer-specific configuration information rather than adding a bunch of (possibly colliding) registry values.
It is a plugin meta-data.
It will not be a registry value, and because we only responsible for the standard UI, that is where we offer solutions that can be specialized for domains using it. (although I believe it is not that hard to see how anyone can adopt this method - plus it is connected more to the plugin and the intended use of the plugin than the visualizer itself...)
We do have visualizer specific configurations, but as you know setting them up is cumbersome and usually if one has the resource to do a specific visualizer, they usually can handle context-menus themselves.
On the other hand, the ones stuck with plugins and standard UI will not be able to offer intuitive UI options...
Finally, the options can come up, I was just thinking that it would be counterintuitive if the user would need to make selections as well (but these can be controlled separately as currently).
Are you proposing adding an extra kvp to the plugin-metadata.json.
Something like:
...."skipManualConfigurationStep": false,
If false (default) no changes, and if true the plugin-manager in the generic UI (or any other UI could use it too) would skip the Plugin Configuration Dialog and just execute the plugin.
If so, I'd just make sure that it runs on the browser by default (if that is the default) and if only server execution is enabled for the plugin - then on the server.
A new option in the meta info of a plugin could control if the plugin was intended to use as contex based command.
That way the standard UI could make the initiation easier.
For this type of plugin, the static options dialog will not come up by default, as no command should take additional parameters that are not controlled by the context.
The text was updated successfully, but these errors were encountered: