← Back to team overview

kicad-developers team mailing list archive

Re: Plot and drill file generation via scripts

 

On 05/03/2013 02:23 PM, Lorenzo Marcantonio wrote:
> On Fri, May 03, 2013 at 02:02:01PM -0500, Dick Hollenbeck wrote:
>> What about what I think Lorenzo?  Is that important to you in any way?
> 
> I reread this:
> https://lists.launchpad.net/kicad-developers/msg07515.html
> (is this what you were talking about, right?)
> 
> Quote your message:
> 
>> 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.
> 
> Well, what I call 'procedural code' could be fit inside your
> BOARD_ACTION stuff. In substance I completely agree with your plan.
> The whole print controller is more or less 'a piece' of the board
> action. Since it's somewhat hypotetical I'd say that the plot
> controllers and the drill controllers are part of the board actions
> interface (not necessarily everything should be put in one class)


If they are not in one class, this makes the mix-in tougher back up at the PCB_BASE_FRAME.
You end up with 2,3,4 classes, each holding a BOARD*, and each being mixed in via multiple
inheritance?  Instead of one class.

In that posting, which was nearly a year ago, I said I had been thinking about it for over
a year.  When you add that up, this is two years, at least.


> 
> In the message before I intended to say that probably there is no need
> to 'deeply integrate' it with the frame since most probably it could
> live by itself (a BOARD* probably would be sufficient for doing the
> work). 

I am thinking that multiple inheritance at the FRAME level is one line of code to do the
mixin.  And yes, of course it can live detached as well.  One class, two living
environments.  If instantiated stand alone, then it is an interface for python.  If
instantiated as part of frame, it augments a frame.

Since it is ONLY actions, i.e. procedural calls, then the integration happens in the
frame, no that is already done.  Just move *procedural* functions into BOARD_ACTIONS, no
event handling, no dialogs, no UI.

What am I missing?

The dialogs can stuff something like the PLUGIN PROPERTIES object, which could be renamed
to say, OPTIONS.  Then OPTIONS can be passed to some of the functions in BOARD_ACTIONS.
Or python can stuff OPTIONS, and do the same.

This has been my vision for 2 years.  Just saying you don't like it or that it is not
necessary, is actually an insufficient argument.  Will it work, and what is better if
anything, and why?


Dick



I was referring to the following paragraphs where you say:
> 
>> 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.
> 
> Since these are 'new' interfaces and not adaptations they can simply use
> the public interfaces without needing to be mixed in.
> 
> So, two use cases
> 1) Plot from UI: PCB_FRAME creates the dialog, dialog uses a controller,
> controller does stuff using the board public interface
> 
> 2) Plot from script: python creates the controller with a board,
> controller does stuff using the board public interface
> 
> I guess it can't be neater than that...
> 
> In short, I substantially agree with your whole idea. Otherwise I don't
> get what is different in your plan.
> 



Follow ups

References