Footprint association or Footprint assignment seems better to me
“Assignment” seems to work best, e.g.
“Click to assign footprints”
“Remove current assignments”
“Show assigned footprints”
“Selection” is best avoided, as it can be confused with the operation of selecting a GUI item.
Fixing bugs and improving the UI need not be exclusive. Personally I would regard a confusing UI as a bug anyway, since the purpose of the software is to increase the productivity of humans.
7 Likes
Yeah, this. Bear in mind too, I’m just looking to gather input so I can gauge if this is something that ought to be done and effectively prioritize it. I’m not doing it tomorrow. Y’all should see what I am doing tomorrow 
1 Like
I’m all out of chickens. Bringing some sanity to the pretty libs is on my list.
2 Likes
In Germany the word for enclosure or package is usually ‘Gehäuse’, which loosely translated would come out as ‘housing’ bak baaak baaka bakk 
Example?
2 Likes
I also prefer more generic names like kicadsch and kicadpcb instead of
eeschema and pcbnew. And while your are at it delete that cvpcb program
because the footprint should be coupled to the specific component in
the library. I never used cvpcb nor will I start using it.
And if you want kicadsch and kicadpcb to be professional replace the
.pretty name and the like for something more descriptive.
roelof
cvpcb sort of already is removed - it is technically just a dialog inside eeschema now. I’ve had my eye on removing the last few UI quirks that treat it like a separate application for a while.
There’s no way I’ll be able to convince anyone to drop .pretty. And just you wait until you see what the sch one is going to be called…
1 Like
That is counterproductive.
Lots of newbies and occasional users wont run their own libraries ever, so why take a perfectly valid way to design pcbs away from them.
You and I and a lot of others don’t use CvPCB, we don’t even open it, it’s not causing us any pain.
Live and let live 
1 Like
How it went down:
JP: lol I bet you $5 I can make the silliest names for this stuff *creates eeschema, pcbnew, cvpcb*
Dick: yo watch this. hold my beer *creates .pretty, .sweet, richio*
JP: *sadface, hands over $5*
Okay not really. But that’s how I imagine it.
2 Likes
As long as they stick to beer we’re pretty safe I’d say - at least here’s hoping. 
Any story on the 4 different pickers up there to share? 
I hate to say it, but I wouldn’t mind seeing an expansion of CvPCB. Currently the only thing I use it for is checking to make sure that I haven’t forgotten to assign a footprint.
This expansion would be to convert it into a table-based (spreadsheet-like) component properties editor with cut and paste capabilities. So, lets say I decide to change 12 switches on a board because the part went obsolete. I could either change the first part in the schematic or in the table editor, and then using the table editor copy and paste the changed part number (and footprint as would likely happen, and any other properties) in the table just like editing a spreadsheet. Then save the changes back to the schematic.
As it is now, the way I would do this within KiCAD is change the properties of 1 part then delete all the others. Then copy the first part to where the others were taking care not to shuffle reference designators around. Much harder on a multi-page schematic as I still haven’t mastered cross-page cut and paste… I suppose directly editing the schematic file(s) with a text editor and doing a search and replace would also work, but that isn’t within KiCAD. And falls apart if I decide I want to add a property to all the components in a schematic.
Hmmm… As I’m thinking about it, maybe an easier method for the developers at this point would be a component property .csv export and “import with update”… Then my editing can be done in an actual spreadsheet program saving the KiCAD developers from actually having to code a spreadsheet interface…
2 Likes
In danger of derailing the conversation and causing some bikeshedding. I think CSV import export sagas are cumbersome and unnecessary. I would prefer if this was part of the software instead. CSV export/import is a way to interact with external software and comfortable editing of part attributes should not require an external tool.
But as far as I understand there is a patch adding table view/edit in the pipeline already. So unnecessary export/import dances will be a thing of the past. Looking forward to seeing that addition appear in a future release.
To bring the conversation back on it’s tracks a bit, and because I did not contribute any patches yet I might qualify as a non-developer.
I am in favor of shorter and descriptive program names. If the binaries will still live in the global PATH search environment a prefix/suffix designating the binary as being part of the kicad ecosystem is probably a good idea. Other applications might decide to use ‘schematic-editor’ too. Regarding binary name lengths I do not think it is necessary to abbreviate the names too much, this is what tab completion is for.
1 Like
Once they’re there, yes.
We can only point out solutions that exist now, not in some distant future 
1 Like
The potential problem with the integrated solution is the table view/edit probably has a limited subset of standard spreadsheet features and might have the added benefit of some wonky-ass user interface.
2 Likes
As a newbie, I will support RickB. When I first looked at KiCad, I just walked away because the names were confusing and off-putting. I read French, but “Cv” is not much of a hint.
I realize there were / are historical reasons for the names, but as KiCad evolves I think consideration should be given to rationalizing the names: file extensions, program names, etc.
MMM
1 Like
Linux causes limitations of needing unique names at the command line eg KiCad gerbview vs gEda gerbv