On 02/01/2012 04:36 PM, Wayne Stambaugh wrote: > On 1/31/2012 3:32 PM, Dick Hollenbeck wrote: >> On 01/31/2012 12:49 PM, jean-pierre charras wrote: >>> Le 30/01/2012 19:06, Dick Hollenbeck a écrit : >>>> Jean-Pierre and Tom, >>>> >>>> >>>> Wayne came to stay at our house this weekend. He is a great guy, even >>>> classier than he >>>> comes across in his emails. >>>> >>> I believe it easily. >>> >>>> During our visit we talked about many things, one of which was an idea >>>> that came in from >>>> Tom last year. >>>> >>>> Attached is a sketch of a class would be compiled multiple times to remove >>>> the drawing >>>> code from the graphical objects, isolating it into a single class. The >>>> advantage is that >>>> we can use alternative output devices (and graphical or plotting >>>> libraries), without >>>> constantly adding member functions. The member functions we assume will >>>> cause problems >>>> linking these container objects as DLL/DSOs, in a way that we can put >>>> scripting and >>>> command line processors up on top of them. >>>> >>>> I sketched this out this morning, and it provides the basic idea. We >>>> sacrifice >>>> polymorphism in BOARD_ITEM::Draw(), but the overhead of PAINTER::Draw() is >>>> minimal >>>> relative to other bottlenecks. It will simply mean you call >>>> PAINTER::Draw() almost >>>> everywhere. >>>> >>>> To interpret the context of the code, we are assuming the following: >>>> >>>> 1) bottom end (data model) PCBNEW code will be linked into a DLL/DSO >>>> >>>> 2) bottom end (data model) EESCHEMA code will be linked into a DLL/DSO. >>>> >>>> 3) they will never be linked together, but might operate together under >>>> one process. >>>> >>>> >>>> This means we can multiply compile class PAINTER with either >>>> >>>> -DEESCHEMA or >>>> -DPCBNEW >>>> >>>> There is no reason to have an inheritance tree in class PAINTER, since it >>>> is multiply >>>> compiled, separately linked. When and if we ever change >>>> graphical libraries, we REPLACE it at compile time, not runtime. >>>> >>>> Please let me know if you have any questions, and what you guys think. >>>> Tom since this was >>>> originally your idea, I wanted to bounce this off you also. >> Seems Tom is no longer following the KiCad project :( >> >> (or is too busy to even read and reply to his personal email, because I sent >> a separate >> one to him personally.) >> >> >>> I agree. >>> This approach has some advantages. >>> And graphical libraries will certainly change in the future. >> Thanks Jean-Pierre. >> >> I guess we can keep this in mind as we free up man-hours. >> >> It may be that building DLL/DSOs will require a number of fragments, not >> just one >> horizontal cut per application. I roughly see: >> >> 1) a lower level cut for data model without actions other than load, save >> and add and >> delete elements. This allows automatic document generation and manipulation >> from scripts. >> >> 2) a higher level cut for existing actions (without GUI). This argues for >> using some of >> the actionable "verb" type operations. The current difficulty is that they >> are tied to >> the wxFrame and I'm not sure this is OK or not yet. I still think at this >> "verb" layer >> you want no GUI in the actions, because the scripting upper layers would not >> need or want >> them. > I think most of what is in the wxFrame objects are the settings used for > printing, plotting, etc. These settings could easily be passed to the > appropriate verb operation via parameters or a class to encapsulate > them. I don't think that wxFrame derived objects are actually used to > perform any of the action operations although I could be wrong. > > Wayne
Wayne, That sounds like a good idea. As you say, if need be, maybe add a controller class for these UI-less portions. Then you could use multiple inheritance at the PCB_EDIT_FRAME level to re-introduce the controller back into the frame, except that you have it separate from the UI when you need it as such for scripting. Dick _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
