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.
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)
SCH_WIRE
SCH_BUS
SCH_LINENOTE
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
like
SCH_LINE_BASE (abstract)
SCH_CONDUCTIVE_LINE
SCH_WIRE
SCH_BUS
SCH_LINENOTE
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
application:P)
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!
