kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

>> 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.
> If possible, we may want to separate out the schematic item drawing code
> since the only application where it is use is Eeschema.  This would
> simplify the design and prevent the drawing code source file from
> getting unwieldy.  Some of the object drawing code is fairly lengthy so
> putting all of them in a single source file may be a bit much.  It also
> might be useful to put the source files for the schematic drawing code
> in the eeschema folder since that is the only place where they are
> needed.  There also is a need to create a third drawing class for
> component library objects derived from base class LIB_ITEM.

Certainly the implementation files, *.cpp, should be different.  I am still pondering
about a common header file, unable to let go of that.
This is the file you shoot in the head when you switch graphical libraries.
I don't understand why LIB_ITEM tree needs a separate header or even class.

You simply add another public

void Draw( const LIB_ITEM* );

to this same class, conditionally compiled with -DEESCHEMA.


The genius of these classes is really in the constructor design.  (classes plural? yes
because it is multiply compiled.)

{
    PAINTER painter( wxDC(this /* window */ ) );

    painter.Draw( item );
}

The value of having a common header file is that:

a) you shoot it in the head with one shot.
b) it ensures you can always see a common strategy between the various programs using it.

The only disadvantage is that:
A) it assumes you will have a common strategy between EESCHEMA and PCBNEW, and they are
moving in opposite directions regarding units.
EESCHEMA is going dimensionless, and PCBNEW is moving towards nanometer internal units. 
So depending on what is brought into this class,
having them tied *may* be un-desireable, or *not* if you stay cognizant of this issue when
adding stuff to this class, and don't say "sit" to both a dog and a fish.

I don't think readability is an issue since you have just a bunch of concise function
prototypes arranged by program.