CERN Kicad development roadmap
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 projects.
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 rules.
- 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 is achieved.
- routing engine might run in a separate thread, to make it more responsive.
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
display engine.
Graphical item view for all Kicad applications, based on the Graphics Abstraction Layer.
Steps:
- 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 printing. - 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 environment.
- 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 completely.
- 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 2.9)
- (extra) evaluate the View class interface extensions that would enable native 3D editing.
Specification: https://www.ohwr.org/project/cern-kicad/wikis/Documents/View-component-specification
Demo:
https://www.ohwr.org/project/cern-kicad/tree/master/tests/view_demo
4. Tool framework
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.
Rationale:
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.
Requirements:
- 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 drag).
- 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 plugins.
- 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 code
- port the P&S router to the new framework
- testing & review release
- refactor remaining of editing tools (one by one).
5. Page templates & script-driven text evaluation.
Type*: feature
Depends on*: python scripting.
Goal*: Removing KICAD_GOST build option.
Status*: planning
Specific release*: Kicad (all apps) with user-definable page
templates.
Rationale:
Currently, the page frame is hardcoded. There is no possibility of changing its contents other than conditional compilation (i.e. KICAD_GOST flag).
Plan:
- add option of saving graphical objects (no wiring/traces) into a
template schematic/PCB file and attaching such file
to a schematic/PCB. - mark items that belong to the template as non-editable (they can't be selected or otherwise altered).
- add spreadsheet-style expressions for texts (i.e. placing a text '=GetBoard().GetCreationDate()' will be rendered as the date itself).
- remove hardcoded page templates. Say goodbye to GOST flag.
6. Further modularization & decoupling
Type*: improvement
Depends on*: page templates.
Goal*: Cleaner code. Kicad applications as DLLs/DSOs.
Status*: planning
Specific release*: Kicad with lightweight core and optional
functionality done in plugins. Applications hosted as tabs in a common
'shell' window.
Plan:
* remove unnecessary build flags. The main reason is to limit the number of possible build configurations, which is often abused by Linux users/package maintainers to produce incompatible software packages. Features that are truly optional, should never be handled by #ifdefs, but turned into DLL/DSO plugins or Python scripts. Such flags are:
- KICAD_KEEPCASE: we should be either case-sensitive or not.
- KICAD_SCRIPTING: basic feature that must not be disabled once fully integrated and tested: DRC classes will become scriptable, filter tool will require Python expressions.
- KICAD_SCRIPTING_WXPYTHON: with the tool framework in place, wxPython console could become another DLL/DSO tool.
- USE_WX_GRAPHICS_CONTEXT: will be replaced by the GAL/VIEW.
- USE_WX_OVERLAY: same as above
- USE_PCBNEW_NANOMETERS: P&S relies on the new BIU format. There is no reason to keep the old one.
- USE_FP_LIB_TABLE: once done, it should become a standard
feature.
- wxUSE_UNICODE: does it make any sense to allow user to select this?
- factorize plotting code away from the model code, move plotting code into plugins.
- factorize 3D viewer code away from the model code (PAINTER-like equivalent for 3D or a 3D VIEW component)
- move 3D model loading into plugins. Develop a global 3D model cache.
- clean up program-specific #ifdefs (#ifdef EESCHEMA, #ifdef PCBNEW, etc.) in common code.
- modify the UI code to host pcbnew/eeschema/gerbv as tabs inside the common shell.
- compile eeschema, gerbview & pcbnew into DLLs/DSOs. If globals/statics cleanup is done correctly, several instances of these apps should run in parallel inside a common shell.
Improved 3D model support
STEP/IGES support for Kicad
Specification