72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
|
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
|
-
+
-
-
-
+
+
+
+
+
|
Apart from providing aliases for the base types, a plugin API might provide its own custom set of setting types:
| type | alias | usage |
------------------------
| `int` | `integer` / `numeric` | numbers |
| `bool` | `boolean` / `checkbox` | true/false |
| `str` | `string` / `numeric` | string |
| `str` | `string` | string |
| `select` | `multi` / `dropdown` | see select: alternatives |
| `text` | `textarea` / `long` | longer `string` type (= renders as textarea) |
| `color` | `rgb` | graphical color picker |
| `file` | `filechooser` | setting should be a valid filename |
| `table`| `csv` / `list` | for supporting more complex (Excel-style) setting lists. |
| `dict` | `hashtable` | complex dictionary (Excel-style) setting field. |
Again, supporting base type aliases (str=string) is very advisable. But complex types (table/dict) often cause too much effort for basic plugin/config systems. There's no need to cram in support for rarely used features.
## Other fields
Other per-config `{…}` attributes migh encompass
| `category:` | grouping config options (else inherited from plugin) |
| `class:` | either decoration or additional type qualifier |
| `arg:` | declares a commandline argument instead of global app setting |
| `param:` | plugin invocation argument instead of global app flag |
| `class:` | either decoration or additional type qualifier |
| `arg:` | declares a commandline argument instead of global app setting |
| `param:` | plugin invocation argument instead of global app flag |
| `help:` | longer tooltip to use in config windows |
| `hidden:` | omit from config dialogs (field thus only used as init default) |
There's some paritiy with the main plugin meta fields. Except that config entries should not have a nested config: attribute, of course^^
## Storage and key `name:`
Notably this scheme just defines a list of available options. It does **not**
|
134
135
136
137
138
139
140
141
|
136
137
138
139
140
141
142
|
-
|
## Purpose
Once config options are easily parseable, it quickly pays off to implement
a centralized option/admin UI. And it sometimes can be combined with plugin
configuration itself. Which is why plugin meta data defines this simple
scheme.
|