DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 55B5QjKR3335239
DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 55B5Qixp3335218
Date: Wed, 11 Jun 2025 07:26:40 +0200 (CEST)
To: "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
From: "grnd AT igor2 DOT repo DOT hu [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Subject: Re: [geda-user] pcb git down, new git repo available
In-Reply-To: <CAC4O8c8iuBsaGUfHHcMW36M1016s5O1Xb2P9NhHT9TFQ3Gcj4A@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.2506110430560.2219@igor2priv>
References: <20250531150718 DOT 51F5881A5EB8 AT turkos DOT aspodata DOT se> <617e175a-a1bc-4a70-99da-78d822c6e7fc AT ecosensory DOT com> <CAHUm0tMjEj=Nirsg4m5-TcYCzQRxDJdWQHZH5xxhP+uO9resng AT mail DOT gmail DOT com> <CAC4O8c8iuBsaGUfHHcMW36M1016s5O1Xb2P9NhHT9TFQ3Gcj4A AT mail DOT gmail DOT com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
Precedence: bulk


On Tue, 10 Jun 2025, Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:

>On Sun, Jun 8, 2025 at 6:34?PM Erich Heinzle (a1039181 AT gmail DOT com) [via
>geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>>
>> Multiple font support, multiple file/footprint format support for import and export, slot in pad support, slot layers (plated and unplayed), extensible layer stack up support, script defined CAM file exporting, pad stacks, polygons in footprints, text in footprints, project files, back annotation, openscad export support (subject to models), auto routing plugins, bitmap overlays as well as working --bg-image support... are just some of the many solved problems in pcb-rnd along with gtk4 support (and a presence in current distributions along with the associated schematic editor sch-rnd and Gerber/CAM file viewer camv-rnd with slotted pad viewing support) all while maintaining support for gEDA PCB file formats and supporting multiple netlist import formats.
>>
>> It is worth trying pcb-rnd if you are used to using gEDA PCB and have existing designs. The only thing you'll find that feels different are the key bindings, as there are a lot more features to be mapped to the keyboard, but as a bonus, the bindings are consistent across sch-rnd, pcb-rnd and camv-rnd.
>
>Since we're promoting pcb-rnd so heavily here I'd like to reiterate
>what I prefer about old pcb:
>
>1.  It doesn't introduce as many features with little testing, both

The part that's true: pcb-rnd does introduce new features (you know, that 
happens when a project is being actively developed, users come up with new 
feature requests all the time).

False claim: "little testing".

pcb-rnd not having enough testing or being more buggy than pcb is simply 
not true.

On an abstract theoretical level, a new release of a software project 
typically has new features and bugfixes in already existing features. You 
may reason that if the balance is consistently for adding a lot more new 
features than fixing bugs, the software becomes buggy on the long run. I 
would agree with such a reasoning.

For data, let's look at pcb-rnd changelog statistics for the past few 
releases. Which is easily possible because of my changelog entries are 
prefixed with:

- "Add" for slightest smallest new features, even if it's just a tiny new 
thing on an existing feature; very often a single complex feature is 
present as a couple of "Add" entries for the subfeatures; "Add" lines also 
cover extra documentation and code comments

- "Fix" for bugfixes

- other tags (e.g. "Del" for feature/code removal)

Crude grep|wc stats from the changelog of the past 3 releases:

3.1.7: 96 Add, 98 Fix

3.1.6: 66 Add, 67 Fix

3.1.5: 21 Add, 23 Fix

What I see here is a healthy balance of an active project, even if these 
numbers still contain the "Add" entries that did not add new features (but 
documentation).


>times I've tried pcb-rnd I hit things that aren't exactly bugs except
>perhaps in the sense of not-well-described-error, but mislead user.

And when those times were? Some 8+ years ago?

I absolutely refuse the claim of pcb-rnd misleading users. 

>I've also seen similar problems discussed on the pcb-rnd mailing list
>for other users and encountered dev resistance when similar
>problems-in-the-making are brought up.

FUD.

If you _objectively_ go through the (large volumes) of pcb-rnd mailing 
list archives, you will see that vast majority of the bugreports are 
accepted, bugs are fixed and reporting users are satisfied.

As with any project used by more than 1 user, there are disagreements: 
sometimes a user wants a feature or regards something as a bug that the 
project doesn't and the bugreport or feature request is refused. But this 
is a very small fraction of all the cases. 

Fact: we regularly have surveys, proactively try to bring in feature 
requests and we track them and implement them - pretty much the 
exact opposite of "dev resistance".

Sometimes people who are _not_ developing the given software think they 
know better how those who _are_ developing the software should be doing 
it. Somtimes they share their ideas. Somtimes developers don't accept 
these ideas and keep on doing things as they see fit.

That does not necessarily mean there is _any_ "problems-in-the-making"; 
that only means your idea on how the project should be done differs from 
the devs'. Give it some years and look at the actual results. If the 
project achieves its goals, users are satisfied, that's a good proof that 
those were no problems. The good thing is that in this specific case those 
years are already spent and we can look at the outcome.

