Mail Archives: geda-user/2025/06/11/01:29:44
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
- Raw text -