Non-devs: what do you think of the app names?

I’d like to gather some opinions from users on the names of the applications within KiCad. How many people prefer the names as they are (Eeschema, Pcbnew, Cvpcb…), and how many people would rather see them made generic (Schematic, PCB, “Associate Footprints” within KiCad) in the future?

Please…users only. I’ve got a parallel thread on the devs’ mailing list for developers. I want input from people who aren’t used to this yet - it’s very easy when you’ve been using it for a long time to forget about first impressions.


Great idea. I like WYSIWYG. Make names self-explaining. I always wondered what happened to pcbold? I can’t even think what “cvpcb” means.

This is how the Getting Started guide explains it:

Eeschema : Schematic editor
CvPcb : Footprint selector
Pcbnew : Circuit board editor

While we are about it, we could decide whether footprints are “associated” “assigned” “selected” or “linked”, because these terms are all used in different places - and all four are used in the “cvpcb” dialog itself!

1 Like

My vote is for generic names.
I recently got started and the names were kind of confusing.

Composants vers PCB. (“Components to PCB” en français)

I wanted to call the OpenGL canvas pcbnewnew, but it didn’t stick :(


Yeah, consistency in terms is something we could generally improve upon.

I see no need to have uniquely identifiable names for the internal elements (its all KiCad as far as i’m concerned), clear concise naming (WYSIWYG) is always preferable in my book.

Doing otherwise just alienates people who are not in the know, which is counter productive.


I’m a developer, nevertheless I stronlgy support self-explaining names.
And consistency. So @bobc’s suggestion to unify terms is supported, too. Personally, I would prefer “assigned”.

My 2 cents:

Generic names like Schematic, Library, PCB would be good, this would also add to the consistency if the programs were named like that and then referred to as Schematic Editor, PCB Editor etc. In the documentation.

But I’d like to throw in another idea: Why not extend on the KiCad naming scheme? Something along the lines of KiSchem, KiPCB, KiLibEdit, KiLibManage and so on?

Remember, you read it here first :wink:

Edit: OK, you didn’t read it here first, I just saw that Jose suggested the same naming scheme on the dev mailing list :frowning:

Inside KiCad I would prefer self-explaining names. But please make sure they appear unique in system menus (start menu etc); “KiCad PCB”, “KiCad Schematic” etc.


Yes, of course. For better or for worse, the KiCad applications behave differently when launched standalone than when launched from the project manager, so that has to remain.

1 Like

I am also strongly in support of a rethink of the application names, to something obvious and consistent. This will have to be managed with docs team etc, otherwise people will be referring to applications that do not exist.

I thought I was the only one who didn’t understand what CvPCB meant - it appears that there were many people! (Maybe everyone was afraid of admitting they didn’t know?)


Heeey, aren’t you a dev? :wink:

1 Like

Curses, we’ve been spotted! Dive, Dive!

1 Like

I thought CvPCB was deprecating as a standalone anyway.
What is Pl Editor meant to signify?

Page layout editor. It edits the title blocks.

I know its purpose, I was puzzled by “Pl” which is a bit terse. Name length is not critical as the panel only shows graphical icons until you hover the pointer over them

1 Like

I’m all for it as well.
Schematic, Symbol Editor, Layout, Footprint Editor, Gerber Viewer would all be good.
And for standalone as mentioned above put a KiCAD in front.

As for CvPCB, call the button by it’s function. It’s not really a program/tool itself.
It should state what it does - ‘assign footprints’.

And while you’re at it (the consistency thing), please rethink the .pretty/.sweet folder extensions and make them self-descriptive as well.
Just need to be careful as the extension scheme for the footprint or symbol files will play into this as well.
Not sure about .kicad_mod though - a module for me is something different then a footprint.
Would be better to see .kicad_fp there and for symbols .kicad_sym


- OnSemi.symbols
    - NCP45560.kicad_sym
    - NUP2202.kicad_sym
    - NUP4202.kicad_sym
    - ...

And get the 3D models/shapes/etc. singled out into their own folder. Make one for STEP and one for VRML. Personally I organize them by type of housing [edit] package, like I do for the footprints.


The names should be meaningful in the language of a given version.
It makes no sense to use any words from the original language version in a different language version unless both languages use the same word. This also applies to documentation. But as an English only speaker, I would still put this at a rather low priority.


Priority is an interesting thing in a large project like this - things you think are small as an established user can be surprisingly noticeable as a newbie. In particular, things that contribute to first impressions, including this, can totally put off potential new users and send them packing for a different program. I’m aware this is a bit down the priority list, and it’s a big change to make - right now I’m just trying to gauge people’s opinions on it - but I honestly don’t think it deserves to be as low priority as a lot of people have been saying.


I’m another one who puzzled over “CvPCB”. Seeing the French phrase helps me understand the etymology, but it is still rather cryptic. This is a reminder that even if English is the most common language in technical subjects, it is still the second- or third-language for many technologists. I would push for names that can be easily and unambiguously translated into other languages and cultures.

The nightly versions of EESchema now use “Assign Component Footprints” in the drop-down menu; I think that’s a major improvement over “Run CvPCB”. The menu-bar tool-tip is still “Run CvPCB to associate components and footprints.” If the application was called “Ki_FP_Linker”, perhaps it would settle the argument over “Assign” versus “Associate”.