kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 02/17/2012 01:17 AM, Miguel Angel Ajo Pelayo wrote:
>
>    Even if I cannot allocate any time to help, I think I should dump to you my ideas
> before I forget them 
> (some can be crazy and expensive to develop, I know):
>
>    1) Single layer view while routing: (some hot key) that would enable a special view mode 
> where the current routing layer is show in its own color, but all other layers go gray.
>  I've used
> this in other tools and it's very helpful, and I suppose it's not hard to implement (if
> not already done).
>
>    2) Footprint wizards/plugins (following IPC models, etc..), you give A,B,C,D,E
> spacings/parameters, get a preview
>    of the footprint on the windows, then setup the density level, and finally add the
> part to the library.
>
>    3) Higher level scripting languages: some integration with Python/V8 engine
> (javascript)/etc.. giving a layer
> of objects to access al the PCB/SCH elements from the high level scripts, and also
> allowing for user interfaces
> to be launched.

Two weeks ago I looked into adding support for V8.  V8 is google's javascript engine and
they use it under the chrome browser.  (You may already have a copy on your disk now.)  V8
is very fast.  There is another project that sits on top of V8 called node.js.  node.js is
great at writing asynchronous webservers, and has been shown to actually be faster than
apache in some circumstances.

My measurement of doing it manually said that it is a lot of work.  However since then I
see some folks are trying to add the binding generation functionality to SWIG.  SWIG can
generate bindings for a number of languages, in theory.


http://comments.gmane.org/gmane.comp.programming.swig.devel/20373
https://github.com/oliver----/swig-js

This is an ancillary project, and not integrated into core SWIG from what I can tell.

node.js has gathered so much momentum that it is actually changing the choice of languages
used on the server side for many web applications.  There are two reasons for this that I
can see:  a) node.js on top of V8 is fast.  b) being able to use javascript both on the
client side and server side is attractive to many developers.



>     
>     4) Push routing mode: allowing to push other tracks around while you route a new track.

This is arguably the most important need of KiCad.


>
>     5) Differential net tagging on schematic, differential net routing on pcb.
>
>     6) This is just another parallel project, but could be awesome:  Something like the
> google content central
> for sketchup, just an open site (that could be cloned anywhere) ready to act as a
> repository of schematic symbols +footprints,
> people could rate them and add comments,etc..  and later kicad could connect to these
> repositories, and browse/use any parts.

The SWEET with distributed library manager concept that I have been working on in the /new
directory within the source tree approaches this concept for EESCHEMA.  My thoughts have
been that what is learned here can later be applied in the more elaborate requirements of
PCBNEW.


>
>     7) Fast preview of libraries: to show a preview of what we're chosing in the
> footprint asignment window.
>
>     And I'm already forgetting things, 
>
>    Greetings to everyone,
> Mike,

To summarize, we are not short on ideas.  I think sometimes new users come into use of a
project and just assume that the reason a feature is not there is because nobody has
thought of it.  However, more often than not, it is a lack of "qualified developer
man-hours", which typically are not free.  And when they do become available, need to be
thought of as financial contributions in and of themselves, even no money has changed hands.

It is my view that once the following 3 items are in place, then the corporate users will
storm in en-mass, and then there may be a way to fund the time of qualified developers:

*) Push routing  (no. 4 above)

*) Painless importation of Eagle files and other popular formats.

*) no. 6 above, along with my distributed library concepts in /new

Until then, there will be limits to what gets done in KiCad, and pouring more and more
mere "ideas" into it will not actually serve to get anything done.
The main developers cannot simply work on KiCad without getting paid beyond a certain
amount of hours per week.  Think of it as giving blood, doing a little is fine and may
make you feel good, *giving* too much will kill you (financially and emotionally).

Thanks,

Dick