kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

I haven't even had time to read what Lorenzo is thinking yet.  And as I said, I would not
do anything this big without talking to the key share holders, excuse me, lead developers,
JP and Wayne.

So at some point, providing I can catch up in time to satisfy you, by me executing those
steps, that would be something I can do, yes, provide you with a quote.

The consultative decision process, ahem, involves consultation.  And believe it or not,
consulting your patch would be on that list also.  I haven't even looked at it yet.

But then, yes, the functionality is needed, and I am delighted you are open to funding the
balance of work, and providing a portion of it possibly, as already written.

Thanks for asking.

Dick




On 05/03/2013 04:23 PM, Adam Wolf wrote:
> Hi Dick,
> 
> I appreciate the 1187 commits.  If I didn't, I would have simply
> created another PPA and maintained a testing branch, selling this
> functionality to board houses.
> 
> Can you tell me (privately if need be) how much Wayne and Layne would
> have to pay to have you implement enough of your desired changes so
> something providing this functionality is acceptable and can be
> committed in core?
> 
> Adam Wolf
> Wayne and Layne, LLC
> 
> On Fri, May 3, 2013 at 4:05 PM, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
>> 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
>>>
>>
>