Post-v5 new features and development news

We’re discussing it, wanted to start with the PCB editor.

Buidling with MSYS2 should still be possible if you disable wxPython. Official KiCad builds will be using MSVC only so that we can ship with wxPython.

EDIT: Wayne says there is currently an issue with msys2’s Python package that needs to be investigated before it will build KiCad. But, the plan is to continue (partial) support of msys2 if at all possible.

1 Like

there should be already a solution for wxpython4 (py3 compatible) for msys2

and the patched repository here at GH
Would someone interested in msys2 have an eye on it?

you should take this discussion to the developer’s list – I don’t use msys2 so I’m not the right person to investigate it. I’m not sure if Wayne is following that.

MSYS2 support is purely about having someone interested in maintaining it and the issue isn’t our codebase, but the dependencies which is the msys2 ecosystem. I am the MSVC maintainer and have no problem working with Microsoft upstream to keep dependencies maintained in vcpkg but have zero interest in msys2.

We aren’t going to be packaging a potentially abandoned fork of wxpython ourselves, MSYS2 would need to include it upstream. wxpython itself is not in a good state at the moment as its a one man maintainer operation and it’s not even updated for wx 3.1.5. I had to manually do so for MSVC builds.
But if you really like msys2, I don’t see why you can’t make your own personal builds with it using the fork…

  1. if you read my posts and links, what is missing atm is the ability to build the fork… only the user who patched the fork seems to have found a solution that was not posted on the forum
    That was why I’m asking for some help in completing the path and later merging the patch.

In needed to add a few more changes to build scripts but no change to the source code. Will update the proposed modifications shortly after testing.

  1. msys is a full open source ecosystem, msvc is not…

I forgot to post about this at the time, so this is a bit old now, but nonetheless worth sharing.

As part of MR 801 on copy paste improvements, there is now a new option in the paste special dialog “Assign unique reference designators to pasted symbols”. In addition, this same dialog has been ported over to pcbnew so now copy/paste can be consistent between the two applications.

I personally use the new option as a very rudimentary design reuse feature. If you copy paste the same block in eeschema and in pcbnew using the “assign unique designators” option, the reference designators should generally match up, so you can then link the two up (via “Update PCB from Schematic”) and that will ensure unique nets are assigned and everything generally works.

There may be a few edge cases that aren’t covered: for example if you paste into a sheet that is instantiated multiple times in the schematic, you would essentially need to paste the same block in the pcb the same number of times as that sheet exists in the schematic.


that is very neat – many designs have circuits that repeat, so this will be quite useful.

1 Like

Even more useful would be to add a fourth option so that each designator would be incremented by a given constant value, e.g. from 1xx to become 2xx.

1 Like

@Olo That is quite beyond the purpose of the option. The idea is just to allow synchronising components between eeschema and pcbnew with an naming algorithm that can ensure consistency between the two applications. It is not intended to be used for reannotation - there is a specific tool for that purpose. After you have synchronised the schematic and pcb, you can use the annotation tool to reannotate as you wish.

I guess I should have posted about this change too: you can now also reannotate a selection in eeschema. (see MR 800). This was done as part of fixing bugs in reannotation which were producing duplicate references in some cases. The backend code required having the ability to reannotate a subset of components (in the current sheet), so it was quite trivial to implement the ability to reannotate a selection as part of the bug fix.


If you have any other specific annotation requirements, then please request that as a new feature on gitlab so it can be considered in the plan for v7 or thumbs up any of the existing feature requests.

Note that there is also a reannotate selection option in pcbnew but unfortunately it is currently broken… (See Not sure if that one will get fixed in time for v6 as it is quite involved - it might require a complete rewrite.


I think this is outdated. In [5.99] new syntax for INT\ ~{INT} etc Jeff tells about syntax which I think I haven’t seen in this thread, although this one has been going on for so long that it’s difficult to remember everything…

Basic support for arcs in polygons has been added, but see for clarification: this is not yet a feature for end users.

1 Like

3 posts were split to a new topic: V6 feature Arcs in Polygons

I remembered a small feature while answering to another thread, I didn’t find it here: in pcbnew print dialog it’s possible to choose “Print according to objects tab of appearance manager”. It’s a small change in the UI but may be a big help for some workflows which need printing. It’s possible to hide for example zones, values, references etc.

1 Like

Every now and then some user has been confused by a zone viewing option which shows boundaries of zones, including strange horizontal lines (see for example here and here).

That view mode is now behind advanced config and we have one button less in the left hand toolbar by default.


I don’t remember if these two features have been introduced: Board Characteristics and Stackup Table which can be added to a pcbnew layer. They are both groups of items, populated with information gathered from the board. Stackup Table naturally needs the physical stackup in the Board Setup. Add these from Place menu.


We are still waiting for two major features, the new python API and the Content Manager. The latter can be tested if you can use git and compile KiCad yourself, see

Despite the latest “we are almost there” update about the python API we haven’t heard about it ever since. Well, the last 10% is always the most difficult… But in any case it looks like the more pessimistic estimates about the release schedule were correct. There’s still hope to get v6 this year, but honestly, those two features are both pretty large and need testing, so it’s probably not only about integrating them to the master codebase and fixing some small bugs, although they should be independent from the rest of KiCad and therefore not cause headaches for those who don’t use them.

Otherwise the state of 5.99 looks relatively good to me. Judging by the posts in the forum 5.99 is pretty popular already amongst courageous users. Please join them, test and report bugs.


Speaking of which, the button in the 3D Viewer’s color settings to copy in the Board Stackup colors was pretty kludgy, so it’s been replaced with a radio button to just use the stackup colors.

It has now been merged to master. At the moment it’s behind a config flag because it’s not fully featured yet, so if you compile, run cmake first and enable KICAD_PCM. You will also see KICAD6_3RD_PARTY environment variable in the Configure Paths dialog, the packages which can now be tested will be installed there. The footprint library must be added to a library table manually. As was said, it’s not ready yet for full user experience.

Discussion should go to the dedicated thread.

Gerbview has now XOR viewing mode a.k.a. differential mode or compare mode. Overlapping colors are blended using certain algorithm, so difference between two layers is easy to see. Screenshots can be found in the merge request.

Notice that this is only for gerbview, not for pcbnew. The latter once had the old legacy toolset/display engine which showed colors XORed and some users have wanted it back, but with other enhancements, for example more detailed settings for transparency, it shouldn’t be necessary for productive work.

EDIT: this isn’t really a new feature, it existed in v5, but was removed probably when the legacy canvas was removed (correct me if I’m wrong). The implementation in 5.99 is different.


Important: Update to 5.99 modifier keys