kicad-developers team mailing list archive

[Ruth Ivimey-Cook <ruth@xxxxxxxxxx>]

Hi,

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
>
> https://docs.kicad-pcb.org/doxygen/v6_road_map.html

I'm hoping some feedback on these goals would be welcomed:


>     User Interface Modernization
>
> *Goal:*
>
> 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.

> *Task:*
>
>   * Take advantage of the advanced UI features in wxAui such as
>     detaching and hiding.
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.

>   * Develop a global shortcut manager that allows the user assign
>     arbitrary shortcuts for any tool or action.
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.

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 
Preferences window.

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.

See:

 * https://www.jetbrains.com/pycharm/download/ ; (PyCharm Community ed.
   is free to use).
 * https://visualstudio.microsoft.com/ ; (Visual Studio Community 2019)
 * https://www.adobe.com/uk/products/photoshop/free-trial-download.html
   (Adobe Photoshop CC free trial download)


>     Implement Sweet (S-Expression) Symbol Libraries  / + /
>     S-Expression File Format
>
> *Goal:*
>
> Make schematic file format more readable, add new features, and take 
> advantage of the s-expression parser and formatter capability used in 
> Pcbnew.
Just a comment about the file format: *please*, please ensure that there 
is a defined order for writing 'things' in a collection to file.

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 
user perspective.

  - 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.


>     Allow Use of System Fonts
>
> *Goal:*
>
> 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.
>
> *Task:*
>
>   * Determine which library for font handling makes the most sense,
>     wxWidgets or freetype.
>   * Add support for selecting text object fonts.
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.

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?

>     Custom Wire and Bus Attributes
>
> *Goal:*
>
> Allow for wires and buses to have different widths, colors, and line 
> types.
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.

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]


>     ERC Improvements
>
> *Goal:*
>
> Improve ERC test coverage and other ERC usability features.
>
> *Task:*
>
>   * 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.
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.


>   Pcbnew: Circuit Board Editor
>
> This section covers the source code of the board editing application 
> Pcbnew.
>
>
>     Push and Shove Router Improvements
>
> *Goal:*
>
> Add finishing touches to push and shove router.
>
> *Task:*
>
>   * Delete and backspace in idle mode
>   * Differential pair clearance fixes.
>   * Differential pair optimizer improvements (recognize differential
>     pairs)
Might this include being able to select two traces and tell it "those 
are supposed to be DPs"?
>   * Respect trace/via locking!
>   * Keep out zone support.
>   * Microwave tools to be added as parameterized shapes generated by
>     Python scripts.
>   * BGA fan out support.
>   * Drag footprints with traces connected.
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 
realizing it.

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.
>
> *Goal:*
>
> Create additional DRC 
> <https://docs.kicad-pcb.org/doxygen/classDRC.html> tests for improved 
> error checking.
As for ERC, a way to mark specific violations as acceptable.

>     Track Refining
>
> *Goal:*
>
> Add support for teardrops and automatically updating length tuning 
> meandering.
>
> *Task:*
>
>   * Draft specification for track refining.
>   * Implement support for teardrops.
>   * Implement support for changing tuned length meandering.
Could this include annotating track lengths onto the tracks -- that is, 
include the length of a track next to the net label?

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).


>     Groups and Rooms
>
> *Goal:*
>
> Support grouping board objects into reusable snippets.
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!

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".


*Related*:

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.


>     Thermal Relief Improvements
>
> *Goal:*
>
> Allow for custom thermal reliefs in zones and custom pad shapes.
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.

>     3D Model Improvements
>
> *Goal:*
>
> Add opacity to 3D model support and convert from path look up to 
> library table to access 3D models.
>
> *Task:*-
>
>   * 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
>     look up.
>   * Add user interface support for 3D model opacity.
>   * Add user interface support accessing 3D models via library table.
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.