If you look at data (activity, number of problems solved, number of new 
users appearing)... Especially if you compare pcb-rnd to pcb, and Ringdove 
to gEDA the past many years, I think it's rather clear that the net 
outcome of my decisions were not "problems-in-the-making" but the key to 
that (unlike gEDA) Ringdove EDA is not declining but (slowly) growing.
 

>2.  It's more responsive, less lag when drawing.  pcb-rnd is not

Again, false claim with no backing data.

Your statement may have been true back before 2017, if:

- you had a system that was rendering faster with opengl than with gdk

- you had opengl enabled in pcb

Around 2017 pcb-rnd got _the same opengl rendering code_ that pcb used 
(and now it even has a second, more modern opengl code that was required 
by gtk4).

In reality, by now pcb-rnd probably renders faster than pcb, because:

- I did further optimization in some of the code directly affecting 
rendering speed; optimization that pcb did not do

- example: we have a new polygon lib that has a new dicer algo that's 
faster than the one used by pcb (and if you have polygons with clearances, 
dicing can cause a lot of CPU spending, depending on the number of 
clearance cutout on screen with the current zoom level)

- example: pcb-rnd has a rather aggressive level-of-details optimization 
that affects polygons and text, as far as I can tell pcb does not 
implement anything similar; this matters _a lot_ when you zoom out on a 
large, dense board

- in the mean time I saw pcb getting at least one commit that definitely 
takes more processing time during each redraw (grid in gtk)

We constantly have ex-pcb users switching to pcb-rnd; they report bugs or 
request support. There are a lot of things that differ between pcb and 
pcb-rnd by now, and there are recurring topics for these switchers.

However I can't remember any such switchers complaining about pcb-rnd 
being slow.


>nearly as bad as e.g. solidworks but just a bit more like other big
>CAD where everything is sluggish.
>
>Maybe these are fixed now but it was enough on my last try that I
>stayed with pcb.

Yeah _maybe_, when you have 8+ years old information and bold claims 
without data. 

>However I noticed that the latest pcb-rnd has rubber-band routing and
>if that's really working I'd try it again for an entirely new design.

Cool, you are welcome to test or use pcb-rnd, but you need to understand 
that I have zero interest in converting you from pcb to pcb-rnd, from 
gschem to sch-rnd, from gerbv to camv-rnd, etc. 

To make my motivations clear:

Most importantly: Nobody says you should switch to pcb-rnd! Please do stay 
on pcb.

I don't mind if anyone here disagrees with me. I also don't mind personal 
opinions: you hate pcb-rnd, that's fine! You hate specific decisions I 
make/made in pcb-rnd or Ringdove? That's fine too! You have outdated 
information about pcb-rnd because you didn't try it in a couple of years? 
Totally fine! What I don't like is false claims (like pcb-rnd being 
"untested" or "developer resistance") presented as if they were facts.

The reason I do mind is not you or the few who are reading this thread 
today, but the following.

Background: from gEDA's perspective I regard the Ringdove EDA suite (which 
grew up around pcb-rnd) the modern replacement of gEDA; what you know as 
gEDA is really gEDA 1.0, and Ringdove EDA is gEDA 2.0. It took all the 
good ideas (toolkit approach, modularity, flexibility, scriptability, 
cli+gui, UNIX philosophy, etc.) and reimplemented the suite without 
dragging on the bad things along (differences in UI controls and logic 
among suite members, mandatory dependencies like 
guile/python/perl/texinfo, inability of subproject to cooperate), etc..

I honestly do not care if anyone here switches to Ringdove EDA or KiCAD or 
keep on using gEDA. That's not what I am here for. The few users who 
remained here and post in a sparsely spaced threads typically happening 
once or twice a year are so much attached to gEDA that they will stay on 
gEDA even when that will mean running the whole thing in VM with a 10+ 
years old OS. And that's totally fine with me.

However, this mailing list has a public archive picked up by web searches 
engines. Which starts to matter if you think outside of these ~2 dozen 
people being semi-active here.

There are still a few hunderd users (my very rough extrapolation based on 
Debian "vote" stats in popcon on pcb-* packages), who are _not_ subscribed 
to this mailing list and are not communicating with the developers or the 
community (not even when they bump into some problem). These are mostly 
casual users who installed gEDA from distro packages and won't go and 
compile from source, especially not if that also means compiling obscure 
and large dependencies from source recursively first.

As gschem already got and pcb started to be removed from distros (see 
repology.org), at some not very far future day these users will suddenly 
find themselves with all their designs done in gEDA and no installable 
gEDA to handle them. For them, the most natural upgrade path is Ringdove 
EDA, because of the very similar basic concepts and that pcb-rnd and 
sch-rnd can load their gEDA files, and somewhat similar UI, at least on 
pcb-rnd side.

These users will probably do a web search on where to go from gEDA. They 
will probably find your false claims about pcb-rnd. That's the only reason 
I replied to your mail, so that those users also find the rebuttal of your 
claims popping up in the same search results.

Best regards,

Igor2