ringdove knowledge pool
Comparison of Ringdove and gEDA
| vs_geda2 by Tibor 'Igor2' Palinkas on 2023-04-01 | Tags: insight, geda, gschem, pcb, gerbv, difference, comparison |
Abstract: List and describe similarities and differences between Ringdove and gEDA. Intended for readers already familiar with gEDA. Philosophycal aspects.
Ringdove
What's Ringdove EDA?
Ringdove EDA is a free/open source EDA suite. Target audience is hackers, UNIX users, command line wizards. Ringdove is a toolkit of independent projects. There are multiple workflows possible within Ringdove and any part of any workflow can be easily replaced with external software.
How does it differ from gEDA?
Ringdove tries to take and advance the good ideas from gEDA while learning from but leaving out the bad ideas. A few examples:
- Ringdove is a toolkit too, but Ringdove does make its graphical subproject look and work alike (similar menus, similar hotkeys, similar UI logic).
- Ringdove is a toolkit too, but that doesn't mean tools have to be developed in isolation. Ringdove has an emphasis on supporting workflows and features that arc over multiple tools, relying on open exchange file formats and protocols, without introducing excess integration, keeping parts replaceable
- Ringdove lets users to use their own build scripts (e.g. Makefiles), but this doesn't exclude an optional Ringdove-wise project file that can contain project-specific configuration in one place, one format, that is then understood by all Ringdove apps.
- Ringdove offers multiple GUI options (gtk2, gtk4, lesstif), but the generic heavy lifting of the GUI is done in a common library, librnd, so all Ringdove apps offer all GUI options and we don't have to redundantly code for a new GUI in each app.
- Ringdove apps can be scripted, but scripting is optional, does not impose mandatory dependency on guile, python, etc. For that optional user scripting, one can choose from more than 12 scripting languages in Ringdove apps.
Fine, but how that could be better for me in practice?
- if you struggle with the fundamentally different menus, hotkeys and UI logic of gschem/lepton and gEDA/PCB and gerbv: sch-rnd/pcb-rnd/camv-rnd all have very similar menus and keys and UI
- no guile or python dependency, no hardwired gtk dependency
- Ringdove has a suite-focus so if you have a bugreport or feature request that needs change in more than one app, it can still happen quiet easily
- there is working back annotation from pcb-rnd to sch-rnd; sch-rnd can semi-automatically perform many back annotated modifications on the sheet if you request
- can load a growing number of alien formats: boards, footprints, sheets, symbols of other EDA tools
Why a new, separate EDA suite?
I had a vision of how a proper UNIX/toolkit/free EDA suite should work. It included cooperation between developers of different tools. It included thinking about features from a workflow/suite point of view. It included fixing a few design decisions in some of the existing tools.
Originally, when I already had pcb-rnd, I tried to convince other developers in gEDA about this vision. They didn't share any of it and refused to cooperate.
Having to split my attention to so many different tools instead of being able to concentrate on one (for example pcb-rnd) is clearly suboptimal. Having others working on sch editors, gerber viewers, autorouters, etc., would have been much easier. So I really tried hard, probably for too long, but failed to bend gEDA to at least converge with my vision. So my only option was to implement my vision in a new EDA suite.
But then Ringdove competes with gEDA!
Yes. The same way as it competes with KiCAD or Eagle. The same way lepton competes gschem. Or gschem competes lepton. (It all depends on which one is your default, the other one would be the competitor to it.)
Healthy competition is not bad.
sch-rnd
What's sch-rnd?
It is a schematics capture software written from scratch (it is not a fork of anything existing). It is part of the Ringdove EDA suite. It implements the cschem data model. It uses librnd so it looks and works similar to pcb-rnd and camv-rnd.
It supports multisheet design, optional project files, portmaps/devmaps, hierarchic design, back annotation from pcb-rnd. Later on will support real buses.
How does it differ from gschem/lepton?
Here is a long, technical list of the major differences.
Most importantly, it is not a gschem rewrite but a brand new schematics capture tool, designed from ground up for Ringdove, so it differs on many levels:
- different data model, different terminology (kept the flexible attribute approach)
- different UI logic, menus and hotkeys (rule of thumb: make it simialr to pcb-rnd to keep Ringdove consistent)
- different file format
- different overall architecture (there's no separate netlist process, exporting netlist is simply an export format plugin, just like exporting png or ps)
- differences in attribute interpretation: different attribute names, differences in how slotting works, how the transistor problem is solved
So knowing gschem doesn't immediately mean one can use sch-rnd fluently. sch-rnd's learning curve is about only as steep as gschem's was. However, sch-rnd has excellent tutorial videos , following these videos learning the whole thing should take only about 2..3 hours.
Fine, but how that could be better for me in practice?
- similar UI to pcb-rnd and camv-rnd
- the GUI understands nets so it offers ways to figure which graphical objects ("wires") and attributes contributed to a given net and can assist you to find them in a multisheet project
- in fact this is even more generic (called the explicit abstract model) and works for figuring what symbols contributed to a component or how the specific properties of a pin (e.g. pin number) were derived from which symbols and terminals
- no guile or python dependency, much easier to compile, won't break on your next OS upgrade
Why didn't you just fork gschem/lepton?
There are some fundamental design decisions in gschem that would have been very expensive to change. For example that gschem doesn't know about nets or that some of the flexibility is implemented only in gnetlist but the conclusions/output of gnetlist can not be fed back to gschem.
For me, as an user, gschem and lepton were a huge pain to compile and keep up to date. Mostly due to the guile (and in case of gschem python) dependency. It make life much easier to loose those unnecessary dependencies.
Unfortunately a big part of gschem is written in scheme and/or python. Lepton went even further and actively converted more C code into scheme. The problem is that I don't speak neither scheme nor python, which means I couldn't have maintained those parts of the code.
A very important goal was to make sure applications of the EDA suite look and work similar. This includes having the same config file conventions, similar menus, similar hotkeys, similar UI logic. Huge parts of gschem/lepton would have to be rewritten to meet this requirement.
These three combined leads to: a fork would have been much more expensive than a clean rewrite.
pcb-rnd
What's pcb-rnd?
It is a Printed Circuit Board editor software originally forked from gEDA/pcb, with vast majority of the code base changed or rewritten since the fork. It is part of the Ringdove EDA suite. It uses librnd so it looks and works similar to sch-rnd and camv-rnd.
It supports any drawing object on any layer in footprints. It supports editing every layer (fab layer included). It has padstacks with real slots. It has a scriptable DRC. It can load KiCAD, eagle, altium, protel boards and footprints and BXL footprints.
(Plus a lot more formats and features I am not going to list here).
How does it differ from gEDA/PCB?
I used to have a list of improvements. It grew too large so I tried to maintain a list of major improvements only. Grew too large too.
Here is a very small subset, a datasheet-like, technical list of the major differences.
In short: gEDA/PCB is mostly the feature set of PCB editors from the '90s; pcb-rnd with all the extra features and the new data model is more like how PCB editors work in the 21st century.
Fine, but how that could be better for me in practice?
If you ever bumped into any limitation in gEDA/PCB, something you had to work around with multiple smd pad objects, hand-editing the file, objects that should have been part of an Element really drawn directly on the board next to the Element... Or had to manually search and tweak things because there was no way to get PCB find the given objects and select them and no action to change the specific property on all selected objects...
... there's a very high chance pcb-rnd has already fixed that.
Plus pcb-rnd already offers a gtk4 HID (while also maintains the gtk2 HID).
camv-rnd
What's camv-rnd?
It is a PCB related CAM (Computer Aided Manufacturing) file viewer. It can display multiple gerber, excellon and g-code files.
How does it differ from gerbv?
It uses librnd so it supports all GUI HIDs pcb-rnd and sch-rnd does, including both gtk2 and gtk4, while gerbv depends on one specific version of gtk.
Gerbv's internal structure mixes gerber parsing/executing with GUI rendering. This has far reaching consequences on fixing gerber rendering bugs, introducing new GUI frontends or new file formats. In contrast, camv-rnd loads any file format into a very simple, flat, static data model and the renderer works from that data model. Having the flat model in between makes it very easy to implement loaders for new file formats. It also guarantees that a new GUI HID in the future will automatically work with any file format.
Fine, but how that could be better for me in practice?
While developing camv-rnd, I wrote the gerber parser from scratch. I actively looked for corner cases and tested them with ucamco's reference gerber viewer (ucamco is the maintainer of the gerber format) and made sure camv-rnd renders the same. While doing that I also tested the same files with gerbv and the version of gerbv at date failed to render some of the test cases properly.
Is there more?
Yes.
There's librnd that is the common, generic part of the GUI apps. It doesn't know anything about the apps, their data models, their data file formats, their menus, but contains all the shared code for GUI HIDs, dialog box API, menu systems, the configuration system, the plugin system, user scripting. This means:
- Ringdove GUI apps look and behave very similar to each other
- the config system, config file format, menu files, user scripting, plugin control are all the same in the GUI apps
- if there's a new GUI HID, it automatically works with any Ringdove app
- if there's a bugfix in any of the common infrastructure, it affects all Ringdove apps
Furthermore there's an external PCB autorouter called route-rnd and an user contributed symbol/footprint/devmap/script collection called edakrill (which is somewhat similar to gedasymbols.org).
It's likely that there would be further smaller projects added to the suite later.