← Back to team overview

kicad-developers team mailing list archive



On 5/7/2012 2:48 AM, Lorenzo Marcantonio wrote:
On Sun, May 06, 2012 at 09:15:11PM -0400, Wayne Stambaugh wrote:
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

SCH_POLYLINE at the moment can only be instantiated from 'p' .sch
records, and that's all! There is loading support for layers but it
mostly doesn't participate in the 'electrical' handling. grepping for
SCH_POLYLINE in all eeschema and common gives:

- A special case in DeleteCurrentSegment

- The class definition itself

- The load operation

- It's in the collectors sets

- Traces of a graphic polyline in the hotkeys file

There is *no way* to instantiate a polyline, so unless there are some in
legacy files I'd say it can be safely ripped out. Even in that case the
load routine could simply instantiate the replacing SCH_NOTELINE (my new
class name) for them. Anyway since now I'm sure it's graphic only I can
finish the m_Layer-icide

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

Sure, it could be interesting.

I'll send you copy this evening when I get home. I walked out the door this morning without my thumb drive.

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

*Somewhere* global definition must be kept XD

As for the 'layer' decoupling I was thinking of simply add a virtual
'primitive color' getter for the SCH_ITEM and simply letting them pick
from the old array. It's reasonable IMHO.

My current refactoring gives:
SCH_LINE_BASE (abstract)

Deriving BUS or LINENOTE from WIRE isn't correct since the IS-A
relationship doesn't stand. If someone *really* didn't want the abstract
intermediate a more suitable parent would be the 'graphic line' but it's
somewhat stretched (since most of the time checks call for a 'wire or
bus' type check). To merciless refactor the hierarchy should be more

SCH_LINE_BASE (abstract)

But that's overkill too, since for many thing buses are actually graphic
lines... loading is done with a static factory method int the
SCH_LINE_BASE (I'm not a pattern fan but this is an handbook

My plan was to use SCH_LINE as the graphical line class. This would require moving the overloaded connection functions into the derived objects SCH_BUS and SCH_WIRE. Using SCH_LINE_BASE is fine but you will end up with one extra class which you will have to prevent from being instantiated since SCH_LINE_BASE will not have a valid KICAD_T or ever need to be used directly.

In the same way I split in two the SCH_BUS_ENTRY.

Makes sense to me. I forgot that layer is used the same way in SCH_BUS_ENTRY as it is in SCH_LINE. One thing you will have to be aware of is that the net list generator currently uses the layer to determine the net connections when the object is a SCH_LINE or a SCH_BUS_ENTRY. You will have to change the net list generator to handle your new objects appropriately.

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.

Another witch hunt I'm doing is for the EDA_COLOR_T type which is mostly
carried around as an int... we have a specific time, so we should use it
(otherwise what is type safety for?). Also the EDA_COLOR_T enum is
a testimonial to 'type evolution' XD it started as a simple enum then
some flag was added and now it contains an alpha value it the bits
24-31! I actually discovered a thing or two like

GRLine( ..., WHITE | GR_XOR )

which are blatantly incorrect since GR_XOR is a write mode (which isn't
stored in an EDA_COLOR_T). Well, now the compiler is flagging them to
me. Fortunately now I've got a quad core to do the recompiles!

I'm not sure why this was done this way. If it can be remove without breaking anything, by all means remove it. While you are on a roll please feel free to use enum EDA_COLOR_T when passing color values instead of int.

Thank you for your efforts.


Follow ups