Kicad pet peeves

[pedro]

@ArtG

I guess that’s another pet peeve - different functionality on different platforms.

Amazing! Unless it has changed in the latest nightly. I thought it was a useful feature.
I think I will delete dangling tracks from “cleanup tracks and vias” before updating the netlist in the future.

[Rene_Poschl]

If you use nightly and ArtG uses stable i guess this has just been added in nightly. (or other way round, or even if both of you have nightly but different versions.)

I don’t think the stable build differs on different platforms. (Nightly might because the simulator integration is not available for all operating systems.)

[ArtG]

@Rene_Poschl

If you use nightly and ArtG uses stable

I used today’s nightly (Dec 27th) It was like that for a while too, not a recent change

[eelik]

@ArtG

Since everybody is apparently perfectly happy with all the features in the software

Not at all, it’s just not easy to list them. I’d like to give a more general, bird’s-eye view. What actually makes day-to-day work slower, even if one learns to live with it or doesn’t even notice it. Many smaller and bigger things are already mentioned here and some are well-known in the community, some are actively going to be fixed by developers. Here are some things:

1. Footprint editor should be something like which was mentioned and linked here, using parameters and distances. Now it’s simple and intuitive, but putting pads into their places requires manual calculation or/and moving the mouse to a right pixel. With a good wysiwyg interface it could take e.g. 5 minutes instead of 30.

2. Symbol editor should have an editable list of pins or something like that for creating and editing pins. Now it’s simple and easy to learn but really tedious.

3. The interactive router should work better in many ways. There’s much potential there but I just find myself deleting the tracks (often segment by segment) and redrawing them because they are not what I want, even though I spent already too much time drawing them the first time. The problem is mostly that automatic cleanup doesn’t work and it often creates a mess when the new track segment isn’t good and I try to redo or drag it. There exists something like global cleanup but it should just work on-the-fly.

(On the other hand I can’t imagine how anyone could have done it without the interactive router in the first place!)

4. The interactive router really, really needs dragging for footprints. Sometimes the interactive router becomes almost useless because I need to move a footprint and redo all the tracks. (Well, of course I still use it for doing the tracks, but you understand what I mean…) The non-interactive legacy canvas dragging is of no use.

Of these, numbers 3 and 4 are the ones which cost most time in day-to-day work.

Then, as a programmer, I like to think what could be done to make it better. There I’ve got some pet peeves, too:

1. The code base is difficult to learn. That’s not specific to KiCad, though. It’s always difficult to dive into existing code.

2. The coding conventions are horrible. (Using UPPER_CASE for almost anything… Sigh.)

3. I don’t like wxWidgets. Well, I haven’t even used it, but I still don’t like it. Nowadays there would be no reason to not use one widget library which is directly implemented on all platforms (GTK, Qt). I actually don’t like the idea of “native look&feel”.

[Rene_Poschl]

@eelik

Footprint editor should be something like which was mentioned and linked here, using parameters and distances. Now it’s simple and intuitive, but putting pads into their places requires manual calculation or/and moving the mouse to a right pixel. With a good wysiwyg interface it could take e.g. 5 minutes instead of 30.

Work in this direction is done. (Not sure how far along it is.)
https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg25180.html

[eelik]

I was aware of mathematical expression input and it’s great, but in the larger picture it’s just a small detail which doesn’t move us a long way towards what I want (see e.g. the link in ArtG’s post Kicad pet peeves).

Edit: It would need wysiwyg dimensions, rulers or anchor lines.

Edit2: mathematical expression evaluation already works in daily builds.

[Rene_Poschl]

There is really no pleasing you guys. (And yes i would like a similar way to define footprints as is used for example in the sketcher of most parametric MCAD tools. But this is really far away.)

[eelik]

@Rene_Poschl

There is really no pleasing you guys.

