Mail Archives: geda-user/2016/07/16/22:58:57
On Sat, 16 Jul 2016, Roland Lutz wrote:
> On Sat, 16 Jul 2016, gedau AT igor2 DOT repo DOT hu wrote:
>> [Pcb-rnd is] close to being "finished". Which means I should probably stop
>> investing as much time in it as I did in the past months and move my focus
>> on something that is more broken (gschem).
>
>> cschem (a replacement for gschem and gnetlist - I'd say contribution is
>> welcome right from the design phase, but I know how it works).
>
> Since I'm up to my guts in libgeda right now, I'm very interested in your
> thoughts. What are the problems you see with gschem? How do you intend to
> solve these problems?
High level:
There are some design decisions which are unusual but great. I want to
keep them. They are the reason I am still using geda and gschem despite of
all the below.
There are other design decisions from early on which I think didn't work
out well or are just plain wrong. There are social/political reasons that
makes it totally impossible to even discuss these constructively, so we
are unable to change them or at least provide alternatives for them within
the existing frame. Geda has locked itslef in, and I believe this
determines its (sad) future.
The loud minority of the community and the very few active developers are
not going in a direction that'd solve any of these problems, thus there's
no chance the project can change direction. (No offense ment, I totally
see those guys believe that direction is the right direction the same way
I believe mine is the right one -> this why we need two separate
projects.)
Low level:
Finally, the code itelf, which is tightly coupled with guile and gtk. When
I wrote the back annotation patch about a year ago I figured I didn't like
most of the code for various reasons. No offense meant, so I rather omit
technical details. Unlike with pcb, I don't see it is worth forking it,
it's cheaper to just rewrite it the way I think is proper, YMMV. (I won't
name any specific issue, because it's really like everywhere I touched the
code there were more issues than solutions; all in the design, in the
API and in the actual implemenetation.)
Finally, how to solve them, my plans (public since 1st january):
http://repo.hu/projects/pcb-rnd/devlog/20160101_cschem.html
(FAQ: Nope, I can't use libgeda or any part of it, and no, I won't be
API-compatible with libgeda. Cschem and the netlister will be able to load
and save geda formats for compatibility, but the native format will be
different, more human-readable, not less script-readable. There won't be
more integration with pcb-rnd or anything else, but there will absolutely
be more cooperation among the tools, options beyond "just generate a
diff to pcb/sim/build netlists and apply the changes by hand".)
I do not want to discuss technical details of the plan now, because a
mailing list thread won't ever yield any useful result but waste
everyone's time. If there are a few users who are willing to help
implementing and testing the design (ideas, no code) on hypotetical test
cases, I am more than happy to channel their efforts in. As I don't use
hierarchical netlists and I have only two or three workflows, such
contribution would help keeping the new design 100% generic. But the
design process can only happen in a coordinated way, using svn to work out
ideas and examples. (I have no high hopes on this, tho, poeple tend to
stick to gschem the are used to, so I expect 0 contributors.)
Regards,
Igor2
- Raw text -