This comparison is dry and datasheet-like, focused on details. There's a more philosophycal comparison also available.
This document focuses on suite-level comparison. Per software comparison is also available for major components of Ringdove:
There is also a history and motivation document available that describes the rationale behind Ringdove.
| property | Ringdove | gEDA |
|---|---|---|
| Project type | EDA suite | umbrella |
| Integrated? | no | no |
| similar UI? | yes | no |
| Consists of... | ||
| sch editor | sch-rnd | gschem, lepton |
| pcb editor | pcb-rnd | pcb |
| gerber viewer | camv-rnd | gerbv* |
| circuit simulator | (external) | gnucap*, icarus* |
| pcb autorouter | route-rnd | pcb |
| (misc) | n/a | gtkwave |
| GUI dependency | multiple, same | sparse, per project |
| other dependencies | minimal, optional | various |
| user scripting | flexible: 12+ languages | limited (or none) |
| back annotation | yes | mostly no |
| plain text native file format | yes | yes |
| file format is a tree | yes | no |
| modularity | high | moderate |
| 3D support | yes, external | no (partial/unusable) |
Both Ringdove and gEDA is a collection/group of separate EDA related projects. Both Ringdove and gEDA have very little or no code of their own, but they both merely wrap the code of those software projects prticipating.
Ringdove EDA is an EDA suite which means the Ringdove project is actively coordinated to achieve a generic, more abstract goal as a whole. Subprojects have their own local goals, but they are also developed consciously with Ringdove goals in mind.
gEDA is an umbrella project, which means it's a collection of GPL'd software that work together, but there's no explicit coordination between development of these projects. No explicit common, gEDA-level goals defined.
An integrated EDA suite means different parts of the project, typically the schematics capture, the simulator, the PCB editor, the gerber viewer, are all integrated into a single software package, often into a single UI. In an integrated suite it's often harder to replace one part of the workflow with a 3rd party software.
Neither Ringdove nor gEDA is integrated. Ringdove consists of independent software projects for each part of the workflow. These project all have their separate source repository, release tarballs, release cycles, etc. Any part of the workflow can be replaced easily.
Replacing a part of the workflow heavily depends on file format support. Within gEDA: gschem and lepton offer many netlist output formats which means it is easy to replace the PCB. However, geda/pcb does not offer importing from too many different netlist formats, so replacing the schamtics capture part is much harder. Also, neither gschem/lepton nor pcb offer loading or saving schematics/boards in alien file formats which furhter limits the flexibility of the workflow. Thus, in practice, the actual advantages of no-integration can mostly be exploited at the output of the schematics editing phase.
In contrast Ringdove projects offer a growing number of alien format support. sch-rnd can load sheets and symbols of different open source and proprietary software. pcb-rnd can work from a dozen of different netlist formats and can load boards and footprints of many other free and proprietary software. pcb-rnd can even save boards in some of the alien file formats. Due to the explicit goal and strong I/O framework, the number of alien file formats supported is ever-growing.
While both Ringdove and gEDA offers separate software projects for the stages of the design workflow, Ringdove explicitly aim to make the UI of those projects similar. This includes:
In contrast, there's no much similarity in how different subprojects of gEDA do any of these. They all come with totally different GUI and CLI, radically different configuration and each force their own different "one true way" of user addons/scripting.
Whether a project is part of the gEDA effort is often not easy to tell. gEDA itslef lists a bunch of projects it considers part projects, but some of these projects do not reference back to gEDA (don't explicitly regard themselves as part of gEDA) and do not use the infrastructure or community provided by gEDA.
gschem and pcb are clearly part of gEDA; lepton is mostly part of gEDA, although it clearly has its own parallel infrastructure for everything (including communication/community) but still active on the gEDA mailing lists.
The rest of the project gEDA lists as being part, marked with * in the table above, are fully detached: they have their own infastructure and their developers are not active on the gEDA mailing lists.
All GUI applications within Ringdove use librnd as a glue layer to GUI libs. This mean all Ringdove applications offer the same GUI options (as of 2023: lesstif, gtk2+gdk, gtk2+gl, gtk4, batch). This also means adding a new GUI option is cheaper, because it needs to be added only once, in librnd, and all Ringdove apps will automatically be able to use it, without any modificaiton on the app side. When librnd is compiled with multiple GUI plugins, every Ringdove app can choose which gui to use as a runtime option.
Note: librnd is a generic 2d CAD lib, it does not know anything about what kind of data model the application has. This means there's no central, integrated data model, no central concept of footprints, symbols or even atomic drawing objects. On the GUI side, librnd is merely a layer to unify the API of all the different toolkits.
In gEDA each project implements its own GUI directly using a random toolkit of their choice. For example pcb uses lesstif or gtk2+gdk or gtk2+gl (but the choice is compile-time). gschem uses gtk2+cairo only. gtkwave uses gtk2 and has an internal fork of the whole codebase, called gtkwave3, that uses gtk3.
The problem with this approach is: each project has to spend a huge amount of effort to keep up with gtk major version changes and at any given point in time it's very likely that different applications of gEDA use different versions of gtk.
Ringdove is very conscious about dependencies. librnd and the applications are all written in pure c89, with no external dependencies in core. This means no dependency on glib, boost, C++ compilers, python or guile. There are only optional dependencies: for example if you want to use gtk4, then you need to install gtk4 (and librnd ./configure will pick it up automatically; not having gtk4 won't make ./configure fail, just announce).
In gEDA, different projects have different dependencies. All major gEDA projects have hardwired, non-minimal dependencies. For example geda/pcb depends on glib even if it is compile without GUI support. Some of these dependencies are large and often hard to statisfy on upstream version transitions (e.g. how it is/was with guile 2 for gschem and lepton and how it is/was with python 2 for gschem and how it is gouing to be with gtk2 for pcb).
Since projects are not coordinated on gEDA level at all, dependencies are not coordinated either; the sum of all dependencies for a typical geda install is large, because of different projects bringing their different, often overlapping (in abstract functionality) dependencies. For example gschem/lepton depend on cairo (e.g. for rendering into pixmaps), while geda/pcb depends on libgd for that (e.g. in the png export hid).
Main or core features are implemented within the code base of a project, in whatever language project maintainers have chosen for the project. User scripting is a different category: it is when users develop their own smallish addons that are not becoming the part of the base project. User scripts are those scritps that run within the application - so an external Makefile or shell script that calls different tools is not considered user scripting in this document.
Ringdove offers user scritping in more than 12 scripting languages. Since the scripting language part is handled in librnd, all scrpting languages are accessible to all Ringdove apps. The number of supported languages is ever-growing. A few basic scripting API is provided by librnd so an user script can do the same thing using the same API in any Ringdove app on many tipics, including:
Furthermore each app provide app-specific API for accessign the data model.
In contrast, gEDA proects typically restrict user scripting to 0, 1 or 2 languages. geda/pcb has a single language, "pcb action script" (not turing complete). Lepton can be user scripted only in scheme. gschem offers scheme and python. There is no common minimum functionality that all apps offer scripting API to, and even when they offer API to similar functionality the API may differ from app to app.
A growing number of modifcations (pin swaps, footprint changes, etc.) can be made in pcb-rnd in a way that the locally made difference is tracked, not overwritten by a subsequent forward annotation and can be back annotated to sch-rnd. In turn sch-rnd can track of modifications required by back annotation, can assist the user to perform them or can even perform many of the modofications automatically, upon the user's request. Tutorial/demo video available.
In gEDA, there is a relatively unknown feature in pcb that can export a connection list that was supposed to be used for back annotation. There's still some code in gschem and lepton to deal with this, but I am not aware of anyone using this or any tutorial being available.
Back in 2016, when pcb-rnd first implemented back annotation, target was gschem; gschem later on merged in the feature, so it probably still has it. However, this version of the back annotation is very much limited, mainly because gschem (and lepton) lacks the most basic featuers in their data model. Most notably: gschem/lepton GUI is not aware of nets. Lepton never merged this feature. geda/pcb never reproduced this feature.
In Ringdove native file formats can represent a generic tree. In gEDA native file formats are either flat or are limited to a tree of 2 levels.
In case of pcb-rnd vs. pcb this makes it easily possible for pcb-rnd to have any object type on any layer in a footprint, while geda/pcb offers a very limited range of objects and layers in footprints.
In case of sch-rnd, this simplifies the data model a lot, because objects can be grouped and groups can be put in groups, thus there's no need for a special temrinal (or pin) object type. Instead a terminal is just a group (within a symbol group) containing whatever drawing objects (typically a line).
The native file formats used in Ringdove are not positional but work with named fields.
These design decisions make it very easy to extend the file format in a backward-compatible any time. In contrast, gEDA projects often struggle with features that can not be implemented easily or cleanly because they would require major changes in the rigid file format. (Typical example: geda/pcb freely editable paste or mask layer.)
Subprojects of Ringdove are highly modular: most of the code is typically implemented in optional plugins. This goes so far that even the native file format is just an optional plugin. This allows much higher flexibility, because parts of the code that could be considered core feature can be replaced by different code at the user's decision. Meanwhile in gEDA, most projets are much less modular.
For example geda/pcb has the GUI and export code in plugins, but everything else, including board/footprint file formats and and netlist file formats are hardwired in core. Adding a new file format or replacing the native file format with the user's own code in pcb-rnd can be done using a 3rd party plugin the user maintains. Adding a new file format or replacing the native file format in geda/pcb is not possible without patching the core code.
Another, even more restricting example is how gschem/lepton does slotting. Normally slotting would be done by the netlist backend, so different backends could do it differently. But gschem/letpon has no concept of brining back backend conclusions to the GUI, that would be impossible to make visible on the GUI. Thus the slotting mechanism is hardwired in the core - which means there is one specific slotting that could work on the GUI, and it can not be replacing without patching the project. In contrast sch-rnd has slotting (and many other similar mechanisms) in optional, replacable plugins. The plugin calculates the slotting once and the result is used both for netlist export and GUI display. It's trivial to replace the standard slotting mechanism with another, user maintained plugin, purely via user configuration, without any modification required in sch-rnd.
For coparison: in geda/pcb 4.3.0, 37.2% of the code is in plugins; in pcb-rnd 3.1.1, 69.2% of the code is in plugins. However, in case of geda/pcb this included all the graphical HIDs, which, in case of pcb-rnd, are outside of the project, in librnd. Adjusting geda/pcb with this, removing GUI HIDs from the mix the ratio is even worse: only 19.6% plugins.
In Ringdove the question of 3D support is clearly decided: following the UNIX phylosophy "do one thing and do it well", Ringdove concentrates on electronics and not mechanics or 3D. Support for 3D is rather delegated to software specialized in 3D modelling, by strong support of 3D export from pcb-rnd:
Thus Ringdove does have full 3D support, with both export to mechanical CAD and (near) real-time preview as external tool. Furthermore pcb-rnd offers a dxf export plugin tat can export the board outline and holes (for 3D CAD programs).
Menawhile geda/PCB, as of 4.3.0, has a partial 3d implementation in the GUI if, and only if, opengl is enabled. This renders the board (but no footprint models), so all the user gets is the flat 2D board rotated in 3D. There is no 3D export support.