Kicad-nightly-9.0.0.rc1 - PTH pads and via color

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 :slight_smile:

1 Like

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.
3 Likes

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.

3 Likes

@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:

image

2 Likes

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.

4 Likes

That’s the magic of the “Release candidate” moniker, I believe… :slight_smile:

1 Like

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!!! :heart_eyes:

What do you mean by “individual code modification”? I don’t see any commits on this topic, does it mean Jon did it in some “private” branch?

1 Like

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.

As I commented way up this thread:

If changes to THT pads are to be made, my preferences would go to @Jonathan_Haas , or the new thread started by @ModuloFS .

1 Like

I’m glad you’re happy, but if your patches could be published somewhere so they’re available to others interested, that would be great.

There have been some changes pushed to the repository in the past few hours; they’ll be available in the next nightly build.

1 Like