Lumiera/ConfigLoader is a brainstorming about our configuration file loader.
does only initialize the variables, so that they get valid values, but does not allocate them as they will be allocated before as they are singleton.
lumiera_config_init (const char* searchpath) searchpath is a buildin-default, can be changed via configure and can be appended and overridden by using a flag, e.g. --config-path-append="" or --config-path=""
frees all space allocated by the ConfigLoader.
reads one single configuration file that will include all settings from other files.
does not read itself but give delegates reading. The actual reading and parsing will be done in configfile object. s.later.
finds out which files are dirty and which settings have to be written to user’s config files.
does initiate the actual saving procedure by delegating the save to the actual configfile objects, see below.
empty user configuration files in RAM will be deleted from disk on write.
checks whether the file has changed since last read, and will print out an error if necessary instead of overriding it without notification.
handles internally everything as string:string key:value pair.
lumiera_config_integer_get (const char* key, int *value) will return integers instead of strings and return 0 if succeeded and -1 if it failed.
set will create a new user configuration file if it does not exist yet or will append a line to the existing one in RAM. These files, tagged as 'dirty', will be only written if save() is called.
lumiera_config_TYPE_set (const char* key, TYPE*value, const char* fmt) Highlevel interface for different types, fmt is a printf format specifier for the desired format, when NULL, defaults apply.
reset a value by key to the system default values, thus removes a user’s configuration line.
Find exact place of a setting.
we might need to implement some cursor api to retrieve all values with the same key, this should allow to filter keys from single files!
integer_set("foo.bar", 123) looks up "foo.bar" this returns as well file and line it will be decided whether it’s a system file or a user’s config file. if systemfile: loop for user’s config file, if necessary create it in our RAM but not yet on disk set the value in the line.
stores the line exactly as read from file, but holds as well pointers to the key and the value.
config settings are key:value pairs where the key is a hierachical string as in "foo.bar.baz"
[01:21] <cehteh> joelholdsworth_: you seen the upcoming config interface i planned with simav?
[01:21] <mno> what about using ardours icons to start with?
[01:23] <joelholdsworth_> sections and keys?
[01:23] <joelholdsworth_> or is it treelike?
[01:24] <__nasa__> Have you all see Agave (for colorscheme generation)?
[01:25] <joelholdsworth_> cehteh: ooh - does mean we can levarge an ini parser?
[01:34] <joelholdsworth_> well is [plugin radius] the same as [plugin.radius] ?
[01:38] <joelholdsworth_> "ordered by the leaves" ?
[01:38] <__nasa__> Here is what I think is cool about the setup: it means that we can treat builtins and plugins the same.
[01:40] <joelholdsworth_> oooh! - have you thought of simply using libconfig?
[01:40] <__nasa__> joelholdsworth_: that format looks a little painful, but it could work.
[01:41] <cehteh> imagine you want to configure things by 'topics' ..
[01:43] <__nasa__> joelholdsworth_: It does look similar to JSON, but more C-like. For example, there are semi-colons instead of commas at the ends of single values.
[01:44] <__nasa__> So if anything does go wrong, the user can fix it.
[01:45] <__nasa__> I think that INI is much easier to read than libconfig, even though I have been programming in C for years and I have never edited a windows INI file.
[01:46] <__nasa__> about:config is so nasty.
[01:49] <__nasa__> which libini? There are quite a few.
[01:49] <__nasa__> I assume the SF one is the best, as it is GPL.
[01:52] <__nasa__> It looks like libini uses [plugin/blur] instead, but that is an easy fix.
[01:59] * __nasa__ thinks it should PRE. That way we don't have to totally agree.
[02:00] <__nasa__> sorry -- PCRE.
[02:00] <__nasa__> I always think of it as "Perl Regular Expressions" and forget the "Compatible"
[02:01] <__nasa__> I was thinking in terms of plugins/blend vs. plugins.blend.
[02:02] <__nasa__> We should have some way to only include certain sections.
[02:06] <__nasa__> There should be a callback for a plugin to add a config file for that plugin.
[02:07] <__nasa__> Then, for example accessing plugin.shade.
[02:07] <__nasa__> either find it in ~/.lumi/config/config.ini or ~/.lumi/config/plugin/config.ini.
[02:19] <__nasa__> Yeah, I do like that structure.
[02:19] <__nasa__> It also makes mass configuration setup very easy.
[02:21] <__nasa__> like they are not all config.ini?
[02:22] <__nasa__> Ok, I see.
[02:26] <__nasa__> in like the plugin/blur folder?
[02:34] <__nasa__> Ok, that makes sense. Good idea!
[02:35] <__nasa__> I was thinking suffixed are only allowed at the e.g. plugin/ level if they effect multiple plugins.
[02:37] <__nasa__> on/off or true/false?
[02:37] <__nasa__> Well, either way.
[02:41] <__nasa__> "Weaken the blur effect"
[02:41] <cehteh> if there was a bool with 'yes' then it will choose 'no' ..