Thank you very much man I really appreciate it, at the end I was having to many issues with 9, so I went back to 8.
Nice for you;
that doesn’t mean an option to choose between the two would make any issue for you.
Well, for me it would be an issue if
- a configuration dialog would be cluttered with such a setting,
- or if it would complicate the further development of KiCad.
A while ago, I maintained software with tons of settings - it was a PITA, and made clean development impossible. In other words, it made software quality worse.
That’s why I fully support the developers’ decision - not based on a gut feeling, but on professional grounds.
1 Like
It’s easy to support the developers decision if the decision is the same as the own liking.
While I accept the decision I will continue to critize it - within 4 month now I’m still not used to the visual change and need more concentration during pcb work. And if a change needs so much time to get accustomed to then the change was probably not the best in user experience (gui design).
And yes, I know the xkcd sketch “every change brakes someones workflow”.
1 Like
I agree.
All the other EDA’s I have used (from memory) had it the original way, and whilst there is a workaround it’s not as good as the original.
In the months I have been using V9 it’s been quite a thorn in my PCB design workflow. It’s simply not comfortable to use.
Can the Dev’s please incorporate a method to have this selectable.
Thanks,
Ian.
Adding a checkbox isn’t the primary issue. The issue is adding the logic quite deep down in the rendering code. That logic isn’t especially simple, which you can see by the fact in that 116 total posts deep between this thread and this one, there is as yet little coherent suggestion for how to reconcile the tension between “I want THT pads to be gold like before” and “padstacks exist now”.
The only suggestion so far has been “draw pads gold when all layers are the same shape”, which I think is a overly strong highlight in the UI for what is essentially a piece of trivia about a padstack. For example, in this image of a footprint where pin 4 has a different B.Cu pad size, why are the two pads drawn so differently on F.Cu when all that differentiates them is the shape on a different layer?
For actionable change, we are still missing:
- What information is actually desired to be highlighted (e.g. “any THT pad”, “any pad boundary”, “exposed, un-pasted copper” or “plated barrel exists here” or “all layers same shape” or something else) and why is it helpful to see that information in practice?
- How to show that information in a consistent and understandable way (for example, if the first answer is “any THT pad = gold”, what do do about padstacks)?
For example, using the gold colour as a proxy for “exposed, un-pasted copper”, has always been a tempting mental shortcut, but is actually misleading. Perhaps what is actually needed is a way to emphasise un-pasted outer-layer copper.
Or maybe people liked the way that the gold THT pads show clearly when the copper comes from the pad shape, and when from a track entering the pad. In that case, do we need a better way to show that transition for all pads, THT or not (or is it already covered by a small opacity adjustment)?
3 Likes
Amusing
just explain me which difference in adding an obscure settings which very little users will test 
it seems it easier in other tools
technical debt…
of course it is possible but decisions to factor the code can result in a new feature, a “trivial” feature causing a major rethink about decisions that were made months and sometime years ago.
do you
- hold the line with the present implementation
- bite the bullet and refactor
- do some bodge that will come back to bite you
the correct thing to do unfortunately is #1 leading to #2 once it is all understood so the best thing todo is answer @johnbeard queries so the impact can be assessed…
johnbeard,
Thanks for replying. Here’s what comes to mind trying to think about all the various related issues.
-
When routing a PCB that has a mix of TH and SMT footprints or pads for instance, the visual of the gold pad/hole allows the mind to already be thinking ahead in terms of “I can’t drop a via here and run my tracks under there coz that’s obviously a TH pad/hole”.
-
The large gold pad/hole allows the mind to think ahead such that “I’d like to route clear of that TH hole, it’s gonna be hand soldered rather than re-flowed SMD reflowed”.
-
It gives a better visual representation of the actual board with having to 3D view.
-
Having the pad/hole appear gold from both topside and bottomside views simplifies the visual representation of the layout by having much more commonality between them. The new appearance makes them quite different and often has the designer switching back and forth to verify “what is on the other side, is there anything…oh yes, that’s a TH pad/hole footprint”
-
I believe for newbies to KiCad Pcb layout the old appearance is more intuitive.
As I mentioned, it’s better for the workflow. The workaround posted does work, but it’s not nearly as obvious/helpful.
How do other EDA’s handle this issue…or don’t they?
If nothing else, pls incorporate HoleWallPaintingMultiplier=** etc into the GUI somehow without having to rely on backend hacks.
Thanks.
Ian.
1 Like
your simple opinion.
As are the vast majority of comments in this thread and all other threads on this form. And even this one of mine 
As has been pointed out, this is false. A pad being PTH vs SMD says nothing about whether it is exposed to soldermask and plated.
You listed a bunch of reasons why you personally prefer how it used to be. That’s not what John was asking for, he was asking for proposals of how to show the required information in a consistent and understandable way, which the old mechanism didn’t do.
I’m not sure that I understand this correctly, but just want to be clear: there is no “technical debt” or “need for refactoring” that is somehow limiting the rendering style here. The current (V9) style is our current stance on the best solution to the problems listed above in the thread, not something that we would do differently if we had more time.
2 Likes
craftyjon,
With all due respect (and I mean that!), you guys are the devs.
As a user, all I can personally do is present some issue in my own way with as much info as I can muster and have the expert devs interpret, weigh-up, look up, down & sideways to come up with possible solutions if they deem it required.
I don’t know the full spread of users and how they use KiCad, nor do I know the backend code and the complexities that make this issue hard to please all.
I’m a hardware guy really, but do have a popular open source Windows app (WinGPIB) & STM32 code out there that I wrote and are presented on the EEVBlog forums and my GIT. So I do to some extent think I know where you guys are coming from. But that’s about it I am afraid.
Ian.
I just want to add to your comment, that probably most users (including me) don’t hate this change and are just quiet. As I pointed out earlier I also welcome this change because now netclass colors and normal layer colors are rendered in the same way
6 Likes
ok fair enough. Personally this doesn’t bother me as there are plenty of other tier-1 tools (ie Mentor Xpedition) that renders it like Kicad is.
I guess what is key is understanding why people want the old style? is it because of some technical reason or is it just that they are use to it. Fundamentally knowing the top layer is RED you will already know that a pad is on the top
1 Like
I do understand where you are coming from, but it sounds like a lot of this reasoning is based on pre-padstack layouts. Concepts from that regime no longer apply universally to the current capabilities. For example:
“I can’t drop a via here and run my tracks under there coz that’s obviously a TH pad/hole”.
You can run a track like this, between two layers of a padstack with non-uniform pad shapes, so gold is not a reliable indicator of non-routability in the general case:
The PTH hole wall and through hole itself are the real sign of “you can’t route though here, it’s fresh air”.
Possibly a feature request here is “PTHs could have a dedicated fill colour, like NPTHs do” (not promising it will be accepted, but it’s a fair request), if you think just the black fill and gold wall is too discreet.
it’s gonna be hand soldered rather than re-flowed SMD reflowed”.
It gives a better visual representation of the actual board with having to 3D view.
Both of these are, IMO, a conflation of what was the gold colour and what has always been in reality un-pasted exposed copper. It’s often true, but not always. For example, pin-in-paste/hybrid pads are THT but are reflowed. And you can have SMD pads that are hand-soldered, and you may not be hand-soldering the board at all.
There are also dedicated tools to formally help you keep more clear of certain pads, for example pad clearance overrides, keepouts, and even custom DRC rules.
Having some better way to highlight paste and un-pasted, un-masked, outer-layer copper does seem like an entirely valid feature request. For my own part, I often find the paste layer to be a little too discreet and easily hidden under other layers.
what is on the other side, is there anything…oh yes, that’s a TH pad/hole footprint
That also depends on your padstack. Nothing forces the back pad to be the same as the front.
A valid feature request here might be: I want to see a “xray vision” of other layers’ pad shape boundaries even when normally rendered under the current focussed layer, so that I can visualise the pad stack better.
E.g. reducing pad opacity is a bit “muddy”, even with only 4 layers:
And maybe something (programmer art alert, this is a quick mockup with no statement of “I think this is a good implementation” attached) like this may be a helpful mode:
I believe for newbies to KiCad Pcb layout the old appearance is more intuitive.
I would contend that it’s more likely to tempt them into long-term wrong assumptions about what is going on for that pad with respect to various layer geometry and paste/mask settings. People have been making that mistake for a very long time.
How do other EDA’s handle this issue…or don’t they?
EDAs that support padstacks do what KiCad now does (at least Altium and Allegro do). EDAs that don’t support padstacks can naturally get away with simpler implementations.
.
If nothing else, pls incorporate HoleWallPaintingMultiplier=** etc into the GUI somehow without having to rely on backend hacks.
That is an actionable, self-contained idea that can be raised on Gitlab as a feature request. I can’t promise that it would be accepted by the team, or implemented in exactly that way (maybe we just need to tweak the default more carefully, for example), but at least it can be discussed on its own terms.
4 Likes
Personally, I would want some better evidence that there is actually a need for a setting other than people being used to the old way. I have not seen any indication that people new to KiCad find the new style hard to use, just statements that some people (and not all people) who are used to the old KiCad style found the new style hard to adjust to.
The problem with this setting is that the more the hole wall is exaggerated from its actual size, the more it creates visual paradoxes (things appearing to overlap that don’t actually overlap). Maybe this is useful for some users who got very used to the old KiCad style, but I don’t think it’s actually a good thing for new users or people moving from other tools. This is why I think it is best to keep this an advanced setting that is not exposed to everyone (besides the goal of minimizing the number of settings as was mentioned earlier in the thread)
KiCad 9 makes it more obvious that there is a difference between a PTH padstack and a via than Altium does, FWIW, because KiCad has the hole wall shown (I think this is true compared to Allegro too, based on screenshots I found)
1 Like
Sure, all I mean is that, valid or not, or good idea or not, it’s a fully-fledged request rather than a amorphous “I want gold pads back but I can’t concretely express exactly when pads should be gold or what gold actually represents”.
I suspect that the setting is indeed not a good idea, but it can be discussed largely on its own terms and that more focussed discussion may even (ok, it’s unlikely, based on…checks notes…129 posts and counting) inform what it is that people are really looking for with thicker hole walls. Or maybe it’s all just “I want a setting that can ramp up to a billion to fake the old style pads, kinda”.
3 Likes
This fills me with hope for the future of KiCad. Time and time again what kills good software is baggage, which usually comes from trying to be everything to everyone. This is a great example - moving forward with key functionality like padstacks means breaking old ties and making new ones that make sense in the new context.
7 Likes