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)
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

index 7fad6f58e839a9c891eb411e975ea52d534fe49a..9005388882e2fb5272790388c2b920a87777f8b6 100644 (file)
@@ -10,6 +10,7 @@ import traceback
 import platform
 import re
 import tempfile
+import ConfigParser
 import cPickle as pickle
 
 from Cura.util import profile
@@ -52,6 +53,27 @@ class pluginInfo(object):
                                # else:
                                #       print "Unknown item in plugin meta data: %s %s" % (line[0], line[1])
 
+                self._readSettings(os.path.join(profile.getBasePath()))
+                for plugindir in getPluginBasePaths():
+                        self._readSettings(plugindir)
+
+        def _readSettings(self, indir):
+                settings_file = os.path.join(indir, 'plugin_defaults.ini')
+                plugin_basename = re.sub(r'\.pyc?','',os.path.basename(self._filename))
+                if not os.path.exists(settings_file):
+                        return
+                cfg = ConfigParser.ConfigParser()
+                try:
+                        cfg.read(settings_file)
+                except:
+                        traceback.print_exc()
+                if not cfg.has_section(plugin_basename):
+                        return
+                for param in self._params:
+                        name = param['name']
+                        if cfg.has_option(plugin_basename, name):
+                                param['default'] = cfg.get(plugin_basename, name)
+
        def getFilename(self):
                return self._filename