I was sitting on a train for a long time yesterday afternoon, and brainstormed the following. Please tell me what you think!
Peter
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.
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.
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).
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).
2. A relatively small number of types would be available for
configuration values. These would include:
- Booleans
- Integers
- Strings
- Scheme procedures
- gEDA objects (basic or compound)
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.
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.
- 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.
- 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.
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.
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.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