Oh yes there is, but I, too, like also to share what’s not so great in my opinion. I like KiCad very much and would like to make it better. Actually I have thought about what it would take to implement something for the footprint editor. But alas, my pet peeves about the KiCad code and other things have kept me back. The most important thing is, of course, the difficulty of learning a new code base and also a new widget library and other technologies (OpenGL, maybe?).

[Rene_Poschl]

@eelik

I don’t like wxWidgets. Well, I haven’t even used it, but I still don’t like it. Nowadays there would be no reason to not use one widget library which is directly implemented on all platforms (GTK, Qt). I actually don’t like the idea of “native look&feel”.

Took me way longer then i care to admit to find this message on the mailing list:
https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg26837.html

In it Wayne said he is not really prepared to switch to something different then wx if there is no good reason for it. (Basically every framework has its problems and it is hard to predict if any other thing like Qt really is better on all platforms.)

[llondel]

@ArtG

I’m not a fan of assigning a footprint to a symbol on the library level. In my opinion ability to have multiple footprints per symbol is one of KiCad strengths. Assigning footprints can be implemented better but the concept is still the right one. Library management in KiCad is really awkward to begin with, I don’t need to have a hundred “parts” for a single resistor, just to accommodate all variations of all avaiable footprints.

I would disagree in part here. For a given component I very much want to have all the information pre-defined, so a 10k 0805 1% resistor could be called up as same, or a 74-series TTL package explicitly as the SOIC or TSSOP variety. I’m looking at it from the error potential - if it’s all there, ideally checked from the first time a part was used, you’re not going to introduce a typo by re-using exactly what was installed and verified to be correct. Any time I have to go in and edit a field I’m introducing scope for error. If I’m patching in to a database of manufacturer/vendor part numbers then it is very important that the footprint is defined up-front because otherwise I have to go edit two fields or end up with a part that won’t fit.

You could certainly save space by having a symbol library and a footprint library that were distinct from the part library, so all your different resistors in the part library could call up a common resistor symbol and an appropriate PCB footprint and only need one copy of each instead of one each per resistor. However, KiCAD doesn’t do that at the moment. (Which I guess is one of my pet peeves, to refer back to the opening topic.)

[JeffYoung]

@eelik

1. The code base is difficult to learn. That’s not specific to KiCad, though. It’s always difficult to dive into existing code.

I’ve actually found it easier than most.

2. The coding conventions are horrible. (Using UPPER_CASE for almost anything… Sigh.)

All coding conventions are horrible. The only thing worse is no coding convention.

3. I don’t like wxWidgets. Well, I haven’t even used it, but I still don’t like it. Nowadays there would be no reason to not use one widget library which is directly implemented on all platforms (GTK, Qt). I actually don’t like the idea of “native look&feel”.

Yeah, wxWidgets is indeed my least-favourite part. (Aside from wxFormBuilder, anyway.)

Then again, I can’t remember ever using a multi-platform GUI toolkit I liked.

[eelik]

@JeffYoung

I’ve actually found it easier than most.

This gives me some hope.

@JeffYoung

All coding conventions are horrible. The only thing worse is no coding convention.

Very true, and it’s always a matter of taste to some degree. There are also some good, useful conventions in KiCad, like using “a” for function arguments.

@JeffYoung

Yeah, wxWidgets is indeed my least-favourite part. (Aside from wxFormBuilder, anyway.)

Then again, I can’t remember ever using a multi-platform GUI toolkit I liked.

Usually people learn to prefer something which they use, and that happened to me with Qt. The link given by @Rene_Poschl was good reading. I don’t expect KiCad to change in that respect; I just don’t like wxWidgets. Maybe I learn to appreciate it with time, I already started to learn it with python.

Which introduces yet another problem in KiCad - the state of python scripting support (other than the lack of a plugin manager). (Sorry, ArtG, but I don’t limit my pet peeves to the end user problems). Despite of documentation, examples etc. I have found it difficult to find reallly good, working information about scripting. About every example and script I have tried has had some problems. The state of the scripting support seems to be not so good. I hope this will get better after 5.0.0. But this would be a topic for another discussion and not so much for end users.