kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 03/18/2012 01:46 PM, Miguel Angel Ajo Pelayo wrote:
> Hi Dick,
>
> 2012/3/18 Dick Hollenbeck <dick@xxxxxxxxxxx <mailto:dick@xxxxxxxxxxx>>
>
>     On 03/18/2012 11:19 AM, Miguel Angel Ajo Pelayo wrote:
>     > We already have something quite useful, but testing is very welcome.
>
>     I would be inclined to offer my help on the architectural changes needed to make this
>     right, before I were to spend any of my time "testing".
>
>
> I will be glad to offer my help on those architectural changes, I could do it while I keep
> working on the scripting system. I'm finding it a very grateful work, because without 
> very big efforts (thanks to swig) I'm being able to get very good results.
>  
>
>     Finding that time is my biggest problem.  Some of my thoughts:
>
>
> I know what you mean, really ':)
>  
>
>
>     a) This is very important ground work.
>
>
> Not as important as the refactoring you're working on :-)
>  
>
>
>     b) Eventually I hope to be able to help, and it will come in bits and pieces.  You will
>     see on my personal todo list in TODO.txt, that I have adding "loading modules" to the
>     PLUGIN API near the top.  This will happen very soon.  See number 2) in that file.
>
>
> Nice!, that sounds great, really great.
>  
>
>
>     c) The architectural changes I identified before still need to happen before we can call
>     this a completely sound design.  I personally am not motivated to merely get this done,
>     but am motivated to get it done correctly on top of the proper architecture.   I do not
>     feel that much if any of the work you have done is a waste of time.  Quite the contrary.
>     However, I am not surprised in the least that you have hit a an architectural wall.
>      It is
>     precisely the wall that I warned about.
>
>
> Yes, after going down in the code I agree with you, let's clean up the house, and when
> it's done then we merge.
>
> During that time I could start writing some basic scripts to check all the object
> wrappings,, 
> etc... , the tests, and  
>
>
>     (On a personal note, the wall that I am hitting lately is insufficient time to spend on
>     KiCad.  There are several items before this scripting in my work queue, but I feel
>     scripting is probably one of the most important enhancements that will ever happen
>     to KiCad.)
>
>
> I think it can be a very interesting one, things like the recently proposed pcb to
> schematic 
> reverse engineering functionality could be very well done in scripting, so executed and
> maintained out
> of KiCad's sourcecode.
>  
>
>     We will soon be moving to all new file formats in PCBNEW, both for footprints and
>     boards,
>     driven by the move to nanometer internal units.
>
>
> One question, now the internal units (used in the objects as wxPoints are in 1/10 of
> mils or inch derived
> units, right?) I was quite surprised seeing that when I added 2000 to X it moved
> 2.54*2mm (if I'm not wrong) :-)
>
> I think that for easiness I'll define some unit converters like mm(x) or inches(x) that
> must map to our internal unit systems,
> that would also make the scripts I write now compatible with the nanometer upgrade.
>
>  
>
>     At this time we have an opportunity to make very disruptive changes to the PCBNEW file
>     format, an opportunity which does not come along often.  The beauty of having the
>     scripting inside the program, on top of the object model, is that your work will be
>     largely preserved, even as the BOARD format changes, probably radically.  (An external
>     pure python library which tried to read *.brd files would be immediately obsolete.)
>
>
> Yes, those changes are hard to make when a project is already rolling, having the
> KICAD_PLUGIN and IO_MGR the compatibility is easier to maintain, for the scripting
> must be totally transparent.
>  
>
>
>     I thank you for the progress report, and I honestly believe you are doing *very*
>     important
>     work, which will eventually get pulled into KiCad.  You have my personal guarantee.
>
>
> Thanks a lot Dick, I will keep working to make it as good as possible before merge. 
>  
>
>
>     But just like the command line argument patch that came in 2 months ago, there will be a
>     better time to merge this all in.   After BOARD_ACTIONS, after nano-meters, and after we
>     have a clean separation of UI from actions.  Otherwise it would be like re-modelling
>     while
>     someone is cleaning the house.  Yes, I have been saying this for nearly 5 years, but I
>     honestly believe we are now very very close, relatively speaking.
>
>
> Once I feel the scripting work is ready with the current version I will try to help on that.
>
> What's the idea of BOARD_ACTIONS? :)


I'm sure I've answered this before.  So here is only a half hearted response (better
probably to google for it):

It's a class which has board processing functions in it.  The UI functions remain in
wxFrame and wxDialog derivatives.  However if we take a look a execution flow control,
after the dialogs are called and all the parameters are gathered up which would allow you
to actually go perform an action on a BOARD, you then pass those "gathered parameters" to
a procedural function that has no further UI requirements.   It's just that I would like
to see that procedural function be in class BOARD_ACTIONS, and take the gathered
parameters as arguments such that the UI is then not needed from that point forward into
the procedure.

With this change, it becomes possible to put the UI on top as a main() program (one of
several possible main()s ), and link BOARD_ACTIONS and below without the UI into one or
more DLL/DSOs, making opportunity for a number of layers in your underlying libraries.  It
also means that the scripting interface can also sit on top of BOARD_ACTIONS, so you can
drive most everything from scripting, but you start with all the richness of the C++
procedural code rather than having to reproduce it in the scripting language, even though
you still can.

The short answer is that this recognizes purposeful boundaries within the code.

Dick