kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>]

Hi Dick,

2012/3/18 Dick Hollenbeck <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? :)



-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo