Anyone willing to share the knowlede on upcoming key new features for the planned release?
I know EESCHEMA went massive rework, but I’m not sure what are the supposed benefits. I’ve heard about new s-expression based fileformat for EESCHEMA.
PCBNew shall support curved tracks (but only for import?), curved ratsnests.
Cleanups, fixes and small tweaks do not count here
I’d just like to know what cool features can an “average EE Joe” expect from the upgrade. Out of pure curiosity
One of the benefits (as I understand) is integration of the used schematic symbols into the schematic file itself, so no more need for the separate -cache and -resque files. More separation of the schematic form the KiCad libraries also frees the road to better organisation for the Library structure, but that’s going to take a few years.
Have you read the 153 posts on:
The problem with your question is there are hundreds, maybe thousands of small changes, and nobody but you knows what the important changes for you are. I’m happy with waiting for all the good things to come and embrace them when they are here.
You could take an hour or so to read the long tread above, read the roadmap for KiCad V6 and go through the solved issues on github.
You may think an hour is long, but it really is not.
The only difference is that with asking you offload the burden to the forum. Threads gets read hundreds of times, which easily accumulates to 10’s of hours of reading time for each thread.
Frankly, I don’t believe that it’s possible to draw any conclusions yet. You can follow the development of new features in the dedicated thread about post-v5 development (it was just updated). But there will be more and the features will change, so it’s difficult to introduce “key features” yet. It’s easier to do when the feature freeze comes.
The benefits of the new file format is invisibe, if we are talking only about changing from one format to another. It’s more important to the developers. New features in the file format are coming soon.
We’ll tell you when V6 hits feature freeze!
Well it was not my intention to ride on other’s back. I’m following the “development news” thread, but TBH could not isolate “big things” easily.
Now it makes me think V6 is not so much about new features, but rather a massive foundation update (EESCHEMA mainly). I couldn’t find an info on killer features as the Interactive router introduced in V4 or the Simulation from V5, and to verify if I’m missing something in my “v6 understanding” was generally the goal of my question.
To me and to what I know, “Object inspector” (i.e. the ability to see object’s properties without opening dedicated properties window) will probably be the most sought-after feature (I like this way of objects manipulation in other tools). But recently it turned out that even if it was demoed back in 2018, it’s still not included in the nightly builds (probably not mature enough, so rather not priority development).
Features that seem small to some are very important to others.
Take for example arc track segments.
About a year ago I tried to find some workaround to get this board routed:
The Altium Importer seems to be a pretty big thing, but I won’t dare to guarantee it will be in V6.
For some people a “modern and intuitive” GUI seems to be important, which probably consists of many different fixes. I think that "editable menu button bars has not made it for V6 and has been postponed.
For me the new file format is a pretty big thing, even thoug eelik wrote:
Just getting rid of the -cache and -reque file hacks make schematics a lot more robust, and gives users more confidence in KiCad. A common error is deleting the -cache file, because “KiCad can apparently regenerate it”. and then, when they fetch an old backup from KiCad V4 the schematic is horribly broken. There have been plenty question on this forum with the square boxes with question marks in the schematic. That should never happen anymore with the new file format.
Also related to files:
Hildo Guillardi Júnior is working on an option to use a compressed file format in KiCad. I do not care much for the compression itself, but having a whole KiCad project in a single file makes managing project much easier. Especially for backups and portability. It also reduces user error of forgetting to copy a file etc. More about this on:
The Roadmap for KiCad V6 has some overview of features likely to be included in V6, but a quick search did not reveal it’s location. Id did bring up another relevant question:
When will Version 6 be Released?
WIP means “Work in progress, don’t merge in yet”. I have compiled and tested it a bit.
For sure proper import filters for popular EDA packages (Altium, Eagle) will be a benefit for many users.
Nice GUI is indeed nice, and the improved GUI itself could be the reason for “big update”. Object inspector would be one of these “nice to haves” for me, as well as proper dark theme for Windows and dockable tool panels (e.g. Visual Studio style).
But TBH I did not found any up-to-date info which of these are actually planned to go into V6, even no info on what changes to the GUI are to be implemented.
And as the V6 already consumed plenty man-hours, I assume that there’s lot of great work done under the surface, not visible to average user (like changes to the interenal object structures etc).
I don’t dare to compile KiCad myself…
There is quite a lot of info here about features that are being worked on;
Some of the sub-streams are more detailed than others - but if you have specific area of interest e.g. net-ties, you might be able to see what the future holds
Many of the “killer features” that are desired are very hard to implement without such foundation updates, so you will see those updates happening first.
I’m fully aware that the foundations are crucial for further development, and that bad foundations lead to crappy products. So my intention was not to diminish its importance, but rather just to get an opinion.
By the way, while this may easily happen in an open source, engineers-driven project, for commercially (marketing people) driven projects it’s not possible to put a new product without providing clear benefits/advantages to the end user. (and end users are typically not interested in the innards of the product).
Sure, and highlighting key improvements is important for open-source projects as well. The thing is, we are not close to releasing V6, so we haven’t started to do that. Once we are close enough to say that no more new features will be added is the right time to start compiling lists of new features. You can try to do that before (see the other forum thread) but things might change, so it doesn’t seem worth it to make a very polished “look at what’s new list” yet.
I’m not the authority on what will happen with KiCad, I’m just one developer. But what I suspect is that at some point, it will start looking more clear where is a reasonable line to draw and say “this set of features can be a good 6.0” and “this other set of features can be pushed off to 7.0” or something like that. We aren’t at that point yet, though. It’s a balance between providing a good release that addresses as many shortcomings as possible in KiCad 5, but also doesn’t take forever to finish. Commercial companies have to do this too, but they usually have the benefit of more predictable developer availability so it makes planning easier.
Well, that’s a bit scary. I was under the impression that the feature list is already set in stone, and now it’s the implementation phase. Of course, adjustments are unavoidable, but the goal should be well defined and achievable. Otherwise, that’s a path to disaster https://en.wikipedia.org/wiki/Feature_creep which could potentially cause the V6 to become a vaporware.
Oh, we are very familiar with the issue
The opposite case is more likely: we may decide that it has been long enough and we can no longer wait for a certain feature to be done, and it has to be bumped to V7.
Our goals are fairly well-defined, what is not as well-defined is how much time our (mostly volunteer) developers will be able to put in.
You are right, that thread is difficult to follow. But given that things will change anyways, if we would give the highlights in this current thread, changes would come, things should be added and changed, and this thread would soon be difficult to follow, too. That’s why I’m reluctant to give anything right now - not because this wouldn’t be interesting or a good question.
Provided that I will follow the development process closely in the future (I can’t promise), I probably will try to give this a shot even before the feature freeze, when we can know with at least some certainty what will actually be in v6.
One more way to find some important changes is to find in the issue database the issues which are milestoned to v6 and sort them by either Weight or Popularity. (Popularity is “thumbs up”, weight is based at least partly on some report properties in the old launchpad database.) That may give you some view on what people have deemed as important to them. Notice that not all which have this milestone will be implemented. If there’s “assigned to” for an open issue it’s safer to expect it to be implemented.
https://gitlab.com/kicad/code/kicad/-/issues?scope=all&utf8=✓&state=all&milestone_title=6.0.0-rc1
The last blog post regarding the settings save location indicates:
With this change, settings are now stored in
%APPDATA%\<version>\
Wouldn’t it be more like
%APPDATA%\kicad\<version>\
???
Depends on what the variable contains. May be something like kicad-5-1-6-abcdef.