Will the Backup exclude other ZIP files to prevent ever expanding ZIPs?
Yes. In fact, there is a fixed list of file extensions that will be backed up: https://gitlab.com/kicad/code/kicad/-/blob/master/common/project/project_archiver.cpp#L157
Will it be possible to display the net names on the schematic or just assign them? Could you automatically just apply labels as net names?
I’m not sure I’m following. Net names are already applied by labels.
Net class assignments are what’s new. Net classes are normally applied to more than one net name.
We’ve talked about how to visually indicate net classes on the schematic.
- The current way is to use the net class colors and line-styles. Negatives are that they might not work well for very large netclass sets; positives are that they appear in plots, print-outs, etc. and have historical precedent.
- We could also support annotations (like the net names shown in PCBNew). Positives are that they’re easy to turn on/off en masse; negatives are that they won’t appear in plots, print-outs, etc.).
- We could have a mechanism similar to labels. Positives are that their placement, orientation, etc. is under the control of the author; negatives are that they’re harder to edit en masse and they can be visually noisy.
I’d love it if we could get by with just (1), with a slight preference for (1) + (2) if we can’t. I think Jon has a preference for (1) + (3).
It’s now possible to create a new net in pcbnew with Inspect -> Net Inspector. It can then be assigned to a pad in the pad properties. The change can also be fed back to the schematic with Tools -> Update Schematic from PCB (with more or less success).
This is an answer to long standing need for easier PCB-only design (WireIt plugin has been used for it).
Again, I opened a new thread for discussion: Creating nets in Pcbnew (5.99).
Note: this is my interpretation and doesn’t necessarily reflect the development team’s intentions accurately, so take this with grain of salt.
Until very recently many issues in gitlab had the milestone for v6 even though it wasn’t certain if someone would implement them. Now there’s milestone 7.0 and some issues were moved to that: https://gitlab.com/kicad/code/kicad/-/issues?milestone_title=7.0.
There are now three feature development milestones: 6.0.0-rc1 , 6.0 Feature Freeze and 7.0.
6.0 Feature Freeze is for new (major?) features. For each proposed feature it must be decided if it actually will be implemented for 6.0, and now it seems to be the time to make those decisions. If nobody hasn’t volunteered to implement a feature, it won’t be in a condition to be included when the feature freeze moment comes, and it can’t be set to that milestone.
The rc milestone is mainly for bugfixes and other smaller changes. They must of course be ready when 6.0 is finally released.
I see 7.0 as preliminary in nature; ATM it includes only old feature plans which were postponed because of lack of manpower. They can be postponed even further, or maybe there will be 6.1 where something can be implemented.
6.0 Feature Freeze and 7.0 should correspond roughly with KiCad 6.0 Roadmap and KiCad Future Versions Roadmap but I haven’t checked how up to date those are right now.
This is essentially accurate. Our plan is to announce the feature freeze in September and move on to polishing the features and fixing bugs.
This is also why the rc1 burn down chart doesn’t look good but the FF chart looks promising.
We’re pushing other ideas to the 7.0 milestone as a convenient place to store them. Once 6.0 is released, we hope to sit down (maybe at FOSDEM if it happens) and hash out plans for 7.0 features.
There’s discussion going on about dropping support for 32 bit Windows because the build system is dropping it: https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg38718.html. No decision yet, but better be prepared because it will eventually happen some day.
KiCad source code has new build dependencies, see the announcement by Ian: https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg38729.html. If you build from source and it complains about something missing, try these (lemon; GTK3 on Linux).
EDIT: Thanks, marekr – it’s not in yet, it’s being tested first.
EDIT later: the plan was changed, no need to install lemon, see https://gitlab.com/kicad/code/kicad/-/merge_requests/318#note_389955494.
It hasn’t been added yet
Geographic reannotation, i.e. reannotating based on the component positions on the board.
Tools -> Reannotate PCB
EDIT: separate post here: Geographic Reannotation Now Included in PCBNew
Hatched zones now get aprons around connected pads and vias.
There’s a new UI for managing the appearance of layers and objects in PcbNew.
Featuring:
- Layer view presets
- Per-type opacity for tracks, vias, pads, zones
- Net and netclass color and visibility controls
If you use a color scheme where you set your copper layers to have less than 100% opacity, I highly recommend you try setting copper back to 100% and use the opacity controls per object type. I personally think it’s a lot easier to see when tracks are fully opaque and other items are translucent.
Demo of per-type opacity:
Demo of net and netclass colors:
There’s a lot of new stuff here, so please report bugs!
…but not here.
General discussion about the features should have their own threads, and Net classes in Eeschema (5.99) and New Net Tools in pcbnew 5.99 are fitting for the net system related discussion.
I liked the “eye” icon instead the checkbox for layer hive/visible (like AutoCad, Inkcape, …) and the new opacity control! Just two observations:
- It not good to see in a dark them (if possible, will be nice use the same text or checkbox color);
- Footprint editor software could use the same interface;
- After this update, this “lateral toolbox” doesn’t save it own width in case of Pcbnew close-reopen. It always open like this (in Nets tab and with small width):
Hello all, it was merged this new feature I developed for 3D-Viewer: light parameterization …with some improvements in the rendering:
Beautiful, marketing will love this