chiark / gitweb /
plugins: Support user configuration of default values for/aleph-objects master
authorIan Jackson <ijackson@chiark.greenend.org.uk>
Sat, 6 Feb 2016 18:09:18 +0000 (18:09 +0000)
committerIan Jackson <ijackson@chiark.greenend.org.uk>
Sat, 6 Feb 2016 18:32:04 +0000 (18:32 +0000)
commit0f5866f0c268d207b55801a7b22fb678b7a0100f
tree0a6be9ce6d802ebc93d57a3c5aca22311fc383e4
parentbe72c9ccd6157845f2b358cbca6a241aa172210b
plugins: Support user configuration of default values

Rationale:

When a new plugin instance is created with the GUI, it inherits the
default values as specified in the plugin itself.  If these values are
modified by the user they are stored in the print profile, of course -
but if the plugin is removed and re-added, the settings are reset.

A user who usually wants different default values could make a copy of
the plugin and edit the default values at the top of the plugin file.
However, this is not really a desirable approach.

New feature:

Here, we arrange for the user's plugin_defaults.ini file(s) to be
read.  Such a file contains sections named after the plugin basenames
(eg `[pauseAtZ]') and the values therein are simply named after the
plugin's own parameters.  This file may be found in
 ~/.cura/<VERSION>/plugin_defaults.ini
 ~/.cura/plugins/plugin_defaults.ini  (and other places cura looks for plugins)

The user is expected to look at the plugin itself to see what the
parameter names are, and to know the pathname of the file, and to edit
it by hand.  There is not any way to save these settings from the GUI.

I wasn't able to find anywhere where this could be properly
documented.  (Nor indeed does the plugin header syntax appear to be
documented, either - near there would be a natural place for the
config docs.)  So I hope this commit message is useful.

Note on implementation strategy:

These settings are read during the construction of each pluginInfo
object.  This is arguably not desirable, because it reads the
plugin_defaults.ini twice, and also because its seems like an
abstraction violation to have pluginInfo contain a configuraton
reader.

However, the 'default' element of each param is accessed in (at least)
two places: runPostProcessingPlugins and _buildPluginPanel.  I didn't
fancy trying to double-check that I had the semantics right, in all of
the relevant places.  And refactoring this area is beyond my present
understanding of the code.  In any case it is certainly arguably
proper to regard the default configuration setup as part of the plugin
loading process.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cura/util/pluginInfo.py