Mail Archives: geda-user/2015/12/28/22:27:14
On Mon, 28 Dec 2015, John Doty wrote:
>
>On Dec 28, 2015, at 11:53 AM, Marvin Dickens (mpdickens AT gmail DOT com) [via
>geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>
> Currently, badly needed development rarely occurs because those
>people who are capable do not contribute because they are put off
>by a few users who want NOTHING to change because it does not
>fit their personal work flow.
>
>
>There are really two projects here: The original gEDA (now confusingly
>called geda-gaf), and pcb. I think everyone agrees that pcb needs a lot of
>work. On the other hand, geda-gaf is matiure, effective, and easy to extend
I know this will not be productive or encouraging, but...
For a long time I was hacking PCB's source and did not check geda-gaf
sources. You led me believe geda-gaf sources are much better organized,
and the code much better designed than PCBs.
When I worked on back annotation, I finally had to add some code in gschem
and libgeda.
It was a big dissapointment. PCB code has its own shortcomings too, but
gschem is far from being perfect either. If you ask me, _both_ need a lot
of work.
>with scripting. Pcb development requires a great deal of collaboration.
>Geda-gaf development mostly does not, as anybody can write and publish a
>script.
False. I am coding/maintaining pcb-rnd alone and it does work - in the
sense that I do get the features and bugfixes I wanted to have. When I did
the back annotation's gschem part, things went much slower. If i had to
pick, I'd say pcb is easier to hack alone than gschem.
As you don't code PCB and you don't even use it, I don't think you are in
a good position in comparing them like that. You can, of course, just
noone should take your words seriously.
>There would be much less controversy if these projects were separated. They
>represent radically different development patterns: conflating them causes
>much confusion and strife.
As an user of _both_ gschem and pcb, as a programmer who has alreay hacked
both code, I beg to differ. The projects are separate enough.
Admitting that a very common (if not the most common) flow is gschem->pcb
is not a bad thing. Even if you will write at least 20 mails a month about
that your flow does not include PCB.
Having some scripts and tools for this flow is not any worse than having
tools an scripts for other flows.
Having a common mailing list or homepage or other infrastructure is not
harmful either. Anyone can use gschem without pcb and can use pcb without
gschem. It's only you who try to change PCB-related traffic into "don't
change gschem" threads. Other than this it's usually pretty clear when we
are talking about gschem or pcb.
About how perfect gschem is...
My personal opinion, especially after actually hacking the code for back
annotation, is that there are design errors in the very core of gschem.
A few smallish things that makes life harder in probably most flows,
makes essential UI features impossible to implement. They are historical
decisions and are embedded so deep that it's unlikely they'd ever change.
I don't want to go into details, because this mail already can cause 30
megabytes of flamewar.
The well-praised sch format: it's uncomfortable to use with a text editor.
It's 1000x better than a binary format (or a hex dump), and I do have my
ow set of awk/sed scripts, and it's easy to parse by programs (but that's
true for tons of other formats too). But if i have to change the footprint
of R1 from 1206 to 0805 with a text editor, it's just a PITA. I'm not an
xml fanboy and I really don't like the overhead of JSON or the magic -- ==
''' marks of wiki/yaml... But really, any of these would have been more
text-editor-friendly. This is a question of personal preference, but just
that you repeat twice a weak that the sch format is perfect and is better
than anything else doesn't change this.
- Raw text -