← Back to team overview

kicad-developers team mailing list archive

Re: Are the python BOMmers case sensitive?


On 09/20/2013 02:22 AM, jp charras wrote:
> Le 19/09/2013 17:37, Wayne Stambaugh a écrit :
> ...
>> I've never liked the fact the Eeschema is case insensitive so you'll get
>> no argument from me.  It's just been that way since I've joined the
>> project.  Changing it surely will break some existing projects and
>> libraries.  There is only one way to find out how many things will get
>> broken.  That's one of the reason's I never tackled the problem.  I
>> didn't want to know the answer to that question :).  If you feel up to
>> it, by all means make Eeschema case sensitive.
>>> Certainly fixing eeschema will break designs,  unless somebody can think
>>> of a fix point where eeschema can heal the design.
>>> Dick.
>>>> Also, in cmake there is a KICAD_KEEPCASE option (default off) which
>>>> could be related to/a fix for this.
> Due to the new .pretty lib format which imply a case sensitive footprint
> name, Kicad is currently moving to the case sensitive option.
> I have no problem with that.
> KICAD_KEEPCASE option ON could be the default option (in fact removed).
> This change will have some (minor) issues which are already existing for
> footprint names.
> To avoid annoying issues in eeschema, a case sensitive search in libs
> could be made first, and only for not found components, a case
> insensitive search could be made 

I see your point and that is a good catch.  The first pass must be case sensitive, in case
there are two parts with different case spelled the same.

This algorithm argues for a version of the Collector with a custom Inspect() function.
The Inspect() could do the initial case sensitive component name compare sweep through the
library parts, and when no match is found, add to collector.  Then upon return the caller
could iterate through the collected components and fix them.

Seems like it should happen in the load step.  Lorenzo's idea to fix UI entries is worth
considering also, but I think for the dialog based searching case insensitive compare may
not be harmful as long what is brought back is case correct.  Only when the user types in
a case in correct partname explicitly (not for search) do we need to correct his entry on
a match.

This seems optimal to me.  I am not volunteering however.  Jean-Pierre, we will thank you
in advance for at least agreeing to put it on your to do list.  We know you are working on
many important things, probably most more important than this, and we thank you for your
consistent persuit of excellence.

> with an automatic update of component
> lib names if found, when a schematic is loaded, and also when the user
> want to place a new component.
> This is one of things which are on my todo list, but if there is a
> volunteer to do that ...