I renamed this wiki page to “KiCad Future Versions Roadmap” to be more clear about the purpose:
Right now, the development team is focusing hard on V6 and being honest about what is possible to do in a reasonable timetable. We moved some features from the old V6 roadmap (which honestly was just a collection of every single feature request and improvement that we thought about implementing since before V5), because either there was no developer working on that feature, or because it was seen as too early on to have a good implementation in a reasonable amount of time.
So, it is not that we already know what V7 will look like, but rather that we are making a guess as to what things we can get done with our current resources and a reasonable timeline, keeping in mind that once we hit a feature freeze, our time will be taken up for months by handling bug reports rather than working on new features.
It can always change: we might get new developers contributing, or current developers able to spend more time, etc. I personally think if we are able to release KiCad more often (there will likely be well over 2 years between 5.0 and 6.0!), everyone will be happier, even if each release contains fewer “huge” new features.
One mistake from the roadmaps I made yesterday: due to a miscommunication, the Eeschema Python API was moved off of V6, but actually it is still targeted to V6.
That can actually be a good news, as it makes the V6 a bit more tangible?
Nothing could be worse than an infinite feature+request list for something that would definitely be nothing more than just vaporware.
Little steps, persistence - key to success for such projects
This is very good, I have needed something like this. Especially when I use a project specific library with the default name (<project_name>.pretty) and it gets lost between all standard libraries, in different place in every project.
It’s simple to use as can be seen in the video. Jeff can find a nice bug there, too.
Jon Evans sent an important message about a big change which may affect nightly build users now and will effect everyone in 6.0. The settings backend system has been changed.
Initial code was merged to support rounded traces. It has to be noted that only the datamodel seems to be implemented at the moment, so the only way to generate them is the current dev-version of my native Altium importer:
Looks wonderfull.
For this test case the use of curved tracks is more easthtetic than usefull.
Some time ago however II tried to help to find a practical workaround for KiCad’s lack of circular tracks on a pretty simple board which is almost impossible to route without rounded tracks, and for any doubters about the usefullness of this feature I’d like to drop a link to that project:
You can now launch a bug report from the About window, and it will automatically include your KiCad version info. See the new buttons in the top right:
(Please continue to follow the other instructions in the bug report template: first search the issue tracker to see if your problem has already been reported, and if not, fill out the other requested information in the bug description)
Seeing as it seems v6 will have something like a stackup planner will that also mean that things like per layer length tuning and node-node resistance measurement might be a thing. Or no real interest?
You can now place multiple color theme files in the colors folder inside your user settings folder (there’s a handy button to open that folder, too). You can get these theme files from something like Thomas’ repo, which has been updated to include JSON versions of the themes that are compatible with the latest nightlies, or you can create your own!
The color theme editor lets you create new themes inside KiCad. You can copy/paste colors between slots (just right-click a color button), reset one or all colors to KiCad default values, and see a live preview of your changes right inside the preferences window.
There will always be a theme called “User” that reflects whatever your existing color settings were before this feature was released.
Note: the live preview currently doesn’t show all types of items. I wanted to get this out for people to play with at this point, even though it’s not completely finished.
Along with this comes some other related new features:
LibEdit can now optionally use a different color theme than Eeschema (configure this in LibEdit preferences)
Plotting in Eeschema can now use a different color theme than the main window, and you can plot background colors to PDF, SVG, and PS files. Configure this in the Plot Schematic dialog:
Please report bugs if you find them! I’ll be expanding this to support the other applications soon, but it should already be working well enough to use on the schematic side.
For “per layer length tunning” you could modify my Length stats action plugin to report length of tracks on each layer. It is not exactly what you want, but it is something.
As for the “node-node resistance measurement” use pad2pad distance action plugin. It also reports cumulative resistance assuming 35um layer stackup excluding via resistance. Note that it calculates distance/resistance on tracks only. If you have a zone somewhere this is not taken into account.
This doesn’t work perfectly yet, there are problems with checkboxes and visibility. But the crashes which happened with the first iteration have been fixed.
I believe the issues with the checkboxes and visibility (on MSW) were recently fixed. So if anyone is still getting them with a current nightly please let me know (or log a bug).
More hotkey definitions available for the 3D viewer. Shared commands (such as zoom in, zoom out) also now respect the hotkeys set for the rest of the suite.
