kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #13747
Module classes refactorization
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.
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.
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.
I look forward to hearing from you.
Regards,
Orson
Follow ups