X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=igor2.repo.hu; s=k1; h=Content-Type:MIME-Version:Message-ID:Subject:From:To
	:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
	List-Subscribe:List-Post:List-Owner:List-Archive;
	bh=pA3zXrIZZJBGjsf6T+5bXKNLbf5X1WXK62pdy5T88ac=; b=cWW8473CQW9vAdRMJYIA2i7pu6
	xcpOM1kkYIhvBwth9vS31/1zt2+yOiLtCvHwLKyeLZaEbBkxTWBQA5/lywR1jveINIPeAryD7vqK2
	Bdu7gQlQr+N4OYC2a/sjF3xf5ofBuT8Y4mYlDpMbkBcuCgh0adESv1lOA1WeDR6AFqEc=;
Date:	Wed, 3 May 2023 05:49:53 +0200 (CEST)
To:	geda-user AT delorie DOT com
X-Debug:	to=geda-user AT delorie DOT com from="grnd AT igor2 DOT repo DOT hu"
From:	"grnd AT igor2 DOT repo DOT hu [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Subject:	[geda-user] new EDA suite: Ringdove
Message-ID:	<alpine.DEB.2.20.2305030537420.25839@igor2priv>
User-Agent:	Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version:	1.0
Reply-To:	geda-user AT delorie DOT com

Hi all,

with sch-rnd 1.0.0 released, the Ringdove EDA suite also reached the first 
milestone: it now offers all tools that one requires for PCB design. It 
will expand of course, in different directions. Plus following the best 
gEDA traditions, even taking them a bit further, Ringdove member projects 
can be used separately, for different workflows, communicating with 
non-Ringdove software.


In Ringdove I believe I managed to solve a few problems that seem to be 
unresolvable in gEDA. This is because I took a step back and evaluated all 
the design decisions we took for granted in gEDA and made some changes in 
them for Ringdove. Since these give the major difference and you already 
know gEDA well, this mail is organized around showing those differences in 
details. I will try to show what I kept from the ideas of gEDA, what I 
changed and why I think the modified version is better.

A table-like summary is available online at:

http://repo.hu/cgi-bin/pool.cgi?project=ringdove&cmd=show&node=vs_geda

Some background in why I thought the good choice was to roll my own EDA 
suite:

http//repo.hu/cgi-bin/pool.cgi?project=ringdove&cmd=show&node=vs_geda2

Comparison of pcb-rnd and pcb:

http://repo.hu/cgi-bin/pool.cgi?project=pcb-rnd&cmd=show&node=vs_geda



1. toolkit vs. integration

Ringdove is a bit like gEDA: a set of mostly independent tool 
projects, each maintained in their own, separate repo. Each can be used 
without the others. Each can be replaced in the workflow with something 
totally different from another source. 

But I took it further. In gEDA, this is the saying, like if it was a real 
general thing. But what it really means is that gschem/lepton can export 
multiple netlist formats. So you can replace everything after 
gschem/lepton, and that's good. But unlike sch-rnd, gschem/lepton can't 
load sheet or symbols of other editors. Unlike pcb-rnd, pcb can't load 
boards and footprints of other EDA tools. And unlike pcb-rnd, pcb can't 
import a dozen different netlist formats, so it's rare that people feed 
pcb with netslists not coming from gEDA. Ringdove took it further by 
opening up the workflow at many more points.

Another major difference is that in gEDA, toolkit on the UI means that 
every single project looks and works differently and sometimes even 
have/had different GUI dependency. The most annoying aspect is the 
different mouse bindings. I know, I know, it's all configurable... but... 
really... Maintaining tools separately, making them replacable doesn't 
necessarily mean they have to make user's life harder by having 
unreasonable UI differences. Ringdove fixes this: the data model is 
different in each tool, but the generic UI logic, default mouse bindings, 
default hotkeys are the same. So it's easier to learn and switch between 
the tools, without any excess integration.

This goes deeper: in Ringdove the config file sytnax is the same and 
config file locations/customs are very similar too. So you don't have to 
learn 3..4 different formats because you need to use an sch editor, a pcb 
editor and forward annotation.

