kicad-developers team mailing list archive

["andre_knoerig" <andre@...>]

--3-7216910937-4445311487=:6 Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Dick,

thanks a lot for your many thoughts and pointers on this. And sorry for
striking a somewhat business-like tone. I'm always kinda careful when I
am posting to a forum for the first time. ;)
We're actually not a business ourselves, but a university project with
an open-source product as its goal.

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

Yes, that's a good point, and we will try to get one for the start of
the project. However, in the long run, it will be an open-source project
used and further developed by designers. If designers have a programming
background at all, it is usually in Java. Neither do they have a
background in electrical engineering, so that, if possible, we would
like to bet on a strong, yet easy to handle horse as a base. KiCad looks
very promising.
The main people behind this project are actually also just interaction
designers with a little background in computer science and electrical
engineering, so that we are relying on hiring more experienced
developers.

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

I guess that's why designers are mostly taught Java. ;)

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

Yeah, and I'm quite impressed by Eclipse. So I thought why not build the
application on some of the Eclipse libraries, like SWT for the widgets,
and GEF for the schema editor. And build on EAGLE or KiCad for all the
application-specific details in the background.

> ** One of the projects you are looking at is written in C, not C++.=20
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.

Yeah, I think gEDA is already out of the race. EAGLE is interesting
because it is quite popular amongst our target group, has a free basic
version (which is sufficient for most of what we need) and two powerful
scripting languages we could make use of. But of course there's the risk
of the company's future politics.

> ** Plan on spending a week studying each of your candidate choices,
then
> the solution will become obvious.

We don't yet have a competent programmer to make such an assessment. We
would rather like to hire one with experience in the project we choose.
Also, the decision depends on the community, the documentation, etc.
And the support of helpful people like you. :)

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

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

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

That's good to hear. Congratulations to the developers on an impressive
product!

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

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

Yes, definitely! If possible, we want to stay fully compatible to the
KiCad trunk and only be a different icing on top of this cake.
As I mentioned, if we are opting for KiCad, we are very interested in
hiring KiCad-developers on a project basis and will try to make their
work flow into a joint direction.

> ** 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
> Help!)

We are beginning to specify more exactly what we want in the end, and we
will certainly discuss it with you. As I said, the goal is pretty much
to create an extremely simplified PCB design tool for designers, so we
are looking for features along this special workflow. It starts with the
designer's breadboard prototype and ends with the BOM and PCB layout
ready for manufacturing.

> 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=20
:)

Please get carried away again!

Thanks for your help,
Andre

