The main usefulness of buses always was for using them to connect over hierarchical interfaces. The old bus could have a bus pin of the form bus[0…9] Which meant that single pin represented a parallel bus with indexes 0,1,…,9. As far as i understand it the new bus can define more powerful buses (for example a SPI with signal names CS, CLK, MISO, MOSI)
If you did not go over a hierarchical interface then buses in the past where simply graphical lines that showed users connections between local labels in a clearer way.
The new bus features will also add power to this usecase. (proper bus entry and exit via the alias and unfolding stuff)
I do not know if buses can now also go via global labels. (Nor do i know if this was possible in the past.)
If you look at your linked document then the vector bus is what has been available in previous versions. The group bus is what is new. (With all the tools needed to properly handle such a bus. Meaning bus unfolding and bus alias handling are also new.)
Another new thing is connecting two buses with each other. I am not sure how much got into this implementation (I think this was one of the topics that created problems during the implementation phase. Might be that there where feature reductions here. I don’t really see a detailed explanation in the document so it really might be something that got removed.)
(Right now it’s available only in the left hand toolbar and in a strange location. IMO it should be near the Show/Hide Board Ratsnest, and it’s called “airwires”. Also I suppose it will be available in the View menu in the future.)
I dropped this feature and will clarify this in the docs once the dust settles on all the bug fixing.
In addition to adding new bus features (like bus groups and unfolding) the entire connectivity/netlisting system got overhauled, which means some other neat things are coming soon
As part of that overhaul, I needed to clarify some of the “rules” for how net names are assigned and how they propagate / override each other when you use global/local labels, hierarchical sheets, etc.
The docs for this aren’t done yet but it’s on my todo list. I think the end result will be a more predictable behavior although in a few cases it will be different from what KiCad used to do.
Jeff called for testers for his eeschema branch which moved eeschema functionality to the modern toolset. Now the fruits of your testing are in the master branch and in the nightly builds.
(A side note: 5.1 already used the modern canvas. Terminology has been mixed because pcbnew had new canvas and new toolset at the same time, so sometimes the modern toolset was referred to as OpenGL/Cairo canvas or toolset. Actually canvas refers only to drawing graphics in computer parlance, like a painter painting a painting to a canvas )
Here’s how Jeff describes it:
It’s the modern toolset for eeschema.
If you remember the difference between PCBNew’s modern and legacy canvas, it’s the same for eeschema. The modern toolset supports selection states and operates on more of a noun-verb pattern.
Functionality should be mostly equivalent, although the new toolset does allow easy incorporation of a few features which were detailed earlier in this thread.
There’s already one huge difference. Now you can actually select something, e.g. a symbol or a wire, by clicking on it. I think this is part of what “selection states” and “noun-verb pattern” mean in practice.
There’s also one not so visible but very concrete feature which was long waited for: you can open a schematic, copy there and paste it to another window. Earlier it was possible only to append a whole file or use a text editor if you wanted to reuse something from another project.
Study ergonomics of various commercial/proprietary PCB applications (when in doubt about any particular UI solution, check how it has been done in a certain proprietary app that is very popular among OSHW folks and do exactly opposite).
Selection model in LibEdit.
Handle-based editing for graphic items in LibEdit.
Handle-based editing for hierarchical sheets in Eeschema.
Handle-based editing for comment lines in Eeschema.
System clipboard for cut/copy/paste in LibEdit.
Auto addition of wires when dragging directly-connected symbols in Eeschema.
There’s a bug logged for junctions (also whether or not to add a junction when you decrease the wire to zero-length so that you now have directly-connected symbols).
The consensus seems to be to go ahead and add the junction (even though it’s not strictly needed) if there are more than 2 connections. We might apply the same when determining whether to drag a junction or insert a wire.
Sorry to hijack this thread, but for some reason, the nightly builds (v5.1 and v6 branches) of last night are missing. I guess an issue occurred and it is a temporary glitch, but where / who to report this to ?