Mail Archives: geda-user/2017/02/12/08:56:38
Hi guys,
this is especially for Vladimir and Roland. I think by now it's totally
clear that there will be two separate paths of
geda/gaf/gschem/xorn/whatever development. Let's try to save some mental
bandwidth and not rehash this and also skip the "who stepped on whose toes
while we figured this out" topic.
Spoiler: I mean absolutely no offense. But really, we either start doing
things instead of ... what we were again doing today, or the the project
sinks in a few years. Especially: we start coding or keep talking and it
sinks. If you find any sentence you can take as an offense please reread
it with an <ironic> </ironic> wrapping and if that didn't help, just stop
reading and ignore the entire mail (or even thread)! I am not trying to
fight gschem, I am not trying to fight any of you. I'm trying to get
something done, in the most pragmatic manner possible.
So let's try to be a bit more pragmatic here. Let's assume users weight
refactorings and cleanups and elegance-of-code a bit lower than actual
features they need in daily use.
I'll be pushing back annotation now. If you are not interested, feel free
to stop reading here. I am pushing this topic because it looks like a low
hanging fruit with considerable user demand behind it and an almost full
solution already available. It also seems like most of our "competitors"
already have it.
I am not pushing it because I'd need it for pcb-rnd. I already have a gaf
"fork: with fully working back annot for myself and for those who want to
use the feature, so honestly, as an user or developer I don't really care
if it makes it into any of the other "forks".
I am talking from the ecosystem's point of view.
In fact, I'm in contact with the developers of some other schematics
capture programs and they are very much interested in implementing back
annotation on their side - we can easily end up having gschem among the
_last_ few programs to support this among the sch cap software pcb-rnd can
interface to.
We have this problem, this missing features many users want (yes I know,
it can be done manually and there's at least one uninterested user too,
etc, etc, we can really save an extra mail on that, thanks in advance). I
could easily dig up geda-user mailing from 2007 that was dealing with this
topic already. There are different partial an full solutions floating on
the web, but afaik nothing that is easily accessible for the user in
standard distributions. So we, as would-be part of an ecosystem, in fact,
have a problem that is about a decade old and we couldn't solve it.
What if... What if we stop talking and sit down coding and solve it? You
guys seemed to agree in the idea of random bridges between tools. To me,
from the bridging aspect, the official gschem, xorn, Vladimir's fork are
all equal, even equal to LTSpice and FidoCadj. For me the only question is
where we can build a bridge and how. And I am not afraid to build my part.
We already have at least 2 well working bridges in the gschem -> pcb-rnd
direction. And I already have a bridge I demostrated to work in the
pcb-rnd -> gschem direction.
So if you are still with me and want to be pragmatic on this, you could
just jump on it and solve this issue in a weekend. Let's prove to our
(potential) users that we are capable of delivering real solutions to real
problems. Let's prove that geda is not yet dead. Let's prove we are not
just a bunch of grumpy old guys talking and talking without coding. Or if
the "p. size comparison contest" is really that important for us, let's
take this as a contest and let the race begin and let's see whose
implementation works first. Let's use this smallish but popular feature to
start with.
If we want to be absolutely pragmatic on this, I think we (you) have the
following choices:
1. Take what's already is there. There's a documented file format and a
full implementation in pcb-rnd. There's a video how it works on user
level. There's a gaf "fork" that you can experiment with. It's version
controlled. You can take a series of patches and put it in your favorite
VCS hosted anywhere. Take it, merge it in your favorite "fork" and let it
be useful for people.
2. Take the file format, take the documentation, take the video, and
implement the same thing differently. In scheme, python, ruby, java,
fortran, commodore 64 machine code, with 3 and a half spaces for
indentation, with 2 seimcolons after each assignment, whatever you
prefer.
3. Take the file format, the documentation and implement a totally
different UI on gschem side.
4. Hate the file format, hate the concept. Come up with something better
or just different. Find me if you want to talk about it. Or just implement
it, document it and mail me when you are ready. If it's not totally
unreasonable and unsupportable from pcb-rnd side, I'll write the exporter
in a few hours or few days, like I did for a few formats already.
5. Choose the easy way. Lean back, ignore the back annotation, go on
refactoring and watch other sch editors getting the back annotation
feature sooner. Watch how pcb-rnd users will start recommending that other
editor in place of gschem. Trust me, this one won't cost any time for any
of us. I won't blame you for this choice, maybe there a more important
features you will be working on.
I'll be online on IRC in my usual hours. That's pretty much all day. I can
help. If you don't want to run pcb-rnd even with rubber gloves on, I can
produce test files for you. Don't find excuses, if you don't want to do
it, just say no, and that's it.
Regards,
Igor2
- Raw text -