Change Details

Workbench preferences are currently stored/managed via blueberry (a.o. berryIPreferences...). That leads to the fact that you only can use preferences, if you are on the plugin level, but not on the module level. That limitation was already problematic in some cases. (E.G. NodeSelectionDialog had to be moved to a plugin in order to use preferences). Also now it makes problems in T29019. A clean solution would be to offer a microservice interface for preferences and implement a micro service that is just a wrapper for the blueberry preferences and will be instanciated in the application core plugin.

Workbench preferences are currently stored/managed via blueberry (a.o. berryIPreferences...). That leads to the fact that you only can use preferences, if you are on the plugin level, but not on the module level. That limitation was already problematic in some cases. (E.G. NodeSelectionDialog had to be moved to a plugin in order to use preferences). Also now it makes problems in T29019. A clean solution would be to offer microservice interface for preferences and implement a overhauled, tested micro service Following open questions: # Is the already existing PersistenceService there for in good shape and is its API style OK? # Is wrapping the blueberry preferences a better solution? # Should there by from the micro service layer the possibility to reach informations of the plugin layer. Or do we want to seperate this layers on purpose? If seperated we should reduce the use of blueberry for persistance to the needed minimum (when it is realy information that is only needed by code that is a plugin.

Workbench preferences are currently stored/managed via blueberry (a.o. berryIPreferences...). That leads to the fact that you only can use preferences, if you are on the plugin level, but not on the module level. That limitation was already problematic in some cases. (E.G. NodeSelectionDialog had to be moved to a plugin in order to use preferences). Also now it makes problems in T29019. A clean solution would be to offer a microservice interface for preferences and implement a micro service that is just a wrapper for the blueberry preferences and will be instanciated in the application core plugin.a overhauled, tested micro service Following open questions: # Is the already existing PersistenceService there for in good shape and is its API style OK? # Is wrapping the blueberry preferences a better solution? # Should there by from the micro service layer the possibility to reach informations of the plugin layer. Or do we want to seperate this layers on purpose? If seperated we should reduce the use of blueberry for persistance to the needed minimum (when it is realy information that is only needed by code that is a plugin.