kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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

> 
> This will all be forgotten before it gets coded, mark my words.  So over and out.
> 
> Dick
> 
> 
> 
> _______________________________________________
> 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
>