kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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