← Back to team overview

kicad-developers team 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 interesting options.

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 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
> 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?
Very perceptive.

> ** 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 package.

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.