Check Preferences / Preferences / Pcbnew / Dislpay options / Annotations / Net names (taken from the current nightly - YMMV).
As long as I can remember they have been on by default.
OK, I didnât quite understand what you meant about the legacy canvas. Now I understand that it did âmixingâ versus just stacking the layers like it does now. The new display model doesnât do any mixing and just stacks the layers in the order as shown in the Layer Management window.
The shots I was getting was showing all of the layers which was, as you say, mixed together and showed up very nicely. Thatâs no longer available with the clarity of the old legacy canvas. It looks like setting F.Cu transparency to 80% - 50% is what comes closest to that old shot.
Yes, I know about selecting active layer. Iâve tried all combinations of selecting active layer and playing with opacity of each layer. None of that completely gets back to the old 4.0 layout shots. (Iâve even tried a lot of combinations of the âPrintâ option and I donât seem to find a solution there.) Again, the F.Cu opacity solution comes closest to being able to get a reasonably good Layout shot that does all Layers like the old legacy canvas mixing did.
Oh, I see. The problem is I need to go full screen on the window and zoom in a little more than before and then the Net names showed up.
Thanks.
If you want all layers, both top and bottom, at the same time, it really seems to be impossible. If youâre happy with one side copper and silk there are several nice ways.
You cannot get what you want with movable stacking order, so itâs not useful to ask that from the developers.
OK. I see what you mean about movable stacking order.
I does look like a combo of 50% opacity of the F.Cu layer and then select F.SilkS as the active layer gets me back to a nice shot that works. Hereâs what that looks like and Iâm happy with it.
Thanks.
The thing is, I am not sure youâve used Legacy toolset for your 4.0.7 screenshots. To me it looks like the Modern toolset in 4.0.7.
Iâm preetty sure my boards look have changed between 4.0.7 and the 5.0.2 (in both cases Modern toolkit), but did not investiaged it. Out of curiosity I will install 4.0.7 on spare machine just to compare board looks between 4.0.7 and 5.0.2
Now (5.0.2) the display order is: current selected layer displayed on top, then remaining layers are displayed in the order they do appear in Layers manager pallette, keeping their Opacity setting.
Silkscreen and âdescriptiveâ layers (courtyards, etc.) are buried below all physical layers.
The âside effectâ is that e.g. board drawings are covered by copper layers, and you need to select copper layer to route a track. In this case, unless you use Transparency, it is not possible to see the board drawing while Routing (I do heavily use copper pours, so my boards are mostly copper with thin spacing lines around the tracks).
Maybe it would be beneficial for some users to manually define and change displayed layer order (just like some graphical programs do). This way anyone could adjust it for own taste/workflow.
EDIT: just installed 4.0.7 on a spare machine. I can confirm now that the Layer order (Modern tookit) in 4.0.7 is different compared to 5.0.2 that the Drawings layer is displayed on Top in 4.0.7, and in âlayer oderâ in 5.0.2. Of course Drawings can be brought to front when selecting in 5.0.2, but it canât be on top while routing tracks.
I noticed an interesting detail in pre-5.1. When I select a bottom layer (silk, pasteâŚ) all bottom layers are raised on top of top layers.
I remember this being the case in v4 (open-gl) as well.
In v4 inner layers are treated strangely here. front silk stays on top of them no matter which outer copper layer is active.
The described behavior is also true for 5.0.2.
But here inner layers are on top of front silk if the back layer is active.
Things are even more complicated than I initially anticipated.
Just selecting Copper layers not only brings the selected layer on front, but also changes other layers order.
For my board:
Front selected: Front >F.Silk >F.CrtYd>Drawings>In1>In2>Back > B.Silk
In1.Cu selected: In1.Cu > Drawings > Front > F.Silk >In2> F.CrtYd>Back>B.Silk
In2.Cu selected: In2.Cu > Drawings > Front >F.Silk >In1> F.CrtYd>Back>B.Silk
Back selected: Back > B.Silk>Drawings>Front>F.Silk>In1>In2>F.CrtYd
(all this on 5.0.2)
selecting any copper layer brings the layers into focus that you most likely need if you work on that layer. Just a reminder: pcb_new is a program aimed to make designing of boards efficient it is not there to make pretty pictures of pcbs.
And thatâs exactly why itâs important to be able to define the stacking order.
E.g. I use drawings layer to keep mechanical compatibility, which is crucial information for components placement. Currently, unless using Transparency I canât see my mechanical constraints. In 4.0.7 (Modern toolkit) it was visible due to different stacking order (Iâm not refering to legacy XOR rendering).
Have you tried outline modes for zones and tracks? I use it all the time and it lets me see ALL enabled layers making layer stacking order moot point. But my workflow may be different than yours.
I turn off zones display to get to lower layers, but I donât really use Outlined mode for Zones. Sort of, does not give me the board feeling I need during my work. And outlined tracks, pretty hardcore to me. I use(d) it only to look for unwanted track breaks.
And all this is just a workaround for what was working for me pretty well in 4.0.7. Of course I can live with it, considering 5.0.2âs advantages but hey⌠shouldât the experience improve with each subsequent version?
My reasoning for the 4.0.7 display order was, the Drawings layer is an auxiliary layer that may be a helper for routing. If you need these guides, itâs better to have them visible rather than covered. If theyâre obscuring your view, itâs easy enough to hide the layer totally.
But if my point of view is wrong, and someoneâs experience is different, then itâs a proof different workflows have different needs and this stuff should be user-configurable.
I have notice that in the new 5.X versions and although I have make it work, it is true that having the drawings on tops can be very helpful when routing a a board. Think about it as having a piece of transparent paper on top of your board while working on it, if the argument is, that people do not want to have their view blocked by this drawing it can be always disabled, that is the way I was doing it also: Put piece of transparent paper on top (enabling the drawing layer), work on the feature, and then take the transparent paper away (disable the drawing layer) when finished. Transparency can indeed help but is is not the same.
In this thread we can see where persistent and polite dialog can go.
- We understand better how legacy and modern canvas layers work and what is the difference.
- The original poster knows that stacking order wouldnât help him.
- Some others have pointed out that different stacking order would still be useful.
As long as configurable stacking order wouldnât affect the current workflows it would be a good enhancement. So, if anyone has time and cares enough, why not report it to the bug database.
I seeing layer ordering not only for art / picture but it is useful for design. If stack just follow a top to bottom order. It would not be as good at this following weir order. It may be more useful if the order would be reversed from the middle copper layer outward compare to the real fabrications order. For example: T.Fab, B.Fab, T.Silk, B.Silk, Top Cu, Bot Cu, L1, L4, L2, L3 ⌠So that we can always see Fab, Silk event with filled copper layer. With addition mix of which current active layer are, but Fab, Silk still be on top if copper are active. It a complex logic, but I think again, the original designer did not pick this similar style out of blue. I think, this logic look ugly in the code base, but well work for user. So may be we need to create bug track, and start vote for it⌠Iâm not confident if I can pass the smell test for this bug report 
Before you have written this I didnât got what could be the source of misunderstanding (as I see cited sentence clearly differs from text I write).
I used quote to show something I am answering to, but if I wonted to show something I am speaking about, but not answering to I supposed that just copying could be good.
My decision now is ânever more copy, always quoteâ.
Iâm not sure what I am writeing now, but I suppose it is so, and I suppose you donât know it yet.
If Iâm wrong I believe someone who knows the right will correct me.
I understand that legacy (used probably from KiCad beginning) was some graphic engine used to display what KiCad wonts to display. That graphic engine gives some sort of possibilities and to display many layers the best way was to mix them and KiCad was doing it.
But some time ago (I donât know, may be at V4 introduction) someone decided to use different graphic engine. This new engine gives probably many âready to useâ features which helped among others to introduce the new interactive routing mehanisms which were probably not possible or very difficult to do with previous graphic engine. I donât understand what graphic has to internal program working, but I also donât understand why graphic cards are used to mine bitcoins and not the main processor. So I belive that may be a complicated tasks of modern interactive routing needs the graphic cards use and that new graphic enging may be gives access to use it effectively.
I suppose that makeing view as in legacy would need to use that old graphic engine. As KiCad is improved there is no idea to write all things twice (for old and new graphic). That would make progress two times slover. As possibilities of new interactive routing was the reason I start to be interested in KiCad I am 100% for deleting legacy and develop modern only.
Danger simplification!
Graphics cards are also just processors. But instead of having 4 cores you have hundreds of them. These hundreds of graphics cores are however more closely linked to each other than the 4 cores of your cpu are.
They are optimized such that at least a lot of them do the exact same thing at each time instance. This is useful for graphics calculations as you have to do the same operation for each âpixelâ.
It is also useful for mining crypto currencies as the algorithms used there can also be highly parallelize able. (You would not really use it for bitcoin itself however. This is because there is specialized hardware out there that is focused on just bitcoin mining making graphics cards quite inefficient in comparison. It makes however sense for currencies where you do not compete against such specialized hardware or while the value of bitcoin is extremely high.)