kicad-developers team mailing list archive
Mailing list archive
Re: Re: KiCad as base for
> ** 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. :)
I have not done such a bridging yet, and I'm afraid do not understand
completely. Are you saying that it is still okay to do the GUI in
Java, as long as we're not trying to write wrappers? I understand
that there are several ways to do a bridging - which one do you think
could be feasible? I found a little report
<http://urakawa.sourceforge.net/BridgeReport.html> that shows some
Java is fast enough at runtime that you could do the whole project in
Java, duplicating the object model that you might find in the C++ object
storage classes within Kicad. The work you would spend in building a
JNI bridge to those C++ classes from Java would surpass the work to
simply translate the whole project to Java. But then you are an
island, no help from us. Versteh?
> ** 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
> database, and a distinct statement from Mr. Charras that he really
> 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
> this project?
I guess, because you are an optimistic person and appreciate quality?
Thanks for giving us a little insight into the history of the project,
it is helpful for communicating. In an open-source project like this
one, aren't those more or less democratic decisions, as long as
someone takes the lead?
> ** 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.
I tried to follow your new discussion around a python binding. As far
as we are concerned, it would be awesome to be able to write our own
GUI in wxPython (as Python is almost as easy for beginners as Java).
Alternatively, a possibility to write scripts in python to call
KiCad-functions externally would be interesting, too.
Since we are developing for a not so technical community, we would of
course like to keep the installation as simple as possible, but I
guess it's always possible to create a tight standard installation
If the python thing comes off, then I would go that way. wxPython is
an immensely powerful tool, and would probably use less lines of code
per UI effect on screen than either Java or C++. And the object storage
model would be in C++.
Florian is looking at the Python bindings for us. It may be a few weeks
before we know anything. It would be easy for us to put the storage
model code into a DLL or shared object file and park the rest of our
stuff on top of that, a blend of C++ UI and Python UI stuff.