kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 5/6/2012 11:51 AM, Dick Hollenbeck wrote:
> On 05/06/2012 10:11 AM, Lorenzo Marcantonio wrote:
>> On Sun, May 06, 2012 at 04:55:54PM +0200, Miguel Angel Ajo Pelayo wrote:
>>> I think it's a very useful work, as it would make the scripting users (when
>>> we have
>>> eeschema in scriptin ) work with the objects in a more natural way :-)
>> Too bad that the non-OO origins of kicad are very evident (tons and tons of Type() switches around...); I was asking about the SCH_POLYLINE because I don't know if it should:
>> a) junked
>> or
>> b) refactored in 3 classes
>>
>> Given its current usage I'd vote for a), but better ask than be sorry...

AFAIK SCH_POLYLINE is only used for graphic ( non-connectable ) lines
although there is no reason that they couldn't be created as SCH_LINE
objects.  Wires and buses are created as SCH_LINE objects using the
appropriate layer.  I'm not sure that you can get rid of SCH_POLYLINE.
You would have to convert all SCH_POLYLINE objects into individual
SCH_LINE objects which would increase the schematic file size on
schematics that have a lot of graphic line items although I doubt that
many actually do.  Take a look at eeschema/bus-wire-juction.cpp to see
how lines, wires, and buses are created and modified to get a better
idea of how all this works.

> 
> By all means wait for an answer from Wayne.  There is a whole new file format spec for
> Eeschema already written.  I'm sure there are things going on here you cannot yet see.

I can send you a copy of last draft of the new schematic file format if
you would like to take a look at it.  I was tentatively planning on
adding SCH_WIRE and SCH_BUS objects which should be derived from
SCH_WIRE.  This should (famous last words) eliminate the need for the
m_Layer member in the SCH_ITEM object.  You would still need to decouple
the layer and color associations but I don't think that would be
terribly difficult.  I'll give you bonus points if you can figure out
how to manage the SCH_ITEM colors without accessing global color map
like the current "LayerStruct g_LayerDescr;" found in
eeschema/eeschema.cpp :).  I could see the SCH_PAINTER class (derived
from PAINTER) being a useful place to hide this after someone (me?)
writes it.  I'll try to answer your questions as promptly as possible
but I'm a bit busy right now so it may be day or two before I get to it.

Wayne


> 
> 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
>