Post-v5 new features and development news

No prob. Thanks :grinning:

Jp charras is working on a board stack-up manager. It’s not in the master branch yet but should be quite soon. Here’s a screenshot or two (self-compiled on Linux with patch):

6 Likes

Paste Special lets you keep schematic annotations in copied symbols when pasting.

image

(@JeffYoung, the checkboxes should be changed to radiobuttons because they are exclusive.)

2 Likes

Will this also affect the 3D visualization and the File>>Export models?

Interesting.
A idea is add (this will be a checkbox) “fill with not used parts of multi-parts components”. What I want is be possible to place the same circuit but using the next A-B-C-D part of an IC (example a operational amplifier).
Also could be add <Ctrl>+<Shift>+v as default hotkey for this function.

Finally, this has been a glaring omission for a long time.
I have a 2mm board so I have to get notepad++ out on the pcb file

In v5.1.4 you can edit the thickness of the board in File->BoardSetup->Layers

2 Likes

I never noticed that setting before. Still limited when you have 4 layer or more.

1 Like

It’s available for Windows in https://kicad-downloads.s3.cern.ch/index.html?prefix=windows/testing/patched/, build #497.

EDIT: it has been committed to master branch and should be in the next nightly build.

Radio buttons have to encode all options, so there would need to be a third for “Clear annotations if there are any duplicates”.

In this case I think 2 checkboxes has a bit better SNR than 3 radio buttons.

1 Like

As was found out in another thread, KiCad has semi-supported bezier curves for some time in graphics layers. Now v5.99 can both edit and plot them (previously plotting footprints didn’t work).

KiCad can’t create bezier curves, but if you import them from another graphics format (i.e. DXF or SVG) you can edit them by dragging the points.

EDIT: the fix was taken into 5.1 branch, too. 5.1.5 will plot bezier curves, but there’s some bug left to be fixed for 5.1.6.

3 Likes

This isn’t a “new feature” but definitely “development news”. As many of you know, there has been discussion about moving KiCad development from Launchpad to Gitlab.

Maciej Suminski has done some work to see how to move the bug tracker. See https://lists.launchpad.net/kicad-developers/msg42502.html and follow the second link to see and test the features. At first sight it looks promising.

1 Like

Project Save As is in. It could use a lot of testing…

9 Likes

Save As was a top ten wanted feature, so this is great news.

(See https://bugs.launchpad.net/kicad/+bug/594051, it’s educating to read also to understand the KiCad project a bit better, if you haven’t familiarized yourself yet with how the wishlist and KiCad development work. You can also see why it can look simple but isn’t and needs a lot of testing.)

1 Like

Those who compile KiCad but don’t follow the developers mailing list actively must read this: https://lists.launchpad.net/kicad-developers/msg42941.html. Most of you already know that the project has been in the process of moving to gitlab, but now it’s happening for real.

This is already pinned: Symbol Library Editor Changes, but here it is again: as a first step towards new library file format the concept of alias has been removed and inheritance is used instead. Notice that this still works on top of the old file format, so it doesn’t have much features.

1 Like

I haven’t followed git commits closely for a while, so if you remember something important, please tell it to us all.

But I thought the status of the new gitlab project is worth reporting in this phase. The source code is here: https://gitlab.com/kicad/code/kicad.

The bug database is of course important for all of us. But check also the merge requests. There you can see possible future features which haven’t landed into the nightly builds or the master branch. (Not all of them ever will.) The lead development team can add their commits without merge requests, so it’s possible that most of the merge requests will come from less active or new developers. But I can see familiar names there.

image

Some highlights (not to say that others are less important) from the current merge requests:

  • Back annotation (propagate some changes from pcb to schematic) by Alexander Shuklin
  • Geographical annotation by Brian Piccioni which he announced in another thread
  • NEW: Altium board importer by Thomas Pointhuber

WIP means “Work In Progress”, not meant to be merged in yet but under development.

How to test the merge request features?

If you can compile KiCad from git source code you can compile and test the code in merge requests, too. Go to the merge request.


There are some instructions but I haven’t tested them. I have added a fork as a remote to my local KiCad git clone and created a local branch to track the remote branch which is the merge request. I’m not too good at git, so don’t ask me about the details.

11 Likes

Great overview, @eelik - thank you!

The lead devs will tend to use merge requests to track larger changes we are making, or changes that impact the UI/UX of KiCad (whereas smaller changes / bug fixes tend to go directly in without a MR).

If you are interested in testing merge requests, keep in mind that those marked as WIP might not even compile, or might have serious bugs that could cause data loss, etc, so proceed with caution.

4 Likes

More about this in @pointhi’s dedicated thread:

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.