Discussion of Symbol and Footprint editor Interface Issues

Hi Rene,
I think it’s a matter of taste and preferences.
First of all, I never use the libraries that comes with KiCad (or Eagle) and I don’t like the symbol and footprint editor in KiCad.

  • no ‘E’ (edit) command in symbol editor for circles and polygons

  • no ‘G’ (drag command) in symbol and footprint editor

  • no possibility to select multiple objects while not selecting an object in the midst of it

  • no group move in symbol editor for designators and values (selected by drawing a rectangle with the mouse)

So, at the moment my workflow is to create a deviceset in Eagle (symbol, package, attributes, etc.) and when finished I convert it to KiCad.

What I like about the converter is that it’s not written as an ULP and not written in Python (which I detest).
Also, it gives me more control about how the conversion takes place.

To be honest, I dislike the interface of KiCad. I guess this is partly because it uses Wxwidgets.
I find it a real pity that the developers don’t use Qt.

For me the reason to start with KiCad is the acquisition of Cadsoft by autodesk, the layout editor of KiCad (which is much better than Eagle) and the 3D support and 3D viewer of KiCad (which is really great). For the schematic editor I prefer Eagle. Also, the fileformat of Eagle (XML) is way better than the S-expressions of KiCad (I’m not asking you to agree with it, it’s just my opinion).

As you can see, it’s all personal and I’m sure that most people will disagree with me. That’s fine, I respect other people’s opinions. At the same time I try to find ways to make my job as easy and efficient as possible.

And yes, I know that “all problems will be solved” with KiCad V6 :wink:

Still, KiCad is a great project, many kudos to the developers and the people here trying to help.

1 Like

Reminds me of:

I also have a dislike for Python. Especially when people try to write a real program in that scripting language, and the way it abuses whitespace for controlling program flow. Juck. Just start a python command line and type " 3+4"

paul@medion:~$ python
Python 3.8.5 (default, Jan 27 2021, 15:41:15) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>  3+4
  File "<stdin>", line 1
    3+4
    ^
IndentationError: unexpected indent
>>> 

The world would be better if I saw an big naked foot with ugly nails stamping out that snake.

But it is adequate as a scripting language and it seems to become a de-facto standard for quite a lot of scripting interfaces for programs, and that is why I put some effort into learning it

Dvorak is also better then Qwerty, but Qwerty is ubiquitous (Except in Belgium, they use Azerty.) and the difference in performance is not big enough to shift the world.

1 Like

Offtopic… Dvorak is better for special cases where someone writes a certain type of text. Each programming language which use different characters in their syntax would need different dvorak to fulfill the purpose of dvorak. Each natural language needs their own dvorak. That’s why dvorak is practically useless for masses. In general, it’s not universally better than qwerty.

But python is universally better than other languages. :slight_smile:

Both work in the symbol editor. The catch is that your cursor (actually the crosshair, not the mouse cursor) has to be exactly aligned with the object, which won’t happen for most points of the circle.

Works fine for me …

In the symbol editor, when I try to drag the corner of the rectangle that forms the body of a symbol, I must select a polyline. I can’t find a way to drag the corner as in Eagle.
That means, dragging the corner of the two polylines without moving the opposite endponts of those polylines.

Also, E for edit doesn’t work here for circles in the symbol editor. I must doublecklick in order to open a minimalist dialog where I can only change the linewidth and fillstyle.
Compare that with Eagle. For almost every object, you can open a properties editor where you can change linewidth, endponts, curve or radius, layer, etc.

image

image

An arc:

image

I hope you are OK with me splitting this as i think your script post is better off without the discussion about the interface of symbol and footprint editors.


Circles and arcs have the “E” command, but it seems to be a bit temperamental for me (I am however on a quite old version of v5 and can not check if it is better in 5.1.9)

It seems to really only work while the mouse is quite near to a grid point that lies on the circle.

Drag exists for polygons, rectangles and circles. But is used to change the size of the current element (or in the case of the polygon the position of a single point) not to move a full element and have an element of another type follow along (like moving an arch and expecting a line connecting to it to be dragged along)

And here a similar issue as with the “E” command at least with my version of KiCad.

It is a different story in the footprint editor. The interface is totally different. There one clicks on a graphical element to get its “drag” points. But dragging a point does again not drag a neighbour with it. I personally never really missed this as i basically use the user grid for most of my operations and then it is not that much slower to just select the second object and drag its endpoint to the new place (and since v5 there is object snap so this is even faster than before).

Really only feasible in the footprint editor as there are the selection filters (right click -> filter selection and select only the text fields before move).

Block selection also works in the symbol editor but without selection filters it will be hard to move just text and leave everything else alone.

Maybe I found a better example:
In Pcbnew, you can drag the corner of a trace.
Why can’t we do this with a corner of a symbol in the symbol editor?
In Eagle this is much more consistent. Many times you use the same commands and the same
workflow for schematic, layout, symbol and footprint editor.
Let’s say it’s more uniform.

Also, the properties dialog of a trace in Pcbnew seems to be almost complete. The only thing missing is the curvature. Why not add this?
In Eagle, there’s basically no difference between a straight line and an arc.
A straight line in Eagle is just an arc with a curvature of zero degrees. I find that very elegant.
Sure, in Pcbnew, one can delete the trace and replace it with an arc. But still.

Pcb new and the footprint editor use a completely different user interface. This was developed for version 4 (back then it was not the default way of interacting with kicad). There where plans to get eeschema and the symbol editor aligned already in v5 but there was too little time for that.

It will however come with v6.


And as a general note: Every tool has its strange features. You will be much happier if you accept that kicad is not eagle and that you will need to learn a new tool.

It is generally hard to remember how long it took to learn an old tool while switching to a new one. I personally always plan about the same amount of time for switching between tools as it took me to learn the first one (mostly because i underestimate how long it took to learn the first one so this is not far of)
This is getting better as interfaces improve overall but it is still true at this point in time at least in highly specialized applications like CAD tools

Yes, inconsistancies in the two interfaces are a known (and being corrected) issue. The KiCad team wanted to update and normalize the interface everywhere starting back in 4.x (I think, it was a while ago). But, being a small team they could only focus on one major branch at a time. They chose to update PCBNew first. Now they are playing catchup in EESchema. There should be less differences between the interfaces in v6. I haven’t played with the nightly development versions that will lead to v6 (hopefully sometime this year) so I don’t know how close they’ve gotten the interfaces.

Sorry Rene, I guess our replies crossed eachother.
Anyway, the way it works in KiCad seems more cumbersome to me.
Could also be that my brains are conditioned after using Eagle (and Linux) for so many years.
Could be. It’s just my opinion and I only wanted to explain why I use workarounds in order to be more productive. It doesn’t mean that what works for me, works for others as well.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.