kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

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)

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 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.

-- 
Lorenzo Marcantonio
Logos Srl