On Thu, 19 Oct 2017 14:28:27 -0200 Gustavo Sverzut Barbieri
<barbi...@gmail.com> said:
> > + get {
> > + keys {
> > + name: string; [[Configuration option name.]]
>
> shall we document and handle this as a path, so nested Eets can be
> used, such as in E (wm).
I'm not so sure this config API is "good enough". It is indeed very very
simple (string key to single value pair). But history tells me that this is
very limiting. I've been here before (edb) and i hit the limits of this pretty
fast. I needed SETS of things (a list of strings. a list of keybindings, a list
of whatever) very quickly. I think that this should be an API which allows
nesting and "sets" (ordered lists/array of items with the ability to append,
prepend, insert and remove) and probably also "hashmaps" as well (key -> item
lookup). yes. it's more complex, but at least it won't hit a wall really really
fast and then we need to extend this api so it begins to look a bit ugly after
extending.
also i'm not sure if it should also allow for fallbacks (look for val in config
store X - if not there, look in Y, if not there look in Z. this is common for
looking in user config first then falling back to system config ... but we don't
do it value by value atm... but needing to be able to defined where those
config stores are would be important big-picture, with probably a default of
system + user).
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - ras...@rasterman.com
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