> > Hi everyone,
> >
> > 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
> > (http://arduino.cc).
> >
> > 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
> > (features/adaptability/..)?
> >
> > 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,
> > Andre Knoerig
> >
> > Interaction Design Lab
> > Univ. of Applied Sciences Potsdam
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
>
>
> --
> Best Regards,
>
> Dick
>
> *** If he runs, I will be supporting Tom Tancredo for President in
2008. ***
> http://tancredo.house.gov/
> http://www.teamtancredo.com/
> http://tancredo4prez.blogspot.com/
>

 --3-7216910937-4445311487=:6 Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Dick,<br><br>thanks a lot for your many thoughts and pointers on this. A=
nd sorry for striking a somewhat business-like tone. I'm always kinda caref=
ul when I am posting to a forum for the first time. ;)<br>We're actually no=
t a business ourselves, but a university project with an open-source produc=
t as its goal.<br><br>&gt; ** Your development team is more important than =
your starting code <br>&gt; base. Pay more attention to who you hire, tha=
n the software starting <br>&gt; point. Interview hundreds of folks if you=
have to. This is far more <br>&gt; important than your starting code bas=
e. You want a goose that lays <br>&gt; golden eggs, you don't need a singl=
e golden egg.<br><br>Yes, that's a good point, and we will try to get one f=
or the start of the project. However, in the long run, it will be an open-s=
ource project used and further developed by designers. If designers have a =
programming background at all, it is usually in Java. Neither do they have =
a background in electrical engineering, so that, if possible, we would like=
to bet on a strong, yet easy to handle horse as a base. KiCad looks very p=
romising.<br>The main people behind this project are actually also just int=
eraction designers with a little background in computer science and electri=
cal engineering, so that we are relying on hiring more experienced develope=
rs.<br><br>&gt; ** There was a time when Java was a faster language to deve=
lop in <br>&gt; because of the fast edit, compile, run cycle, but that is n=
o more. C++ <br>&gt; and the machines that execute the compilers are now =
to the point where <br>&gt; you can edit, compile, test, about as fast wit=
h C++ as with Java. <br>&gt; Somebody might like Java more than C++ from a=
maintainability point of <br>&gt; view. C++, if misused, can be hard to =
understand for new team <br>&gt; members. Java is more straight forward.<=
br><br>I guess that's why designers are mostly taught Java. ;)<br><br>&gt; =
** Properly written Java code would be fast enough for a user interface <br=
>&gt; type application. I've done this, just try and minimize object <br>=
&gt; instantiation, as "new"-ing objects in Java is about the slowest thing=
<br>&gt; you will run into.<br><br>Yeah, and I'm quite impressed by Eclips=
e. So I thought why not build the application on some of the Eclipse librar=
ies, like SWT for the widgets, and GEF for the schema editor. And build on =
EAGLE or KiCad for all the application-specific details in the background.<=
br><br>&gt; ** One of the projects you are looking at is written in C, not =
C++. The <br>&gt; other you mentioned is not even open source. So doesn'=
t this bring you <br>&gt; back to Kicad? I would not start from a project=
written in C. C is <br>&gt; fine for embedded or operating system work, =
but you don't want to <br>&gt; program on your hands and knees.<br><br>Yeah=
, I think gEDA is already out of the race. EAGLE is interesting because it =
is quite popular amongst our target group, has a free basic version (which =
is sufficient for most of what we need) and two powerful scripting language=
s we could make use of. But of course there's the risk of the company's fut=
ure politics.<br><br>&gt; ** Plan on spending a week studying each of your =
candidate choices, then <br>&gt; the solution will become obvious.<br><br>W=
e don't yet have a competent programmer to make such an assessment. We woul=
d rather like to hire one with experience in the project we choose. Also, t=
he decision depends on the community, the documentation, etc.<br>And the su=
pport of helpful people like you. :)<br><br>&gt; ** Building a bridge from =
Java to the C++ object model in Kicad is not <br>&gt; advised. Most of yo=
ur work will be at the user interface level, and <br>&gt; the object tree c=
an quickly be reproduced in Java if Java was what you <br>&gt; were going t=
o use at the user interface. Trust me, I've spent that <br>&gt; last 6 ye=
ars doing exactly what I am telling you not to do. :)<br><br>I have not do=
ne such a bridging yet, and I'm afraid do not understand completely. Are yo=
u saying that it is still okay to do the GUI in Java, as long as we're not =
trying to write wrappers?&nbsp; I understand that there are several ways to=
do a bridging - which one do you think could be feasible? I found a <a hre=
f=3D"http://urakawa.sourceforge.net/BridgeReport.html";>little report</a>&nb=
sp; that shows some interesting options.<br><br>&gt; ** As far as open sour=
ce projects go, the Kicad project is less of a <br>&gt; project than it is =
a hobby started by its original author. I say this <br>&gt; in full respec=
t of the fine work done by Mr. J.P. Charras, but I would <br>&gt; feel bett=
er about this being a true "project" if there was a clear <br>&gt; mission =
statement or road map, better communication from Mr. Charras, <br>&gt; assi=
gned roles, adopted standards, a bug database, a feature enhancement <br>&g=
t; database, and a distinct statement from Mr. Charras that he really wants=
<br>&gt; this effort to be a team effort. Most of the time we cannot even=
get <br>&gt; answers to direct questions when posted on the mailing list. =
So why <br>&gt; have I given the last week of my valuable software engine=
ering time to <br>&gt; this project?<br><br>I guess, because you are an opt=
imistic person and appreciate quality? Thanks for giving us a little insigh=
t into the history of the project, it is helpful for communicating. In an o=
pen-source project like this one, aren't those more or less democratic deci=
sions, as long as someone takes the lead?<br><br>&gt; ** The design of Kica=
d is actually quite good, and I think it has <br>&gt; potential to truly be=
excellent. I played with the gEda package for <br>&gt; about 1/2 year. =
If I remember it is written in C, and I think so out <br>&gt; of religious =
grounds. Being religiously opposed to C++ is silly at <br>&gt; this poin=
t. Being religiously opposed to the use of the more exotic <br>&gt; parts=
of C++ might make sense. Kicad is not over using C++. <br>&gt; wxWid=
gets is a decent cross platform gui. It is good enough.<br><br>That's goo=
d to hear. Congratulations to the developers on an impressive product!<br><=
br>&gt; ** Recently there has been some work to marry python on top of Kica=
d. <br>&gt; There is also a binding from wxWidgets, on which Kicad is bas=
ed, to <br>&gt; python, called wxPython. Getting all this to run on Windo=
ws takes some <br>&gt; doing: Kicad+python+wxWidgets, but I think the sky=
is the limits at <br>&gt; that point. If you do not need user macros and =
have a C++ developer <br>&gt; available to you, then the python might just =
get in the way for the <br>&gt; user. Imagine the customer installation pr=
ocess.<br><br>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 o=
wn GUI in wxPython (as Python is almost as easy for beginners as Java). Alt=
ernatively, a possibility to write scripts in python to call KiCad-function=
s externally would be interesting, too.<br>Since we are developing for a no=
t 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 s=
tandard installation package.<br><br>&gt; ** We would encourage you to revi=
ew the GPL license under which the <br>&gt; Kicad project is licensed. As=
you seem to understand, any distribution <br>&gt; on your part of a deriva=
tive work would call for you to make that source <br>&gt; code available. =
And if you would be so kind as to actually contribute <br>&gt; it back int=
o the core Kicad project, well then we could avoid a fork and <br>&gt; we c=
ould benefit from each others' work indefinitely. (Provided we can <br>&gt=
; agree on a direction, and have sufficient dialog to agree or not to agree=
.)<br><br>Yes, definitely! If possible, we want to stay fully compatible to=
the KiCad trunk and only be a different icing on top of this cake.<br>As I=
mentioned, if we are opting for KiCad, we are very interested in hiring Ki=
Cad-developers on a project basis and will try to make their work flow into=
a joint direction.<br><br>&gt; ** Now that we have helped you, could you p=
lease help us by stating in <br>&gt; detail what it is about the Kicad proj=
ect that does not meet your needs <br>&gt; in full now? We can discuss the=
se deficiencies, and queue up these <br>&gt; remarks for our future "featur=
e enhancement database" :) (Igor <br>&gt; Help!) <br><br>We are begi=
nning to specify more exactly what we want in the end, and we will certainl=
y discuss it with you. As I said, the goal is pretty much to create an extr=
emely simplified PCB design tool for designers, so we are looking for featu=
res along this special workflow. It starts with the designer's breadboard p=
rototype and ends with the BOM and PCB layout ready for manufacturing.<br><=
br>&gt; See, by asking for customer feedback, we are making a weak attempt =
to <br>&gt; act like a business. But I'll stop now, before I get carried =
away :)<br><br>Please get carried away again!<br><br>Thanks for your help,=
<br>Andre<br><br><br>&gt; &gt; Hi everyone,<br>&gt; &gt;<br>&gt; &gt; we ar=
e currently looking into several EDA suites as a potential base<br>&gt; &gt=
; for a new software we are developing. It will essentially be an<br>&gt; &=
gt; extremely simplified EDA tool targeted at the needs of designers and<br=
>&gt; &gt; artists, who want to bring their breadboard-based prototypes to =
a PCB.<br>&gt; &gt; We are affiliated with the Arduino prototyping platform=
<br>&gt; &gt; (http://arduino.cc).<br>&gt; &gt;<br>&gt; &gt; We would like =
to program our own GUI, but build on existing software<br>&gt; &gt; for the=
backend (like routing, checking, exporting). The most<br>&gt; &gt; interes=
itng tools we found so far are KiCad, gEDA and EAGLE, and would<br>&gt; &gt=
; appreciate if you could help us make a decision. The most important<br>&g=
t; &gt; questions at the moment are these:<br>&gt; &gt;<br>&gt; &gt; - Do y=
ou think that KiCad is suited for such an approach? Are its<br>&gt; &gt; fu=
nctional parts cleanly separated from the GUI?<br>&gt; &gt; - Would it be p=
ossible to write a Java GUI (we are favouring Eclipse<br>&gt; &gt; GEF at t=
he moment) and write Java wrappers for the KiCad libraries? Or<br>&gt; &gt;=
should we use Qt Jambi to integrate closer with KiCad?<br>&gt; &gt; - Why =
should we choose KiCad over gEDA or EAGLE<br>&gt; &gt; (features/adaptabili=
ty/..)?<br>&gt; &gt;<br>&gt; &gt; If we choose KiCad, we would of course co=
ntribute back to this very<br>&gt; &gt; nice project and be interested in h=
iring an experienced KiCad<br>&gt; &gt; developer. Last but not least, if o=
ur software takes off as Arduino<br>&gt; &gt; did, this would bring a ton o=
f new users for KiCad. :)<br>&gt; &gt;<br>&gt; &gt; Thanks a lot for your i=
nsights and support,<br>&gt; &gt; Andre Knoerig<br>&gt; &gt;<br>&gt; &gt; I=
nteraction Design Lab<br>&gt; &gt; Univ. of Applied Sciences Potsdam<br>&gt=
; &gt;<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt; <br>&gt; &gt; Yahoo! Groups =
Links<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt; <b=
r>&gt; <br>&gt; <br>&gt; -- <br>&gt; Best Regards,<br>&gt; <br>&gt; Dick<br=
>&gt; <br>&gt; *** If he runs, I will be supporting Tom Tancredo for Presid=
ent in 2008. ***<br>&gt; http://tancredo.house.gov/<br>&gt; http://www.team=
tancredo.com/<br>&gt; http://tancredo4prez.blogspot.com/<br>&gt;<br>

 --3-7216910937-4445311487=:6--