Post-v5 new features and development news

If you pull KiCad code from gitlab you may have received some needless large files recently. See these developer mailing list threads:

Rebase the tree?
GitHub Mirror not updating?

They are likely to be removed from the git history soon which may lead to some complications if people have pulled them. Update your own repos as needed. Especially if you have a public fork. (Again, I’m not so good with git, so don’t ask me for help.)

EDIT: the situation has been resolved (see the Rebase the tree? thread above), the git history has been altered. Simon Richter gave some instructions in case someone has problems: https://lists.launchpad.net/kicad-developers/msg43298.html. The gitlab repo will reject accidental large files in the future to prevent this happening again.

Footprints can have keepout areas.

7 Likes

The v6 roadmap hasn’t been updated for a while, but Craftyjon made a merge request for that purpose.

(The proposed changed roadmap can be found by navigating to his branch and to Documentation/development/road-map-r6.md.)

As you can see in the discussion there, the roadmap may later be moved to some new location with the hope that it would be more frequently updated.

Anyone who’s interested in the future plans should take a look at the epics, too:

Maybe even one of your bugreports is part of an epic. :slight_smile:

It’s now possible to do back-annotation from pcb -> schematic

10 Likes

(It’s not in the nightly build yet, missed it by one commit. Will be there tomorrow. I’ll give a screenshot later.)

EDIT: Available now.

image

As you can see, it’s quite simple. Just try changing a footprint’s value or reference designator or use “Change Footprint” function and run this dialog from Tools.

6 Likes

The v6 roadmap has been moved to the project’s wiki.

1 Like

5 posts were split to a new topic: Is rigid flex suport not part of version 6 roadmap?

From the new roadmap wiki page you can navigate also to the new v7 roadmap. Everyone is disappointed seeing their favorite feature having been silently moved from v6 to v7 (I was waiting for example teardrops). Let’s hope there’s a good side: v6.0 will be out sooner because there’s less to do.

One point in the V6 roadmap is native net-ties. This will allow be to make RF structures like directional couplers without a page full of DRC errors

1 Like

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.

7 Likes

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 :slight_smile:

1 Like

Pinned libraries in the Footprint Editor and Symbol Editor. (Pinned state stored by project.)

4 Likes

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:

10 Likes

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:

1 Like

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)

6 Likes

To add what Jon said - it opens a new issue page in gitlab. You still need a gitlab account.

A long awaited feature was integrated: We can grab footprints now:

18 Likes

It’s no real Push’n’Shove at the moment, but a good start anyways. There are some serious bugs to solve (I’m going to report something soon).