gEDA is the GNU Electronic Design Automation suite. For a while in Summer 2006 I was employed to work on it by Cambridge University Engineering Department, although I still use it extensively and sometimes fix some bugs.
Recently, I was involved in the switchover to using git for version control. I have a personal repository where some of my changes get put to mature; it can be cloned from:
git://repo.or.cz/geda-gaf/peter-b.git
You are likely to be more interested in branches other than the master, which tends to track the main git unstable branch.
Here is a list of some recent code changes I've made to gEDA.
| Component | Description | In git? |
|---|---|---|
| gschem | Position text drag placeholders right [#1740620] | 24-06-2007 |
| Fix sort-component-library option [#1589691] | 09-06-2007 | |
| Preview symbols from all types of symbol library | 28-06-2007 | |
| Add "refresh" button to component selector | 04-07-2007 | |
| Add "in use" view to component selector | 04-07-2007 | |
| General | Major cleanup of system-gafrc & related files | 22-06-2007 |
| Generate ChangeLog files from git | 23-06-2007 | |
| Scheme support | Better configure checks for Guile | 02-06-2007 |
| Remove some deprecated functions | 04-06-2007 | |
| Load symbols from buffers | 28-05-2007 | |
| Symbol library (libgeda, gschem) | New component library system | 28-05-2007 |
| Smarter handling of embedding | 28-05-2007 | |
| Load symbol libraries from commands | 28-05-2007 | |
| Guile functions for loading symbols | 28-05-2007 | |
| Recognize symbol files case-insensitively | 28-05-2007 | |
| Enable run-time library refresh | 23-06-2007 | |
| Better symbol search which caches results | 23-06-2007 | |
| Make command libraries more flexible | 04-07-2007 | |
| Better handling of libraries with the same name | 05-07-2007 |
Here is my current list of gEDA development jobs that need doing:
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:
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).
A relatively small number of types would be available for configuration values. These would include:
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.
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:
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.
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.