kicad-developers team mailing list archive

[Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>]

Hi folks,

Can I selfishly suggest something?

Since Dick has a plan for where this goes and how the future interface
works, can we do the minor changes in my patch so that folks that
choose to use the experimental Python features can get to the drill
calls?

I tried to propose a solution to create drill and plot files from the
command line that has (hopefully) minimal changes to Kicad.  If the
team agrees that those minimal changes probably won't hurt anyone, is
it ok that they get committed?  I like Dick's vision and how nicely it
aligns with the dll/dso future.

Adam Wolf
Wayne and Layne, LlC

On Fri, May 3, 2013 at 2:45 PM, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
> 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.
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp