So I’m really sorry that you made this decision. I already switched to 8.99 halfway through the year and this change surprised me at the end of September. I thought it would eventually be incorporated into the final version with some choice. Now I’m frustrated. I don’t know what I’m going to do.
Unusual pad stacks are pretty common in industry, due to the use of flexible PCBs. I first came across small PCBs bonded to the kapton flexi in the mid 80s, so 40 years ago.
I’m not describing here that unusual pad stacks are not used or that PCB Layout should not support them. I’m describing here how these unusual pad stacks are displayed in PCB Layout.
I didn’t know this.
If you want this feature, it is best for you to make a “Feature Request” on Gitlab. Others may upvote your request and the Devs may include this feature some time in the future.
OK, thanks. I’ll try to bring this more to the attention of the development team.
I think the original color display should be kept and users can switch and choose the new color display method
1 Like
I’ve made similar arguments myself in the past with other software products, but I’ve mostly changed my mind now. The downside of this approach is that you end up with more and more user-selectable options which, a few years down the line, nobody can quite remember why they’re there, almost nobody cares, and which just add to a mountain of miscellaneous settings which people - especially new users - have to navigate. Plus, of course, it’s another source of code bloat.
Sometimes it’s better just to bite the bullet and make a breaking change, or deprecate a now-redundant feature.
9 Likes
I would say … give it a chance. The one thing I hate is changes for change sake but this one appears to have some rationalisation behind it - assist in HDI where key information is lost.
Can it be improved? probably. Does it need improving? maybe.
It being different, it not being the same as $other_eCAD doesn’t mean it is wrong or it won’t work and there have been other key UI changes (eg icons) that have garnished emotional responses simply because it is visually different from what was there before BUT people got use to the change.
So … give it a try, if it really is causing actual issues then a constructive issue on why (and how to improve) stands a chance of being implemented, as long as it is objective and not subjective (its changed doesn’t count).
and as always, there is an XKCD for this 
2 Likes
We’re open to considering changes to the behavior and might try some out to see if there is agreement with the development team that something else would be better. We are unlikely to make it an option to select between multiple different modes, for the reasons SteveT mentions.
Right now the major complaint I’m hearing is “it’s different from Altium”. It would be nice to articulate what the actual issue is with it being different from Altium (other than just having to learn two tools), because KiCad’s goal is not to just match the UI of another CAD tool in all ways.
6 Likes
I believe it’s best to leave it in place for now like other software firms this do with api changes, allowing everyone to continue working on their projects while benefiting from the new features. Then mark it as to be deprecated in V9, giving users time to adapt, and plan and tell for its removal in V10.
Simple, clear, oversee able and acceptable.
The answer is simple: Altium is a widely used program that sets certain standards among ECAD programs - whether we like it or not, besides, the way vias are displayed is logical - the same size - common color (yellow in kicad), other sizes - layer color - what is wrong with it that you couldn’t implement it? I have noticed a tendency in open source programs to introduce changes “in their own way” without looking at external, commercial solutions. Whether this is right is a topic for another discussion 
2 Likes
There is also the converse of the Altium “standard”. Do users require an indicator to independently show pads and vias with the same size on every layer? Is this just Altium bloatware?
Most KiCad users are not coming from Altium. I can see how having different colour via pads depending on varying size or not confusing users. It’s all about what you are used to.
I wonder what Orcad and Mentor do. Altium is not the only commercial EDA.
I understand your point of view - it’s like this - if I’m going to design a car - why is the gas pedal on the right? Because that’s how it is in other cars? Screw it! I’ll do it on the left!
Just a joke. I know that Altium is not the only commercial program, I also know that probably all Kicad developers took it as an honor to do everything differently than commercial programs do, but from experience I know that if you’ve worked on some software for many years (and different ones) but each of them was generally similar, it’s hard to suddenly see red vias because someone makes multilayer boards and each of their vias has to have a different color!.
Ok, let them have it, but let me have a choice and let me set the vias of the same size (double-sided board) in yellow, what’s the problem?
It’s enough to give a choice - after all, that’s what open source is supposed to be different from commercial - the user has a choice. Unless we understand it differently - you can use Kicad or not - then it’s different.
1 Like
the answer is usually this: use version 8) in the end, those who need it now and not in a year or two will use what most people use. And this is a bundle of Altium and Windows. 9 can only be fully used after 6-8 months, as was the case with other versions, and all the errors in 8 will remain in it from the transitions to V9
I’ll do that, I have no choice - I can load projects from kicad into the company’s altium, but that’s what kicad is for, so I don’t have to use the company’s software at home
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.
3 Likes
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.
1 Like
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.
1 Like
I also strongly agree. The current color of solder pads and vias makes me feel uncomfortable.