kicad-developers team mailing list archive
Mailing list archive
Re: KiCad as base for
Unlike a business, an open source project does not have a team of
salesmen. Therefore, no one is likely to step up and say, "please use
us!" Folks visiting this website and mailing list are not part of a
I can however, since I have contributed heavily in the last week to this
project, and have written a ton of software in my life, comment on your
** Your development team is more important than your starting code
base. Pay more attention to who you hire, than the software starting
point. Interview hundreds of folks if you have to. This is far more
important than your starting code base. You want a goose that lays
golden eggs, you don't need a single golden egg.
** There was a time when Java was a faster language to develop in
because of the fast edit, compile, run cycle, but that is no more. C++
and the machines that execute the compilers are now to the point where
you can edit, compile, test, about as fast with C++ as with Java.
Somebody might like Java more than C++ from a maintainability point of
view. C++, if misused, can be hard to understand for new team
members. Java is more straight forward.
** Properly written Java code would be fast enough for a user interface
type application. I've done this, just try and minimize object
instantiation, as "new"-ing objects in Java is about the slowest thing
you will run into.
** One of the projects you are looking at is written in C, not C++. The
other you mentioned is not even open source. So doesn't this bring you
back to Kicad? I would not start from a project written in C. C is
fine for embedded or operating system work, but you don't want to
program on your hands and knees.
** Plan on spending a week studying each of your candidate choices, then
the solution will become obvious.
** Building a bridge from Java to the C++ object model in Kicad is not
advised. Most of your work will be at the user interface level, and
the object tree can quickly be reproduced in Java if Java was what you
were going to use at the user interface. Trust me, I've spent that
last 6 years doing exactly what I am telling you not to do. :)
** As far as open source projects go, the Kicad project is less of a
project than it is a hobby started by its original author. I say this
in full respect of the fine work done by Mr. J.P. Charras, but I would
feel better about this being a true "project" if there was a clear
mission statement or road map, better communication from Mr. Charras,
assigned roles, adopted standards, a bug database, a feature enhancement
database, and a distinct statement from Mr. Charras that he really wants
this effort to be a team effort. Most of the time we cannot even get
answers to direct questions when posted on the mailing list. So why
have I given the last week of my valuable software engineering time to
** The design of Kicad is actually quite good, and I think it has
potential to truly be excellent. I played with the gEda package for
about 1/2 year. If I remember it is written in C, and I think so out
of religious grounds. Being religiously opposed to C++ is silly at
this point. Being religiously opposed to the use of the more exotic
parts of C++ might make sense. Kicad is not over using C++.
wxWidgets is a decent cross platform gui. It is good enough.
** Recently there has been some work to marry python on top of Kicad.
There is also a binding from wxWidgets, on which Kicad is based, to
python, called wxPython. Getting all this to run on Windows takes some
doing: Kicad+python+wxWidgets, but I think the sky is the limits at
that point. If you do not need user macros and have a C++ developer
available to you, then the python might just get in the way for the
user. Imagine the customer installation process.
** We would encourage you to review the GPL license under which the
Kicad project is licensed. As you seem to understand, any distribution
on your part of a derivative work would call for you to make that source
code available. And if you would be so kind as to actually contribute
it back into the core Kicad project, well then we could avoid a fork and
we could benefit from each others' work indefinitely. (Provided we can
agree on a direction, and have sufficient dialog to agree or not to agree.)
** Now that we have helped you, could you please help us by stating in
detail what it is about the Kicad project that does not meet your needs
in full now? We can discuss these deficiencies, and queue up these
remarks for our future "feature enhancement database" :) (Igor
See, by asking for customer feedback, we are making a weak attempt to
act like a business. But I'll stop now, before I get carried away :)
we are currently looking into several EDA suites as a potential base
for a new software we are developing. It will essentially be an
extremely simplified EDA tool targeted at the needs of designers and
artists, who want to bring their breadboard-based prototypes to a PCB.
We are affiliated with the Arduino prototyping platform
We would like to program our own GUI, but build on existing software
for the backend (like routing, checking, exporting). The most
interesitng tools we found so far are KiCad, gEDA and EAGLE, and would
appreciate if you could help us make a decision. The most important
questions at the moment are these:
- Do you think that KiCad is suited for such an approach? Are its
functional parts cleanly separated from the GUI?
- Would it be possible to write a Java GUI (we are favouring Eclipse
GEF at the moment) and write Java wrappers for the KiCad libraries? Or
should we use Qt Jambi to integrate closer with KiCad?
- Why should we choose KiCad over gEDA or EAGLE
If we choose KiCad, we would of course contribute back to this very
nice project and be interested in hiring an experienced KiCad
developer. Last but not least, if our software takes off as Arduino
did, this would bring a ton of new users for KiCad. :)
Thanks a lot for your insights and support,
Interaction Design Lab
Univ. of Applied Sciences Potsdam
Yahoo! Groups Links
*** If he runs, I will be supporting Tom Tancredo for President in 2008. ***