In fact these are so easy in Ringdove because there's a common, shared 
lib, called librnd, that offers a a HID API (similar to pcb's), a config 
API, and some other similar generic infrastructure. But it does not do 
anything for the data model. So when I need to interface a new GUI 
toolkit, like it was with gtk4, I work once, and all ringdove apps get the 
new GUI automatically. But this connection is only technical, librnd 
doesn't have any idea what the tools are doing, it merely provides the 
boring, generic, low level tasks (API to do GUI, conf files, menu files), 
that's how excess integration is avoided.

Ringdove also offers an _optional_ project file support. If you choose to 
use it, you can store your project-level configuration, or if you want, 
even your file names in the project file. When used, both sch-rnd and 
pcb-rnd know how to load and handle it. So instead of having a separate 
local gafrc, then some other local config file for gsch2pcb, and then 
still having to have a Makefile if you don't want to remember all the file 
names all the time, you can have a single project file solve it all. But 
you don't have to: you can totally go without a project file, with 
Makefiles, shell scripts, or loading all the files manually from the GUI. 
(And you can do a netlist export from the sch-rnd GUI too.) So more 
options, each taken a bit further.


2. project management

A side effect of the toolkit approach in gEDA is that there's no deep 
cooperation between the projects. I mean what was the last major feature 
that required more than 2 weeks of work in at least two different gEDA 
projects and resulted in a fature that would have been impossible if only 
one of the projects did it? In Ringdove, this is different: we think in 
features in workflows, spanning multiple tools/projects; these features
are not blocked by subproject boundaries.

In other words, gEDA is really an umbrella, a collection of otherwise 
mostly unrelated tools that sometimes happen to work together - but are 
not designed together, not coordinated. Ringdove is an EDA suite, which 
means development is coordinated.


3. Reduced dependencies

In Ringdove, an important goal is to keep software bloat low, including 
avoiding unnecessary dependencies. A fancy programming language may be fun 
for the programmer, but is a burden to the user. Yet another dependency, 
yet another thing that breaks in a major version number change. The myth 
is that you can't write complex GUI apps without <insert your favorite 
dependency here>. The proof that you can is Ringdove, implemented in ANSI 
C89 (except for the optional gtk plugin where gtk forces us using C99 and 
glib). No C++, no guile, no python.

Ringdove build doesn't depend on autotools; ./configure && make && make 
install just works, without autogen.sh, without having to figure which 
version of autotools is required and how intltool or libtool broke this 
week. In Ringdove ./configure figures what's the best it can do, and 
prints a summary of what choices it made and why. So you don't need to 
re-itrate ./configure 5 times just to expand on --without arguments as you 
figure it wanted to depend on something more you didn't need.

All in all, reduced dependencies makes it easier to complie and reduces 
risks of the project getting broken and bitrotten over time.


4. better CLI vs. GUI balance

Ringdove doesn't have a GUI tool that couldn't be compiled without GUI. 
This sounds silly first, like why would you want to use a pcb editor or an 
sch editor without GUI?! But there are a lot of applications, ranging from 
automatic file format conversions through preview generation to automated 
design and verification.

Ringdove HIDs are similar to pcb's. Except that you don't need to make 
your choice compile-time: you can compile multiple (GUI and CLI) HIDs and 
choose runtime. You can use the same executable to do your interactive GUI 
editing and then call it from a Makefile to do some automated 
action-script processing. Or you can use the same executable to do 
rendering with gtk2+gdk on 2 layer boards and gtk2+gl on with 
translucency on 8 layer boards.

All our features work from both CLI and GUI. For example you don't need to 
run a separate, CLI-only step to export a netlist from a schematics. You 
can do it either using CLI with a command (from a shell or Makefile) or 
from the GUI (from a menu and a dialog box). In fact, netlist export is 
just an export, same as png or svg export, which also work from both CLI 
and GUI. Forward annotation and backward annotation also work from both 
CLI and GUI.

You can also edit your config file both with a text editor from the 
command line or with a GUI in a nice tree view in each tool.


5. balance between out-of-box usablity and flexibility


Ringdove apps have most of their code in plugins. The advantage is that 
plugins are all optional. If you don't like a feature, you can turn it off 
by not loading (or not compiling) the plugin that provides that feature. 
Or you can write an alternative implementation of that feature in another 
plugin (or user script) and load that instead.

This includes a lot of things that would normally be considered 
mandatory base feature, like native file formats, GUI, or drawing tools.

So Ringdove can provide a set of plugins that make it easy for new users 
to use the tools out-of-the-box while it doesn't have to sacrifice any 
flexibility because all these plugins are replacable by advanced users.

Practical examples, features that depend on plugins:

- the slotting mechanism in sch-rnd

- transistor problem solution (devmap/portmap) in sch-rnd

- whether you store your pcb-rnd footprints or sch-rnd symbols in a 
directory or in some database (e.g. sql) or "in the cloud"

- how you do pcb autorouting


Best regards,

Igor2

- Raw text -