I despair at any possibility of getting this basic "usability" idea into the collective heads of the KiCad crowd.
Sorry to say that, but you fell into the standard UX pit of: my approach is the right one.
No I didn't. It's just convenient for you to say that so that you can continue thinking that
your approach is the right one. Yes, it's hard to have your baby criticised, especially when someone says that your whole UI is riddled with usability problems and needs a radical overhaul.
KiCad is not a drawing tool for schematics as you would draw them for a book. Nor is it a tool to draw schematics for simulation, where you do not care if you can order that part. KiCad is there to build pcbs, and its long term goal is professional usage. And thats where database part libraries reside (planned for KiCad v7). Or nowadays, atomic libraries, when you want to have fully specified library symbols in KiCad as required by many business.
Optimizing you usecase makes KiCad behave more like a toy for electronic beginners, but not for people who care about the parts they need to order in the future.
There is no tension between "
make the drawing bit easy" and "
make it possible to fully specify components". To get the latter it is not necessary to make "
drawing" an exercise in "
selecting components from a database". You're thinking of the schematic capture tool as a "
produce a netlist containing wires and references to a database of components" tool, which it is under the skin, but
on that skin you've quite deliberately put a
schematic drawing interface. If you're really so wedded to the idea that it's being a "
select parts from a database" tool is overridingly important and the
drawing bit is an annoying irrelevance, why bother with this
drawing at all. Make 'em select all their components from the database and only then let them draw any wires or move components about. That would be ridiculous wouldn't it? Why so resistant to making the
drawing easy with good usability? Looks to me that you can't see the wood for the trees.
For your use-case: place a resistor once, and duplicate it when you need a second one. Should be fast enough and works for every part, not only the "standard" ones.
For a start it's not a use-case, it's a UI usability case, inability to tell the two apart is telling; as is dropping into business analyst-ese with phrases like "use case".
Every time, every bloody time, someone says to fanboy contributors of
program x "It would be better if the UI did
this like
that" the fanboys say "Oh, you can do that [the functional equivalent] by <series of moves in existing UI>" thereby completely missing the point. Just because something is functionally possible doesn't mean that it satisfies usability criteria.
I've been a programmer for 45 years, since the bloody punch card era. If I was as resistant to improving usability as you guys seem to be I'd still be insisting that my customers used punch cards. "No, look, you CAN change the customer field. Just pull the 3rd card out of the batch, walk over to the punch/duplicator, hit COPY for the first twenty columns, then type the new customer name, and then keep hitting copy until the end of the card. Then put the card back into the stack. See, no need for fancy mice or screens. Not as easy for you, you say. Well if you want a millennial
toy rather then a
professional tool I suppose it's alright, but we produce professional tools." Sound familiar?