From: Ian Jackson <ijackson@chiark.greenend.org.uk>
Date: Sat, 6 Feb 2016 18:09:18 +0000 (+0000)
Subject: plugins: Support user configuration of default values
X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=cura.git;a=commitdiff_plain;h=HEAD;hp=be72c9ccd6157845f2b358cbca6a241aa172210b

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

diff --git a/Cura/util/pluginInfo.py b/Cura/util/pluginInfo.py
index 7fad6f58..90053888 100644
--- a/Cura/util/pluginInfo.py
+++ b/Cura/util/pluginInfo.py
@@ -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