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
