kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 05/03/2013 03:07 PM, Adam Wolf wrote:
> 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.


You can push to your own branch, and they can get it from there.

We're having a discussion now.

(I'm beginning to wonder if open source software development is a spectator sport after
all.  This is why a lot of stuff happens off list.)

This is a reasonably significant architectural decision, and having folks become dependent
on some temporary feature is not prudent, and I don't want it to lock us in to honour some
previous API, or form of obligations.

So I think its best that the testing branch be done correctly.  I would want to consult
with Jean-Pierre and Wayne, probably in private.


The GPL says you get to use my code.  It does not say I have to accept yours.  The process
here is not democratic.  It is evolution by consultation.

Folks are free to publish their own branches, and you can vote on those branches.  In
branch testing, I am a key shareholder, and I have trusted people that I consult to make
important decisions.


$ bzr log | grep 'ickelbeck\|ollenbeck' | wc -l
1187

The 1187 commits.... should mean something to you and should explain why every now and
then I perk up and assert more control.  Actually I am in control *all* the time, it only
looks like I am not, because the consultative decision process is happening without you
knowing it apparently.  This is not to say I have to or want to control everything,
precisely not.  But exposing APIs means people become dependent on them, that is a form of
an obligation.  Obligations are somewhat binding, so I perk up.  Other stuff is not as
important.

So no, we're not committing your patch.  At least not at this time.  But I said that in so
many words yesterday.


Dick




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