kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

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)

In the same way I split in two the SCH_BUS_ENTRY.

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

-- 
Lorenzo Marcantonio
Logos Srl