kicad-developers team mailing list archive

[Dick Hollenbeck <dick@...>]

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