kicad-developers team mailing list archive
Mailing list archive
v6 roadmap and schedule (was Re: 5.1.5 released.)
On 29/11/2019 13:56, Wayne Stambaugh wrote:
It's not as up to date as it should be but it's pretty close
I'm hoping some feedback on these goals would be welcomed:
User Interface Modernization
Give KiCad a more modern user interface with dockable tool bars and
windows. Create perspectives to allow users to arrange dockable
windows as they prefer.
Even though v5.1 is better than v5, and v5 better than v4, this is welcomed.
The Adobe tools (Photoshop, InDesign et al) have the idea of preset
workspaces, which are not prescriptive and do not imply anything about
the way the product works, but are simply arrangements of windows, etc,
that make sense for the named tasks. I find them helpful when I want to
"switch mode", whereas I'm happy to do manual changes inline as I work.
I would encourage KiCad to explore this idea too.
* Take advantage of the advanced UI features in wxAui such as
detaching and hiding.
Definitely looking forward to this as well. Can I suggest, as for
workspaces, that keymaps can be grouped and labelled and easily switched
between, so that we can have the legacy keymap for those who don't want
to change, the new keymap, and named custom keymaps. This will make life
so much easier for users and devs alike.
* Develop a global shortcut manager that allows the user assign
arbitrary shortcuts for any tool or action.
I would most *definitely recommend* anyone doing UI work on either of
these topics to explore the JetBrains tools, some of which (e.g.
PyCharm) have free editions. I very much like their way of setting up
Keymaps (Preferences), and of being able to search for an action by name
and invoke it immediately and/or see where it is in the menu (Help
menu). I also really like the "search for setting" implementation in the
I'm not so keen on the JetBrains implementation of floating / docked etc
windows, which I think was much better done in Visual Studio
(traditional version). Adobe does several things right in this area as
well, and IMO it's not clear whether Visual Studio or Photoshop has the
better "docking window" implementation.
* https://www.jetbrains.com/pycharm/download/ ; (PyCharm Community ed.
is free to use).
* https://visualstudio.microsoft.com/ ; (Visual Studio Community 2019)
(Adobe Photoshop CC free trial download)
Just a comment about the file format: *please*, please ensure that there
is a defined order for writing 'things' in a collection to file.
Implement Sweet (S-Expression) Symbol Libraries / + /
S-Expression File Format
Make schematic file format more readable, add new features, and take
advantage of the s-expression parser and formatter capability used in
This is so that loading a project, making some change, and then saving
it again only changes lines in the output file(s) directly related to to
change. This so that source control tools like git can track actual
differences, without being obscured by other, inconsequential ones.
I say this because it seems to me that v5 reads into an unordered
collection and therefore writes it out unordered, so writing the "same"
file again may change 90% of it by "chance".
To do this, I think the various file writer implementations must:
- for every collection/list/set/group, the order of things read in
from a file must be retained when written out.
- even when there is flexibility in the file format to reorder data
chunks, that once a file is read in this order does not change when
written again (of course, it could be the same order every time).
- items in the file should not be labelled with transient IDs (e.g.
the component reference numbers are ok, but a number that is just a
sequence number for this save is not). This so that inserting something
doesn't result in every item after that being "changed" because its
sequence number is now incremented. User-visible changes (reference
numbers) would be ok: you really are changing lots of things from the
- where possible, line breaks should be inserted so that user-visible
properties that change can be diffed showing just that change and not
the whole entity. E.g. if the type of a component changes but nothing
else, you see a diff of the form:
- type: old name
+ type: new name
There may be more, but those are the basics.
I would suggest freetype2, on the basis that it is widely portable and
used widely as well, unless using "native" wxWidgets provides a
significant integration advantage.
Allow Use of System Fonts
Currently the schematic editor uses the stroke drawn fonts which
aren't really necessary for accurate printing of schematics. Allow the
use of system fonts for schematic text.
* Determine which library for font handling makes the most sense,
wxWidgets or freetype.
* Add support for selecting text object fonts.
I would be interested to know why it is not possible/good to use
"normal" outline fonts (ttf, otf et al) on a PCB.... what are the issues?
Would this mean that we could have named "wire styles", which we can
draw on the diagram and the properties of the drawn wire are taken from
the style definition? I'm thinking something like "character styles" on
a wordprocessor defining things like font and colour.
Custom Wire and Bus Attributes
Allow for wires and buses to have different widths, colors, and line
The advantage: if you use one wire style for e.g. power, one for e.g.
RF, you can easily change them.
Bonus points to be had if a style change to e.g. width could cause the
router to rejiggle the wires to fit!
[Thought applies to both Schematic and PCB editors]
Could we have a method to mark particular rule violations as being
acceptable, where it has been determined that although the rule has been
broken that in this case there is no problem? Not sure how the UI
should work. Probably mostly UI thing - the checker can still flag
these, and then some are suppressed.
Improve ERC test coverage and other ERC usability features.
* Add missing ERC tests to improve coverage.
* Save ERC settings in project file.
* Add mechanism to allow import and export of ERC settings.
* ERC user interface improvements.
Might this include being able to select two traces and tell it "those
are supposed to be DPs"?
Pcbnew: Circuit Board Editor
This section covers the source code of the board editing application
Push and Shove Router Improvements
Add finishing touches to push and shove router.
* Delete and backspace in idle mode
* Differential pair clearance fixes.
* Differential pair optimizer improvements (recognize differential
I'm not sure if it's been dealt with already but one of the issues I
struggle with is that component boundaries are the enclosing box, and
components cannot (AFAIK) be marked as not selectable. For example, I
have a "component" which is the outline of a daughterboard (for a BB
Black). The component ensures the relation between the edge cuts and the
connector footprint is maintained. However, on more than one occasion I
have messed up the board badly by moving the board component without
* Respect trace/via locking!
* Keep out zone support.
* Microwave tools to be added as parameterized shapes generated by
* BGA fan out support.
* Drag footprints with traces connected.
I have two requests from this situation:
1. I would /really/ like to be able to lock components in place,
preventing them from being moved (or even selected) until unlocked. Lock
= select and "Lock", Unlocking might be done with a separate list of
locked items, or with a UI action that unlocks anything in a drawn area,
or by an Unlock All action.
2. I would like the selection code to prefer selecting items by visible
artefact, e.g. a line or some text, and only if there is no such
artefact under the cursor to consider things nearby. I'm particularly
thinking here of clicking on an component placed beside e.g. an IC
footprint, though not on it. If the component is under the cursor then
that should be selected directly even if the cursor is also within the
bounding box of the IC.
Design Rule Check (DRC) Improvements.
Create additional DRC
<https://docs.kicad-pcb.org/doxygen/classDRC.html> tests for improved
As for ERC, a way to mark specific violations as acceptable.
Could this include annotating track lengths onto the tracks -- that is,
include the length of a track next to the net label?
Add support for teardrops and automatically updating length tuning
* Draft specification for track refining.
* Implement support for teardrops.
* Implement support for changing tuned length meandering.
Would it be possible to have a view mode that highlighted EMR from track
shapes? E.g. for a sharp bend it would annotate the 'point' of the bend.
I'm a bit out of my depth on what is possible but I hope you get the
idea. The overall purpose is to show where any EM problems are likely to be.
It would also be interesting to see some sort of heat map view - that
is, take the specified track width and thickness and colour-map the
traces with the predicted resistance (and possibly, given info about
voltages somehow, current).
Is this the pcb editor's equivalent of the schematic editor's
possible-but-difficult to arrange multiple-linking of one circuit onto a
parent, so I can have one schematic of, e.g. a preamp and use that
several times, one for each channel? That would be cool!
Groups and Rooms
Support grouping board objects into reusable snippets.
Can we have a nice UI for it in schematic as well?
Is there scope for "exceptions" -- the layout is repeated except for
this component or that trace? E.g. a multiband filter that has a
resistor defining the frequency, or E.g. channel linking traces go
"here" to join up, except for the end one, which goes "there".
What is the status of multi-board projects (e.g. main + daughter board).
What is the status of defining off-board links, e.g. where the project
board signals link in some way on the main board, but the main board is
not in the project? This is more about ERC/DRC checks than anything else.
I have seen cases where automatic thermal reliefs interact badly with
board traces to create nice sharp corners and etching holes. It would be
good if the TR code could check for such issues and possibly fix them.
Thermal Relief Improvements
Allow for custom thermal reliefs in zones and custom pad shapes.
Any chance of being able to view-time modify 3d models parameters, e.g.
the colour of metal or plastic, or its reflectance? It would be nice to
be able to get a white plastic connector representing a part when the
standard model was black, for example.
3D Model Improvements
Add opacity to 3D model support and convert from path look up to
library table to access 3D models.
* Add opacity support to footprint library file format.
* Add library table 3D model support to footprint library file format.
* Create remapping utility to map from path look up to library table
* Add user interface support for 3D model opacity.
* Add user interface support accessing 3D models via library table.