gEDA Library v3 Specification

Rationale

The current version (2.x) of the libgeda shared library has a number of defects:

This page is an attempt to itemise in detail what is required of libgeda, and what the interface to it should look like. This will enable:

Requirements

Core

  1. Define data structures for representing schematics
  2. Provide methods for creating and manipulating schematics
  3. Provide methods for reading and storing schematics into files and data streams
  4. Provide access to detailed data on errors and exceptions
  5. Provide a simple interface for configuring libgeda's behaviour

Secondary

  1. Make no assumptions about applications which will use the library
  2. Make no assumptions about the compiler or architecture on which the library is being used
  3. Fully reentrant for thread safety
  4. Minimise number of dependency libraries
  5. Detect and gracefully handle multiple instances accessing the same schematic file

Coordinate System

Because libgeda should “make no assumptions about applications which will use the library,” libgeda should use only “world” coordinates throughout (the same coordinate system as used in the files). See the file format specification.

Configuration

Currently, libgeda relies on an embedded Scheme interpreter (Guile) for configuring settings such as library search paths. This has a number of pros and cons:

Pros:

Cons:

It might, therefore, make more sense to provide a complete API for configuring libgeda, and rely on the application to handle the storage and loading of the configuration.

Dependencies

glib

glib provides a very large number of useful features that would make writing and maintaining libgeda easier. These include:

Not having to reinvent the wheel – and letting a much larger project be responsible for optimising and maintaining these features – would make the libgeda code smaller and easier to understand and maintain. libgeda already uses glib to a certain extent, but using it more extensively in future versions of libgeda does not immediately seem to be a bad idea.

gobject

gobject is an object-oriented programming system in C. It is used extensively in the GTK+ user interface toolkit. In addition to class-like structures, it provides a signalling system that allows objects to emit, listen for and respond to events. It is designed to be compatible with the object systems of other languages, and this is one of the chief reasons that so many bindings of GTK+ are available (Python, Perl, .NET, Java, C++, etc).

gobject is often considered to be heavyweight, requiring lots of boilerplate code in order to use it effectively. Its use in libgeda has historically been opposed, though its use in future versions may ease creation of bindings for libgeda in more directly object-oriented languages such as Python, Java or C++.

GObject is currently used in libgeda for the GedaList class which wrapps a GList, and provides a notification signal when API is used to modify the list.

References