pcbnew Module Editor & Viewer GALification blueprint
Maciej Sumiński/CERN <maciej.suminski@cern.ch>, May 2014
In order to complete the GALification process of pcbnew, there are three
remaining view panels that should be replaced by a GAL canvas, the pad
viewer, the library module editor & viewer (aka browser).
To keep look-and-feel of pcbnew consistent, the canvas should be
selected basing on the current view. If user sticks to the legacy view -
it should stay this way in the editor and browser as well.
Pad viewer
The pad viewer is shown when one opens properties window for a pad. It allows to see changes introduced by modification of the edited pad's properties in the real time. All operations are handled by DIALOG_PAD_PROPERTIES class. The visualization is presented on wxPanel (m_panelShowPad). To replace it with GAL view, I see two possible solutions (both are a bit hacky, but this is what happens when there are 2 views in parallel):
- Change m_panelShowPad type from wxPanel* to wxWindow* and if GAL is to be used - recreate it in DIALOG_PAD_PROPERTIES constructor, fix the code in painting routine.
- Add DRAW_PANEL_GAL (or a simpler object that only displays BOARD_ITEMs) to DIALOG_PAD_PROPERTIES_BASE and hide either m_panelShowPad or the GAL canvas in the DIALOG_PAD_PROPERTIES constructor.
Module viewer
The viewer owns a canvas that displays a selected part and allows to zoom in/zoom out/pan the view. Changing the legacy view to the GAL one should be a relatively easy task, considering FOOTPRINT_VIEWER_FRAME inherits from EDA_DRAW_FRAME. That means, it already contains the right canvas - it just has to be explicitly shown and then a few have to be extended by routines to deal with drawing and controlling the view.
Module editor
Proposed improvements
- Use the tools that were created for the Tool Framework. That will allow users to have e.g. SELECTION_TOOL, all upgrades done for drawing tools, EDIT_POINTs for graphics editing.
- I have seen user requests for having a possibility of drawing on
layers different than silkscreen (particularly the edge layer).
There was a comment that it may break DRC/zone filling. I suppose it
is due to the algorithms that do not expect anything on the edge
layersto be stored in modules.
TODO: propose a sensible solution to the problem
Other remarks
To reduce amount of replicated code, there could be created a new, simple widget which has only one purpose - draw a BOARD_ITEM and allow simple view control (zoom in/out, panning).