> New configuration mechanism > =========================== > > There are several issues with the current gEDA configuration system, > particularly as regards component libraries. > > Firstly, no distinction is made between the system configuration, the > user configuration and the per project/directory configurations. This > would be a particularly useful distinction to make when it comes to > providing an interface to manipulate the configuration, something > which gEDA (in particular gschem) sorely needs.
PCB is somewhat bad in this respect too.. it saves a lot of state to ~/.pcb/, so if defaults change in the system config files / code, they won't be seen by existing users. Perhaps I'm just thinking of the education case where we might want to roll out new "sensible" defaults for users who won't necessarily have changed settings explicitly, but have already run PCB. > Secondly, there's no provision made for saving/restoring > configurations. This is a major issue when it comes to settings which > affect the GUI, such as the colour scheme, and the component library > system. At the moment, component library configuration settings > changed in a project gafrc affect every file loaded. We probably need to split out from the section where rc files are applied, an option to apply a setting "locally" to one TOPLEVEL / GSCHEM_TOPLEVEL, rather than setting defaults to be used globally. We might then make a per-project / dir gafrc explicitly apply only to the TOPLEVEL context which caused it to be loaded. > Finally, not every configuration setting is adjustable at runtime -- > some things are finalized when the GUI starts -- and some values are > not available to be inspected from Guile (the component library items > are notably bad in this respect). > Other (relatively) minor problems include the lack of a way for > applications which use libgeda to hook their own config settings into > the libgeda configuration mechanism, and the large number of places in > which things need to be added in order to provide a new setting for > customisation (helper functions for getting and setting, and explicit > registering of the functions with the Guile interface). I agree with this, and it lends its-self to a "database" of name=value settings, rather than the current system where every setting has a variable in a struct somewhere. The code to load said config options (or register guile functions to do so) can then be all in one place in libgeda, without needing parts to be in gschem to modify gschem specific data-structures. PCB has code which does similar, where settings are specified with a name, default value, bounds checks? (from memory), and can be defined in various places. I'd suggest doing similar. Perhaps each functional block (libgeda / gschem / gnetlist / gattrib) could keep its own list of settings, rather than having it all part of a single name=value list in libgeda. That ought to help root out the abstraction breaks we have currently where settings defined and loaded in gschem are used in libgeda. (This will break as soon as say, gschlas wants to print with some colours defined in gschem). > Ideally, a new mechanism would take the following form: > > 1. Each configuration option would be identified by a string, of the > form ``appname.optionname``. Options affecting libgeda directly > would be called ``core.optionname``. These strings would always be > used whenever reading or writing config values. (The naming > convention would not be enforced). I'm not opposed to that. I had a slight preference for flat naming, but I guess if we're not enforcing the convention, its ok. Such a scheme introduces basic namespacing to the config system, which might be handy. Would you still keep separate gschemrc, gafrc, gnetlistrc files, or roll these into one? > 2. A relatively small number of types would be available for > configuration values. These would include: > > - Booleans > > - Integers > > - Strings Agree > - Scheme procedures Fine.. presumably used to set hooks etc..? (On that.. how would we register multiple hooks? I assume you're proposal would preclude the use of directly executable scheme, such as (register-foo bar) in the config files. Would you insist on one scheme function being registered to dispatch call the others, or would registering the same name=value config setting add an _additional_ config pair? To say that again more clearly... does having two name=value pairs with the same name over-write the old config key, or does it mean two config keys exist with that name? > - gEDA objects (basic or compound) Ok - although I'm weary of defining a scheme interface for those yet, as its more structure which could break users if it were to change. On the other hand, I'm not sure its useful to just dump a serialised geda file-format block of ASCII into a variable, as that is far less scheme manipulable. I think we need to polish the libgeda API first, then write the scheme bindings for it, then think about allowing gEDA object types - although there is no reason not to design for it being possible in the future. > The number of additional value types added would have to be kept to > a minimum in order to keep the interface simple. The configuration > mechanism would provide functions for converting the values to and > from their equivalent Scheme representations. The GValue API might > be used to good effect here. Ack > 3. The current configuration would be represented by a "configuration > context". It would be possible to carry out a number of different > operations on the context: > > - Save and restore the context. For instance, this could be used > to "remember" the system and user setups, and to quickly switch > between different configurations for different projects. We want to differentiate settings which have been changed explicitly by the user too. I don't want to fall into the trap where a user changing one preference and saving their "config" means gschem now loads all its settings from their per-user config unless this is explicitly asked for. > - Export to a Scheme script which, when evaluated, would recreate > the configuration context. This could be used to automatically > store a user's or project's settings or even to implement a "save > workspace" feature in gschem. Ack, that would be nice. > - Get or set the value of a particular configuration setting. > Setting the value of a setting for the first time would also > implicitly register the name and type of that parameter. This > could be used to avoid the necessity of a explicit function for > registering which settings are available and their types. I'm not sure about this. If a config line is to be useful, it has to be coded somewhere. Having them defined in a list somewhere allows more flexibility in offering a gattrib style view of "all possible settings", rather than having it only possible to set config settings where someone has coded a dialog for it specifically. > The context would emit a signal whenever a setting is modified. > This would make it possible to efficiently handle configuration > changes which require updates to the GUI. Sounding more and more like gconf here, that has per-user and per system settings too ;). I know we can't depend on gconf though as its Gnome - so no flames please. > 4. All of the functions for manipulating the configuration context > would be available from Scheme (although they might not take an > identical form). > > Unfortunately, implementing such a scheme would require significant > changes to a large proportion of the gEDA codebase, and would be > unlikely to provide useful back-compatibility with the existing > mechanism. However, the vastly increased flexibility which such a new > system would provide would more than offset this disadvantage. This I can't give an opinion on, but I agree that it would be good to have the above benefits. I just hope it doesn't bring a raft of demands for more config options where "sensible defaults" would be more in every-ones best interests. Peter _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
