It seems to me that there is a lot of GUI inconsistencies in KiCad. Since they aren’t exactly handled as bugs in the bug database. How do you actually report design problems with the software?
There does not seem to be even a rudimentary guideline for developers on how to do things anywhere. Just having a single wiki page for this would make things much better as now it seems that every developer just wings their own way of working. The guideline does not even have to be very robust just as long as there is a place to build a guideline over time like say in the next 3 years. Where do you discuss the problems related to the usability issues of the software?
Because it seems to me that there are really low hanging fruits in this area. But for example I can not help by submitting patches because reporting is always its not a bug, so i don’t even know if such a fix would be welcomed. At least based on my discussion on the bug forum seems to indicate it wouldn’t be. Yeah its a design error, which isn’t a bug.
The official way is to ask on the developers email list or in an issue on GitLab. The core development team will discuss (maybe in private, or maybe in public) the specific question you have.
In more complex situations, we usually discuss with the team, which we find more productive than trying to come up with every policy ahead of time.
Because “design problems” are often a matter of opinion rather than of fact, we do not always engage with the broader community to determine what is “good design”. We tend to keep these discussions to a smaller group, who have already figured out how to work well together: how to have disagreements in a polite way and how to proceed when there are differing opinions on how to do something. This is also a reason that we haven’t put together a comprehensive public document on this kind of thing: we prefer to work on the most challenging/controversial/non-obvious decisions about what to do with a group of people who have already built a working relationship rather than the Internet at large. So, we generally invite new contributors to work on bugs and features that are not controversial, in order to build up that relationship.
I would encourage you to report issues on GitLab listing the details of a specific inconsistency (please do not combine multiple unrelated or vaguely-related things into one issue) as well as your proposed change, if you have one. Please keep in mind that we will evaluate whether or not there is something to improve separately from whether or not we agree with your proposed way to improve it.
No design is not about opinions. It is not a opinion that by having tool work differently at different instances makes it harder to learn, teach and use a tool. That is a fact.
But ill bite, lets assume its a opinion: Why would you make yourself more development work by not coordinating together?* If you don’t have the resources use them to best use case. Clearly this is not a good design:
Animation 1: The new Bézier tool works differently in schematics and PCB editor
Why would the same tool work differently in schematics editor and the PCB editor. This is not an opinion, its a fact. They work differently, period. Is it truly desired to waste time on doing two implementations and then later fix them to be same implementation? Okay so this is 8.99 maybe it will get fixed.
But looking then arc tool in 8.0.
Animation 2: Well the arc tool works differently too
As does the line tool.
I this really good development practice?
* After all your motto is we don’t have enough resources for development
PS: I don’t want you to agree, i want you to consider that there is in fact a problem which is related to how you work. Yes its not cool programming stuff, but you cant attain your stated goals if you dont start taking this into consideration
Many things about how software should work are opinions, not facts. Having similar-looking tools work differently in different parts of KiCad is not a design decision, though, it’s just a bug. There is no debate needed here. Just someone to report the bug, and someone to fix it.
I’m not sure there is a problem here. You seem to be jumping to some kind of assumption that:
there is no agreement on the KiCad team that similar tools in different places should work the same way (this is not true)
you can’t report such things on the issue tracker (not sure where this came from)
When things in KiCad work differently than you expect, it is because a developer didn’t know the right way to do it and just chose a different way at random
Instead of assuming you know why the Bezier tool works differently in two places and monologuing about how we should change our practices, it would be more productive for you to just open an issue pointing out that the Bezier tool works differently in two places so that there is a better chance of it getting fixed.
In January 2023 I made a write-up of an inconsistency in menu ordering, including screenshots for comparison. The issue was closed over a year ago, but inconsistency still persisted. Just now I made a new screenshot composition and re-opened this old issue.
Well i have reported and every time it has been closed as working as intended. What frustrates me is not that it does not get fixed but that the system is unwilling to even discuss the things.
You could upvote that issue to show support for it. Nobody is disagreeing with it or closing it.
(you might ask why is it that way in the first place: it’s sometimes because the PCB editor and the schematic editor up until very recently have had fairly independent ideas of what graphic shapes are, so it was not possible for them to share much code, and it’s sometimes just because of some bug in how one or the other editors implements the interactions)
Well the problem is that issues get merged with issues that are clearly dead. Even if they are not the same issue.
I cant upvote a issue that is not the same issue as what I wrote. I can add a disclaimer that i disagree but if i was lazily merged with a issue thats been up for 3 years. Forget it.
I am trying to help out here by finding issues that you think were closed in error and double-check them to make sure they shouldn’t be re-opened, but you are making it really hard by continuing to refuse to link to actual specific things.
In general, if you disagree with an issue being closed, or merged, leave a comment explaining why.
Right now you are just ranting about the system being broken and refusing to share any details that would let us check if what you say is true or not. You are also continuously taking a really negative attitude, assuming the worst about people by saying things like “lazily merged”. This kind of way of interacting is not productive.
No i think you are on a path with a strategy that has no avenue out. Im just trying to raise awareness that your making more work to yourself. But there seems to be no mechanism for me to help you from doing a long term maintenance suicide.
Also: i dont rant i just point out that your not doing a very good job. Nobody should need to raise a bug about same tool working differently. Every dev should instantly have understood this.
I’ve already said that what would be most helpful for you to do is to continue opening specific issue reports. That’s how we work here. Thank you to everyone else who continues to help us out in this way.
It sounds like maybe KiCad isn’t the best tool for you if you are both unhappy with its design and unwilling to engage with improving it in the way that we ask? There are plenty of other ECAD tools out there…
