Closed klues closed 5 years ago
looks good. Actually I would prefer a more generic solution for all plugins.
A complex solution for this could be to implement composition of bundle descriptors, so we could define generic functionality. A simple solution could be to create a plugin which allows to control the lifecycle and properties of any other plugin.
But nevertheless let's merge until we have time to make something more generic.
thanks for the review!
yeah, agree that a generic solution would be great. Maybe a third possibility would be to define some generic functionality for enabling/disabling a plugin in a superclass DeactivatablePlugin
and Plugins can derive from this class.
thanks for the review! yeah, agree that a generic solution would be great. Maybe a third possibility would be to define some generic functionality for enabling/disabling a plugin in a superclass
DeactivatablePlugin
and Plugins can derive from this class.thanks for the review! yeah, agree that a generic solution would be great. Maybe a third possibility would be to define some generic functionality for enabling/disabling a plugin in a superclass
DeactivatablePlugin
and Plugins can derive from this class.
:+1:
ok, will merge
ok, created an issue for the generic solution: https://github.com/asterics/AsTeRICS/issues/309
If a model uses the ComPort plugin but is not used in all cases it's quite annoying to get the error message at model startup
COM port not found
.This PR adds the possiblity to disable/enable the ComPort plugin by property and/or events.