kicad-developers team mailing list archive

[Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>]

Thanks.

My company has a little money and a little time to help out a Free and
Open Source ECAD tool.  So far, we've chosen Kicad.  We spend time
every week doing things like maintaining build servers (time *and*
money), working on the Mac packaging scripts, answering people's
questions about the PPAs, writing Kicad tutorials, teaching Kicad
classes, and adding tests to Kicad.  A friend of ours runs a board
order.  At one point, and maybe still, Kicad was the single largest
source of files for his order.  We was hoping to give him a little
functionality that Eagle has, by using the Kicad Python scripting
support.

I didn't realize there were large architectural changes that would
have to precede adding a file to the SWIG interface.  If I would have,
I certainly wouldn't have approached this feature.

I've been polite and gracious, but to be completely honest, I feel
discouraged by both the tone and the content of some of the responses
in this thread.  Is there a different way you would suggest that I
should have approached this?

Adam Wolf
Wayne and Layne, LLC

On Fri, May 3, 2013 at 4:39 PM, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
> 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
>>>>
>>>
>>
>