kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 22/06/2014 11:20, Maciej Sumiński a écrit :
> As I have already most of the tools adopted to work with module editor,
> I have a few suggestions that may result in cleaner and more generic
> code. They require a bit of changes in the internals of KiCad, therefore
> I prefer to ask for your input before I proceed.
> I am not sure if the efforts are worth it - if there is half of KiCad
> code to be ripped out, then I will leave it up to the moment when GAL &
> Tool Framework are mature enough to become the main interface. I will be
> able to tell more when I start digging through the code, if the ideas
> get acceptation.
> 
> 1) Change MODULE-specific structures (TEXTE_MODULE, EDGE_MODULE) to have
> a common interface for position control.
> The main difference between module and non-module version is the module
> type store two types of coordinates: relative (to parent module) and
> absolute. The developer is forced to synchronize them if one of them
> changes, because there are separate methods to access them. I propose to
> drop the relative position field and modify the methods to compute
> relative position on the spot.

You cannot drop the relative position.

The reason there are two types of coordinates in footprints items is due
to the fact footprints can be rotated by 0.1 degree increment.

Therefore, when a footprint is rotated, due to rounding issues, the
relative position cannot be exactly known.

The major issue is when footprint is rotated many times (by few degrees,
not 90 degrees).
When the internal units were 0.1 mil, the rounding issues made the
footprint very different from the initial footprint:
the pads were moved by few mils in some cases, which is very critical
for pads.
Even for footprint outlines, the modification is very noticeable.

Of course, with nanometers as internal units, the issue is smaller, but
it exists.

In fact this is the absolute coordinate which should be computed from
the relative coordinate.

> That makes one step closer to simplifying the class tree that probably
> could live without the MODULE flavoured classes, but I do not dare to
> propose it right now.
> For the time being I would make TEXTE_MODULE inherit from TEXTE_PCB.
> This way they are no longer parallel in hierarchy and offer a common
> interface to be used by the tools.

Should be possible.

> 
> 2) Unify the way undo buffer works in the layout and module editors.
> There is a special undo operation type for the module editor
> (UR_MODEDIT) that saves the entire edited module. Such entry has to be
> created before any modifications are done, in contrary to other undo
> operation types that are stored afterwards. I believe the module editor
> could work in the same manner as the layout editor and UR_MODEDIT could
> be disposed.
> 
> 3) Create an abstract class BOARD_CONTAINER.
> The class will contain 3 pure virtual methods, that have the same
> purpose as in the BOARD class:
> - void Add( BOARD_ITEM* aItem[, bool aAppend] )
> - BOARD_ITEM* Remove( BOARD_ITEM* aItem )
> - void Delete( BOARD_ITEM* aItem )
> If BOARD and MODULE classes implement the BOARD_CONTAINER interface,
> tools may add/remove items without testing if it is a board or module.

No opinion about that.

> 
> I look forward to hearing from you.
> 
> Regards,
> Orson
> 

-- 
Jean-Pierre CHARRAS