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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 : [email protected] >>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>> More help : https://help.launchpad.net/ListHelp >>>> >>> >> > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
