I’m on a roll. Anybody wants to share your pet peeves about KiCad. My main complains are related to PCBNew (just realized that the name is one of them ) Here are the things which I can remember now:
Can’t place via on the end of an existing track. When you try to place a via on an end of a track, a junction or just in a middle of a track, you have to click in that spot hit V shortcut and then move the cursor to the side and only then the via would appear. If you move back to the original location it will disappear again. Depending on the side of the grid the locations can be pretty far apart from each other. This especially drives me nuts when you run a trace on multiple layers and click the mouse button first to “tack” the trace down and then hit V - it will not place the via at that spot anymore, so you have get out of the trace drawing mode, delete the last segment (here we go, another pet peeve - what happened to the good all backspace, when you could just delete last segment without having to interrupt your workflow) then go back to track drawing mode again and draw it again and this time try to remember hitting V first before clicking. And while I’m on the subject, add via tool is worthless for that too (or for any other purpose really). You can’t snap to the existing tracks when you activate it and even if you manage to place a via manually precisely on the track, it won’t assign the net name to it. You would have to manually edit it and try to find the proper net name from a list of a gazzilion nets.
Being able to switch quickly between top layer visibility only and bottom layer visibility only. High contrast mode doesn’t really do it. High contrast mode is useful during layout, when you actually need to kind of see what is going on on other layers, but quite often I need to be able to see everything on one layer (silk screen, footprints and copper). To do that right now you have to jump between two separate tabs and do a lot of clicking in between. An if you have to keep switching back and forth, it becomes a real annoyance.
Changing track attitude. In GAL canvass changing attitude of a track sometimes is just close to impossible, especially when you are trying to connect it to a pad. It seems to have a mind of its own and refuses to take into account any user inputs. Quite often I have to get the track close to a pad and then stop and connect it to the pad by starting drawing from the pad to the track, just to make sure that it doesn’t stick out from the pad at some weird angle. There were couple of cases when I had to switch back to legacy mode because it would just refuse to place the track the way I wanted it to go in the GAL canvass.
Sometimes it helps to press the ctrl key for the last part of the connection. (This tells kicad that you don’t want further changes in track direction.)
Or place it as kicad suggests and then use the interactive drag feature to move parts of it around. (The interactive drag feature gives a lot more user control than interactive routing does.)
What’s that “LayerViewSet”? In a daily build I can find on Layer tab -> context menu -> “Show All Front Layers” etc. which should do the trick, but it doesn’t work well ATM - it selects/deselects the right layers but I have to e.g. go to Render tab and deselect Pads Front if I want to see only Back layers.
Ah! Sounds useful. But one of my pet peeves at the moment is that there is much potential in scripting but it’s not realized. There are several nice useful projects but few find them or even want to try them because it means downloading, saving, keeping up to date and being unsure if the nice script will work in the future. There should be a script downloading tool, a bit like web browser plugins.
Completely agree. I deal with it all the time. More often than not I see some scripting tool that provides very valuable functionality but I don’t install it because the hassle is just not worth it. And another issue to consider is that more often than not those scrips are trying to plug the hole in the existing software that shouldn’t have been there in the first place.
An easy to use “plugin manager” like that of Arduino IDE would be really nice. Many (most?) software tools now have a “add on manager” or even marketplace function, but there doesn’t seem to be anything off the shelf that could be adopted, it also needs something on the server side.
The Arduino method is quite lightweight, the server can be a github repo. The user just adds the URL to the repo (or other site) into the Arduino IDE, and then the Arduino IDE provides install, uninstall, update functions. It is fairly easy for developers to create packages, it requires a JSON file with some config and a SHA sum of the package, which can be mostly automated. The package is a zipped file.
When I have a chance to set up my Linux box again and build KiCad, it’s something I would like to look into.
I don’t completely agree with that. The other point of view is that if there was a good ecosystem and the Python API and support would be first class much of the existing functionality could be moved to plugins. The core developers could concentrate on the C++ core and do what they are best at. There’s more freedom in Python - you don’t need to compile or set up a complicated environment. Distribution is easier and quicker, no need to cross-compile and distribute for different platforms. Etc.
On the other hand this would require that important plugins were fully developed, supported and maintained over time.
I had a brainstorm and ATM have some vague idea of a system which maybe wouldn’t need extra C++ support. Only one master Python plugin which would handle plugins. And also no need for anything special on the server side, or not even a new server or service at all.
I, as a user, don’t really care how a certain functionality implemented or what language is used. I have no problem with a concept of certain tools or functionalities being Python (not to exclude other reptilians) plugins. What I disagree with, is trying to band aid a badly designed tool with a plugin patch. Anyhow, I think we departed from the main topic.
Which part of my statement exactly is not true? Are you sure you are talking about GAL canvass? I’m assuming that your proposed sequence of steps to place a via on an existing tack is: switch to track mode (T shortcut), click on the existing track, press place via shortcut (V) and then press end track without moving your mouse pointer (End button is a default shortcut)? If so, it does precisely nothing. So right back atchya with your “not true”
Works in 4.0.7 GAL canvas. I can place the via even by normal left click. (By the way track mode is shortcut X for me. T brings up the search tool.)
Is it possible that something is too close to the location where you want to place the via? (DRC might not allow it to be placed there.)
To make sure this is not the case test this where no other traces are close.
My workflow: switch to track tool, left click at the end of one of the traces, press v, left click again at the same place (It does snap to the end of the trace). -> via is placed as expected.
I can also place a via this way in the middle of a trace. (Here it snaps to the intersection of a grid line and the trace on which i want to place my via.)
If it does not work in nightly any more, then this is a regression. (Make a bug report.)
No tracks nearby. I use the same workflow. I do use nightly builds. The via would appear as soon as you move your mouse by one grid size, whoever if you move it back to the starting point it disappears again.
Congratulation you discovered a bug. Please document your findings over at the bug tracker.
Don’t forget to add your version information and a small test project that allows reliable reproduction of your bug.
Maybe make sure you have the latest nightly release installed. (Your wonderful bug might have been fixed already.)
Most importantly have a look around at the bug tracker. Somebody else might have reported something similar already.
Oh thank you! That’s what hose things are called! And you can track them too! Who would’ve thought!
Lately I try not to waste my time on trying to file every bug, but only the ones which are major issues (at least for me), even those sometimes tend to sit there with no action for months. I can tell you right now what would happen with this bug. It will get filed under a wish list with no action in coming years.
I thought my emoji would already communicate that i am not fully serious. (I even googled what emoji to use to show that one is not fully serious.)
Well so be it.
But still if nobody reports such bugs, the developers will never know about them. And regressions in functionality should not be filed as wishlist. (It worked in v4, should be expected to work in v5 as well.)
Back to the issue. I’m not sure, but I think it was there for some time. I remember it annoying be for a while. It is still present in today’s night build.
) Here are the things which I can remember now:
Please document your findings over at the