Force a category for the Settings of a Plugin

• Feb 15, 2016 - 10:55
Reported version
2.1
Type
Plugins
Severity
S4 - Minor
Status
active
Project
MuseScore

This task is an improvement thought up after some remarks in this forum thread

A Plugin can use the Qt.labs.settings method to store its settings, which are then incorporated into the .ini/.prefs file of MuseScore. These settings are namespaced by the category property of that object.

If a developer does not set the category property of the Settings object in his/her plugin, those settings are included in the main MuseScore group within that file. This means it is likely that a plugin could also overwrite the actual settings from MuseScore itself if a name collision occurs.

The proposition is the following:
1. A plugin has no Settings -> nothing to do
2. A plugin has Settings and specified a category -> nothing to do
3. A plugin has Settings but didn't specify a category -> autogenerate one based off of the pluginName

A sidethought for situation 2. Would we want to block plugins from changing the MuseScore settings at all? If a plugin explicitly defines the MuseScore category, it could still lead to collisions…

Sidenote 2: I haven't tested if multiple Settings objects can be used within one plugin. If so it could be useful for a plugin to explicitly read out Settings in the MuseScore namespace. However I think that there is no way to provide read-only access via a Settings object.
In that case (if the need should arrive) it might be better to add a string MS::getSetting(string key) function allowing the readonly access.

Comments

• Jul 1, 2016 - 15:49

Some basic test conclusions:

  1. A plugin can use multiple Settings objects with different categories
  2. A plugin can currently change MuseScore settings

Those settings are taking effect as soon as the QQmlComponent for the plugin creates the plugin from its data. It therefor seems that the only way to intercept these constructs is to analyse/alter the plugin code.

We could perform the analysis only from within the PluginCreator and show a warning message (either popup or in the console over there) about missing/conflicting categories.

I feel we should also perform the verification when loading plugins 'normally' and possible enforce the categories to be prefixed with the pluginName. That way we would avoid cross-plugin corruption and safeguard the MuseScore internal settings.
Although this would limit the plugins in access to the MuseScore settings (no plugin to reset window positions for example), I still believe this would make sense.

Any other thoughts?

Reply

• Sep 8, 2017 - 22:02

I've had a little bit of hope that we could analyse the parsed value of a category setting on a the settings object; but it currently seems quite hard to do this.
It is possible to have a plugin be instantiated in two steps by using beginCreate and endCreate rather than the create method (see also http://doc.qt.io/qt-5/qqmlcomponent.html#beginCreate )

However, it seems that the Settings part is not listed in the 'public' accessible children of the object, but is hidden behind a QScopedPointer in the private space.
Additionally it value is then contained in a QQmlSettings object, which in itself is hardly document as it is part of the Qt.labs modules. Haven't figured out yet which header to correctly include to access it.

Reply