Before this degenerates into ever more “tch, how hard can it be to just add an option” comments (answer: hard enough, and it has to be tested and maintained, and gets in the way of other things in the same area, it’s not free, even if everyone thinks it’s a great idea) here are some suggestions for how to structure an argument for why you think your favoured thing should be implemented. This goes for everything, not just via/pad colours and not just KiCad.
What is the information you would like to be surfaced in the UI (perhaps: all a via’s layers have the same shape)
Be specific - in this case, does that, or does that not, include when vias have smaller inner layer annular rings, for example, or is it just the outer layers? Is it the same for micro and buried vias? Why?
Why do you think it is particularly important to be surfaced to the user? And why right there, and not, say, in the status bar or properties panel or in some other way. What, specifically, about that information in that place makes KiCad more usable? If it is not there, what problems would it cause in practical use cases?
Now you will have established the what and why. Next:
How do you think this information should be presented to the user? For example in this case, “a specific, unique, distinctive fill colour” is one suggestion, but it’s not the only possible answer.
Should the information always be there, or should it be only in some modes or some circumstances? What are they and why?
Should it be an option? If it’s optional, it mustn’t be always important to everyone: what are the distinct use cases that separate users who use it and those who don’t? If it’s optional, is it likely any one user will use both modes from time to time, or will there be a disjoint set of “users” and “non-users”? Should there be a quick toggle?
Does your suggestion for how the information is shown over- or under-state the importance of the information? In this case, why is “the other layers are the same shape” so important that it both outweighs any other information that may be conveyed by fill colour and creates a dramatic difference between the rendering of a “normal” via and the rendering of a custom one?
Does your suggestion present information in a way that naturally suggests the meaning? For example the gold hole walls are suggestive, to me, of the meaning “plating here” in a way that, say, a polka-dot fill pattern on the pad area would not be.
Does your suggestion create the potential for incorrect inferences? For example, is it possible someone might see many gold vias and some non-gold vias on a board and assume the colouring means something else such as tenting? How will you ensure the meaning of the colour is clear to users?
Does your suggestion make the “normal” or “special” case more visually distinctive? Is that the right way around? Why?
If you can articulate these points, then you have clearly thought about it beyond the immediate visceral reaction and made a suggestion that is actively useful. Not everyone will agree on all your points, but your points will materially advance the topic.
Of course, not all design decisions in KiCad are made with such rigour (and god knows I have personally committed truly egregious sins against usability though carelessness and lack of ability whenever someone foolishly lets me near a compiler). Sometimes the UI tools we have to hand don’t support the ideal method - if it did, obviously we’d just make it all telepathic and be done with it. It’s quite likely the “way it’s always been” was an expedient method using the tools available at the time or the reasoning it was originally based on isn’t so solid 30+ years later (a.k.a. path dependence).
And the same goes for our commercial counterparts. In fact, speaking from experience, it’s often far, far, worse when you have sales putting the screws on. Just because it costs the customer $X,000 a license doesn’t mean it’s actually always thought through before shipping or gets things tidied up down the line even when the engineers are pinky-promised they’ll be allowed to, so following what they do is not self-evidently a better choice. Saying one particular commercial package does X holds very little water (not no water, but not a lot), especially if it’s not a universal convention. If you want to make an Argument from Expensive Means Better you should do a survey of various implementations and explain why your suggestion represents the best of them.
Sometimes it’s good to strip things back when the opportunity presents itself during a major refactor and take a moment to think things through. Especially for things that are really quite central to the presentation of board data to users.
It could be so simple from a user perspective: Display the color style for individual PTH pads and vias by type.
Same size and shape (all in alignment) - one light color (like version 7)
Different size or shape - current state
I don’t know how others see it, but for example there is no DRC on the placement of GND vias and their placement is purely at the discretion of the designer. The current state of the via is displayed absolutely “invisibly” when looking at the entire board. I have no control over the placement.
The main reason why I liked the golden colors of THT pads in V8 is because it made it obvious which pads go to multiple layers (and can be used as a pseudo-via) and which are SMD only. I feel like only the black/golden circle for the hole is much less obvious at a glance.
That’s my only complaint, otherwise I’m sure I’ll be fine even with the colors like they are in the current RC.
Well well well, Cadence Allegro which is probably more of a standard than Altium renders vias in a different way…
As for adopting certain standards among the ECAD programs, which ones we should consider adopting first?
subscription-only licensing
online-only operation
cloud-only storage
dropping support for Linux/OSX (“because it’s professional software, everybody using it can afford Windows”)
rewriting KiCad in Delphi, adding some more technical debt, and if this doesn’t suffice, putting artificial slowdowns here and there?
PS. Personally I probably like the old way of rendering vias a bit more, but the difference between “the new” and “the old” isn’t as important to me to write 40 posts on the forum about it
I just checked mentor and they have an option for pth pads otherwise it is the layer colour
So what we have he is there isnt even a defacto standard in how to represent such a concept and thus we do not have a objective view of what is correct. We also do not know whether something was done due to other decisions.
Kicad shouldn’t imitate, it should do what is correct, correct from it’s implementation and/or correct way to represent such a concept especially if this is part of a wider custom padstack concept
I just want to point out that the OP just asked to keep the old kicad standard for the case with same size and shape.
Not asking to emulate any other cad even if this could be useful.
He also clearly stated the user case.
Initially I didn’t want to comment on this topic, but here are my opinion about the changed display style:
I liked the older display version more, and I’m still not accomodated to the new style (working since 2 months with v8.99)
Observing myself during footprint placing and routing I think I have used the old via/THT-holes for optical orientation on the board. Now with the complete board having the same color some orientation is lost.
in retrospect the introduction of this change was maybe a little unfortunate. It seems every change on display/GUI has the potential for long discussions. I remember long threads about the new kicad v6 icons…
regarding making the display style configurable with an checkbox/option: in general I second john beard (restricting the number of options), but if a decision really splits the userbase then that might be the right place for a preferences setting.
For home or as they say personal use it does not matter as well as buying software for this reason 70 percent use win and there you can use everything together fully. If you want buy it, you want the cloud, you want without the cloud, you have a choice. With organizations, with rare exceptions, the picture is completely different there and the cloud is relevant and the internal server
The sarcasm you included in your response is not substantive. Secondly, if I don’t like something or have a different opinion, I write about it - that’s what the forum is for. You accept the new reality without any reaction and I respect that, but don’t measure others by yourself (I don’t know if I wrote that correctly - there’s a saying in my country).
I’ll just say that it is unfortunate that this change has been in the nightlies for months and nobody who apparently feels strongly about it filed an issue about it or anything until this week.
The change was discussed with the development team and at the time, everyone was in agreement that it made sense. It is a change from how KiCad used to work, but it means that (unlike Altium) the way vias and pads are rendered doesn’t change just because you decide to make some of them have different shapes on different layers. We feel like there is a good reason for things to be consistent (meaning, there is one way that a via is always rendered) rather than rendering a very similar via in two different ways just because one of them has its inner layer pads removed or something like that.
For those who are saying that vias are invisible now: Do you know about setting transparency for things like zones, and about customizing your color theme if you don’t like the default gold color for the via holes?
We welcome suggestions and will consider all of them, but those who just want the old way back seem to be missing the point that there are problems with the old way.
@Jonathan_Haas that’s certainly a valid use case that is worth thinking about. But it’s not quite the same as the suggestions upthread to use gold fill but only when the pads are the same size. The information you are looking for is more like “there’s a PTH barrel available here” and not “this is a via or THT pad and has the same pad sizes on each layer”.
“PTH here” is no longer very reliably conveyed by a gold fill: in cases like custom pads, you won’t see the gold fill, but you’ll still have a PTH, so, yes, it’s an incredibly strong signal when it’s there but it’s inconsistently applied and can’t be relied on at a glance.
Which is why I think it’s important to be sure that the right information is being highlighted. Personally, I do not see why “THT pads the same size” specifically is important information that should get the highest dedicated highlight we can give to a pad or via short of making it flash. If nothing else it makes it quite hard to explain when these two pads look so very different, and why pad 2 can be said to be visually more like an SMD pad than it does to pad 4, when actually it differs only in size of the copper oval:
I believe the wish to make pads with identical pad sizes golden is just a (nonsensical) attempt to somehow preserve the old behaviour and there’s not a serious benefit to know which pads use identical pad shapes and which don’t.
What could make sense to me is making PTH pads another colour (e.g. slightly lighter) than other copper items on the same layer, or to increase the optical weight of the thin golden circle that indicates the plated hole, e.g. by making the golden circle thicker and filling the hole (or even covering part of the pad) when zoomed out.
I haven’t worked enough with v9 to really form a solid opinion, though.
Thank you for your opinions and contributions, but they did not solve my problem.
The problem is finally solved by individual code modification in the form of a patch of multiple source files. (Thanks Jon) The display of PTH pads and vias now works the same as in AD. I asked for this because I also work in AD. (I have to because of my job). Now I can use the latest KiCad for my hobby again, because it is the best PCB design system in the world!!!
Ever since I started with kiCad there have been endless streams of “why isn’t this the same as Protel/Eagle/AD/Mentor…”:
All of these have a mountain of legacy cruft, making the codebase a mess and usage quirky
edit
Another thing to beware is that if KiCad deliberately copies some really quirky and non-intuitive UI feature, there is some risk of legal action by the commercial software owner.
