kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 02/22/2012 09:11 AM, Miguel Angel Ajo Pelayo wrote:
> I think I could put some efforts on testing it, and see how well the "JS" branch of swig
> does work.
>
> Do we have an idea of which interface we may want to give to the scripting layers?, 
> access to PCB objects, modules, tracks, etc?

To keep it simple, let me talk about PCBNEW only *for now* (duplicate the discussion in
your mind for EESCHEMA).

class BOARD, and the needed significant objects contained within it.  I say needed,
because I think there is some flexibility as to where you build this bridge, either in the
class BOARD by accessor augmentation in C++ go give access to everything there, or by
SWIGing out the contained classes.

We also talked about moving the non-UI member functions that are now in PCB_BASE_FRAME,
PCB_EDIT_FRAME, into a class which is purely for significant actions but with NO UI, like
plotting, annotating, etc.  The UI portion (meaning the preceding dialog invocation) would
stay out of this class.  conceptually lets call this class BOARD_ACTIONS.  All the
functions in BOARD_ACTIONS take enough parameters to operation *without any UI*, by
definition.



BOARD_ACTIONS could then be transported into two realms: 

a) back into PCB_*_FRAME by multiple inheritance, so you are back to where you started
from with respect to PCB_EDIT_FRAME.

b) into the top of a scripting entry point DLL/DSO.


Along with this, it might be useful to try and build a PCBNEW DLL/DSO that has the public
BOARD_ACTIONS, and BOARD entry points exposed.
The actual PCBNEW program (where main() is), could be a thin layer with linked with the UI
(mostly dialogs and wxFrames).

The plotting and drawing functions themselves might have to be yet a separate DLL/DSO.
Since your BOARD_ACTIONS might actually have to plot or print.

We are finally getting in a position to be able to do this, reduction of globals has been
an enabler in this effort.  There is some more work to do.  We still have a number of
globals, and getting the separation into BOARD_ACTIONS would be some work.

This design I think deals with both the paradigms:

a) scripting calls C++ actions, and
b) C++ calls scripting, since these calls from C++ would be from the upper main() area,
and you could still call BOARD_ACTIONS and BOARD from the script.

It just does not however deal with the letting the script control the UI.  I think that is
significantly more work, and is probably best done in C++ forever.

I don't anticipate that this would take under two days to do.

:) read carefully now.

Dick



>
>
>
> 2012/2/22 Dick Hollenbeck <dick@xxxxxxxxxxx <mailto:dick@xxxxxxxxxxx>>
>
>     On 02/17/2012 08:56 AM, Miguel Angel Ajo Pelayo wrote:
>     > Hi Dick,
>     >
>     >    Thanks for your feedback on the ideas, it's really appreciated, I fully understand
>     > all of your points, as I'm on the same situation with some open projects and my little
>     > company. I supposed that most of the ideas were already in your mind, but if I didn't
>     > share them I wouldn't know now where do they converge with yours :-)
>     >
>     >     I really love the V8 engine, just played a little bit on embedded systems, and it
>     > works incredibly fast (it does JIT of the code and you get all the flexibility of
>     > javascript), and nodeJS gives all the functionality needed to access the underlaying OS
>     > and network, although I'm not sure if it's internal design makes it suitable to get
>     > integrated in other apps.
>     >
>     >      I'm also using SWIG to build interfaces to many languages, and it works incredibly
>     > well. I must test the swig-js and see how mature is.
>
>     We will be interested in finding out what you learn.  JavaScript seems to have a lot of
>     momentum now, and it needs to be looked at in detail.
>
>     With HTML5 giving it new life on the client, NodeJS giving it further life on the
>     server,
>     its C++ like syntax, its standardization by a standards body, it has a lot going for it.
>
>     And for any one not already knowing a language, one is comforted by the fact that
>     learning
>     it might serve a real purpose in other areas, (like when you go design your next
>     webpage.)
>
>     Dick
>
>
>     >
>     >     Personally, I'd like to give "some blood" on the project as soon as I can and get
>     > familiar with kicad's code/design :-)
>     >
>     >     Cheers,
>     > Mike
>
>
>     > 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.
>     >
>
>
>
>
>
> -- 
>
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 636 52 25 69
> skype: ajoajoajo