gEDA

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.

Recent Changes

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

Todo List

Here is my current list of gEDA development jobs that need doing:

  • Symbol categorization
  • Show preview of top-level (unattached) attributes in component selector
  • Add buttons to component selector for editing the currently selected symbol, and refreshing the component library.
  • Ability to remove component libraries.
  • Ability to go down hierarchy into symbols from new component sources
  • Fix uses of deprecated Guile macros/functions. In progress.
  • Use guile-snarf to generate code for setting up Guile functions
  • Command-entry mode for gschem
  • Implement command and directory component sources in Scheme. Suspended, because of non-portability of some Guile pipe-opening procedures.
  • Change paper-sizes Scheme procedure to add-paper-size
  • Group paper sizes by type (ANSI, ISO, etc)
  • Dynamically generated submenus on gschem menu bar.
  • Saner names for component library related Guile functions.
  • Fix embedding bugs
  • Per-directory configuration contexts
  • Separate embedded symbol data & instances (and embed by default)
  • Make "In Use" library view only show symbols relevant to the current page.
  • Use GObject for gschem main window.

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.

Page Menu