Yes, Ideally KiCad should only have just a single menu button which always does what the user wants.
To be more realistic. Refactoring is taking place. Sometimes even big things such as the complete file format overhaul introduced in KiCad V6, and with it both all used symbols and footprints are embedded in the project. A lot of things have good or historical reasons for why they are as they are as explained by eelik in the link posted by jmk.
For the rest, I already wrote:
I know you mean well, but I have followed KiCad development for several years (being a forum moderator, issue database janitor and having contributed a couple of lines of code) and itâs apparent you donât know how KiCad development works. The code is being refactored slowly, the UI and UX has been made internally consistent slowly, quite much has already been done to make KiCad consistent between different parts. Usability is important for the core developers. The KiCad codebase or architecture isnât falling apart.
Of course there are things which could be made better. But the developers plan ahead, know what they are doing and donât allow contributions which would rot the code base or the UI. You can have your opinions about details, so do I, and I donât always agree with the decisions. But in general the project is going forward in all areas. The problem is â always and in all respects â that the resources are limited and must be spread over several needs, plans, features, bugfixes etc.
Actually some commercial projects have more of the problems you mention. The development is in the end driven by commercial interests and the resources are put where the money is. There are two possible paths: either the code and UX continue rotting slowly and becoming more and more difficult to manage, or it is rewritten from scratch. KiCad has managed to take the superior path, slow but steady refactoring and enhancement, taking the needs of the end users and the developers into consideration.
Hi,
Thanks for the FAQ and answers. 
It reassures me that KiCad is developing in the right direction. I am happy about that.
Hi,
I tried moving the tracks again because I could just use it. However, I had to realize that the way it moves the segments is not usable. Why?
The horizontally marked segments should remain on the Y axis. Then I try to move only the 45° segments to the right. In doing so, it moves the horizontal segments downwards. Exactly what it should not do.
The function has to be modified. I donât think anyone wants it like this. You would have more rework as it helps. Donât be angry with me, but it doesnât work like this.
Euhm, well, apparently it does work like that.
Why do you write:
The important thing for you to learn is to stop worrying about trivial details. You fist set up the net classes to proper track widths and clearances, and after that you just connect the tracks. It simply does not matter at all whether the horizontal tracks move or not. If you donât like their position, then you can move them afterwards. You probably have to move them again in an hour, tomorrow or nest week because you then decide to put some viaâs or resistors in between those tracks.
Another thing that would help is if you would stop blaming KiCad for your own lack of knowledge / experience of how to work with it. Instead, just accept the way it works, and figure out how you can use KiCadâs features to your advantage, instead of fighting it.
Hi,
now it becomes nonsense. Later I correct the horizontal segments and KiCad then stupidly moves the 45° segments too. What have I gained from this?
Experience?
And some *&^%$#@! to get over 20 chars.
Fortunately, there is no obligation to use KiCad or any other open source program.
True, but a bit harsh, but also understandable.
Nobody here is waiting for rants or complaints.
I was expecting some kind of serious response for:
For me this dragging track feature is also hard to use. After drag one track I have to drag all others.
I have to set minimum clearance to 0.18 as my main controller has 0.4mm raster and 0.22mm pads. As it is main IC even I would try to have its nets in special class to have bigger clearance for the rest these rest would be may be 20% of tracks.
But when routing I prefer to have bigger distance between tracks (taking in mind crosstalk for example) so I keep this distance manually. Then if I have to drag one track the distance decreases so I have to manually drag all the rest.
Why this cares. For example you have TXD and RXD lines in paralel but they go under shield and have to be filtered at shield border. I place capacitors out of shield, but as close to border as possible (I donât use through shield capacitors) and then inside shield resistors also just near shield border as possible. Resistors are to decrease disturbance re emission inside shield.
So inside shield you have TXD line strongly driven by controller and next to it RXD line that is driven by resistor (practically you have many output and input lines mixed).
When I was searching information about crosstalk I found that practical solution is to have tracks distance 3x track width.
I think I canât stop worrying about trivial detail of track distance at their way. At the end they have to be at 0.18mm from one to another but I push them away from each other as fast as I can.
@Piotr I agree that itâs a good idea to make clearances wider if there is room to reduce capacitive coupling. Iâve been experimenting a bit with custom rules to do this.
First, I created a simple rule area and gave it the name ânarrow1â and nchecked all basic rules.
Then in the board setup, I created a custom rule:
Or, in text:
(version 1)
(rule clearance_mod
( constraint clearance (min 0.4mm))
( condition "A.intersectsArea('narrow*')")
)
And on itself this works. I can now set a narrow clearance to be able to reach the pads, and the track segments that intersect the rule area do get a wider clearance.
But in practice, it does not really work. This rule area interferes with the interactive router. As you can see from the screenshot, it says there is a DRC violation, but if I force that location with [Ctrl], and then do a DRC check, there is no violation. On itself, the concept is useful enough to try to make it work but I am encountering too many difficulties with it at the moment.
Maybe I should report this on gitlab, but I have very little experience with custom rules.
You can also make a custom rule to modify the clearance when you are inside the courtyard of a particular IC. These custom rules are quite powerful things (Assuming you can make them work as intended).
Also, in your example:
You can use here 0.18mm tracks and 0.22mm clearance (Sum is also 0.4mm) if you use a custom rule to reduce the clearance inside the couryard. This prevents the pads from thowing clearance violations, while still being able to increase the clearance for the tracks a bit.
I didnât tried to use any custom rule yet.
I think that it is mainly useful when you have complicated PCB or when someone else sets the rules and someone else designs. Specially when someone else makes schematic he can know there are some requirements that PCB router (person) can not know.
As my projects are simple and schematics are done by me I have all signals in my head. When routing each track I know if its state changes once a day or if it is up to 50MHz SPI bus.
Hi,
anyone who answers arrogantly has to deal with a headwind. But itâs interesting that you first complain but then realize how stupid that is. If the operation becomes too complicated, it wonât be used. You are faster manually.
And such arrogant answers are even more pointless. The point is to make a program more usable. Many people just donât understand that because everyone thinks of themselves in the same way.
Stop your arrogant answers and we can talk to each other normally.
I could answer if I will understand you. Be more clearly, please.
On what I complained?
What I realized is stupid?
Iâm not sure what you mean as for me your sentence (thanks to word âbutâ) looks like speaking about two opposite reactions then complaining and seeing something being stupid are not one to opposite the other but rather the same side reactions but with different level.
You were kind to omit from the quote your statement to which this was a reaction. If you use word âstupidâ describing KiCad actions (I even donât know what exactly so stupid KiCad did) then for me (and I believe not only for me) you express your opinion about KiCad developers as a whole as most KiCad actions are not the result of chance, but of a concerted decision.
Of course bug happens, but in such case instead of using word stupid it would be better to help and report that bug.
So if you came here to insult people who created something as good as KiCad in their spare time, wouldnât it be better to exercise your right not to use it instead of expressing your upset about the stupid behavior of the program?
There is no less true or more true. Something is true or not true. Is there anything not true in my sentence?
