This page hosts a proposal for work packages, which are supposed to
bring Kicad in par with the features of proprietary software that are
required for designing boards of similar complexity to our SPEC/SVEC
1. Unified geometry library
Type*: framework/library Goal*: clean up existing geometry routines. Add functionality
necessary for more advanced DRC and P&S. Depends on*: none. First client*: P&S router Status*: Started. Bare minimum required for P&S implemented. Specific release*: along with the P&S router.
A one-library-to-rule-them-all for spatial indexing and geometry
operations on 2D shapes. Specification
2. Push and Shove router
Type*: tool Goal*: modern routing tool. Depends on*: geometry library Status*: C** demo available. Specific release*: pcbnew with P&S route tool
The initial aim is do develop a simple push & shove router and integrate
it with existing pcbnew codebase, without any dependencies on the new
view, etc. The requirements are:
routing single tracks with clearances as specified in the design
walk-around and shove modes (for tracks).
initial version will have no via/component shoving support.
routing engine performs intermediate calculations on its internal
model and updates the main (BOARD) model whenever a 'stable' routing
routing engine might run in a separate thread, to make it more
3. View component
Type*: framework/library Depends on*: none Goal*: robust display layer for all Kicad applications, based on the
GAL. Refactoring towards clean MVC model. First client*: tool framework
*Status": demo available. Integrating into pcbnew. Specific release*: pcbnew (and later on, all apps) with the new
Graphical item view for all Kicad applications, based on the Graphics
Improve the GAL, so that it is capable of rendering a complex board
on entry-level hardware. Initially, support two GAL backends:
- OpenGL for 'normal' work. Must be extremely fast, things like
anti-aliasing are second priority here.
- Cairo for high quality rendering, bitmap export and maybe
Integrate the VIEW in pcbnew. First stage of integration will result
in non-editable view, that can be switched with the legacy one
during run time.
Second stage will come up with a fully functional VIEW, but will
require significant refactoring in the tool code. The reason is that
tools use a lot of XOR rendering to erase items off the screen,
which is not compatible with any reasonably modern rendering
Allow users to select own layer color scheme, layer transparency,
drawing order, contrast and wireframe/solid rendering mode.
Given the experience gained with pcbnew, redo gerbview and
schematics in the same manner.
After a review & testing period, remove legacy rendering from Kicad
Refactor printing to use the GAL (via either wxDC or cairo). Cairo
provides native printing (via GDI+) on Windows and a PS filter for
Linux/OSX. Use native GTK printing dialog under Linux (default in wx
(extra) evaluate the View class interface extensions that would
enable native 3D editing.
Type*: framework/library Depends on*: View component Goal*: Conflict-less way of developing tools. Script-driven tools.
Refactoring towards clean MVC model. First client*: P&S router
*Status": planning Specific release*: pcbnew with fully functional P&S.
Currently all editing tools in pcbnew reside in a single, enormous class
(PCB_EDIT_FRAME) entangled with numerous editing methods in the model
& a bunch of global/static functions and variables. Such code is very
difficult to maintain and extend.
Each tool belongs to one of following categories:
- interactive, such as a PCB router - that once activated take a
group of keyboard/mouse events and process them until an exit event
is received. Only one interactive tool can be active at a time.
- batch, which are run once in response to a UI/Scripting command
(such as DRC)
- background - background tasks that are always active and filter
events before they are passed to other kinds of tools. Examples are
zoom or highlighting.
Interactive tools are implemented as (hierarchical) state machines.
An interactive tool can call another interactive or batch tool (for
example, drag tool internally calls selection tool to know what to
Each tool has a predefined activation event, and accepts a
predefined range of keyboard/mouse events, assigned when the tool
instance is created. Tools can exit when they want or when
application-wide exit event is received (i.e. pressing Esc).
In general, tools are not allowed to draw anything that doesn't go
through the View, unless there exists a very good reason for doing
so (an example is drawing transparent selection boxes or moving
large groups of items)
One tool = one class. Tools must not use non-trivial static methods
and must never, ever, have any global states. Main tool interface
must not have any wx dependencies. If the tool needs special GUI
other than a menu entry, shortcut and button in a toolbar or the
right-click menu (e.g. a settings dialog/docker), it must be handled
by a separate, non-public class.
Tools are registered within a application-wide tool manager via a
factory class/function. This allows for adding tools as DLL/DSO
Tools use Kicad-internal event format, that works with native board
units and follows gestures & shortcuts set in application
preferences. A big advantage of this approach is the ability to
drive a tool with a series of events from a script. For instance, an
automatic BGA fanouter script could simply run the P&S tool with a
click-move-click series of events for each pad instead of
calculating every breakout trace itself.
Work to do:
come up with a specification
make the initial version, that works in parallel with the legacy