kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 08/19/2014 01:35 PM, Wayne Stambaugh wrote:
> On 8/19/2014 1:53 PM, Dick Hollenbeck wrote:
>> On 08/19/2014 07:33 AM, Wayne Stambaugh wrote:
>>> On 8/18/2014 5:46 PM, Dick Hollenbeck wrote:
>>>>
>>>>>> I will do the "workaround" reordering of my libraries.. not a problem for me now that I know how it works..
>>>>>
>>>>>
>>>>> I think the sort() call has to go, so I now think you discovered something.
>>>>>
>>>>> Should have a fix in minutes.
>>>>>
>>>>> When the foundations get simpler, so do the algorithms.
>>>>>
>>>>>
>>>>> Dick
>>>>
>>>>
>>>> This one simplifies everything by removing the sort() and the sortOrder support.   The
>>>> library list is loaded in the proper order, I know of no reason to sort it.
>>>>
>>>> Guys please try this one instead of other, and comment.
>>>>
>>>> It is even simpler yet, and gets rid of the sort-order global which *would not fly* in a
>>>> multiple project situation.
>>>>
>>>>
>>>> Dick
>>>>
>>>
>>> Dick,
>>>
>>> That fixed it.  Thanks again for the quick response.
>>>
>>> Wayne
>>
>>
>> I committed that.
>>
>> There is still a design flaw in the part picker.
>>
>> It does not consider the current nature of how parts are actually chosen by eeschema.
> 
> It looks like the sorting needs to be eliminated from the part picker
> dialog in order to yield the correct part in the schematic even though
> it will not be as nice to use.  Otherwise we are right back to the same
> problem.  I'm surprised this issue hasn't been raised before now.
> 
>>
>> If I have part 'R' in mylib, and it is also in library devices, it shows me devices as my
>> top and only candidate as I type in 'R'.
>>
> 
> If the picker can select part R from a library further down the library
> stack, that's not the one that will be shown in the schematic.  Maybe as
> a stop gap measure we should check for duplicate part names in the
> picker and warn the user that part FOO in library BAR will be used but
> there is also a part FOO in library BAZ that may be the part they want
> and that the library search order must be changed in order to use the
> part FOO from library BAZ.


My problem is not when I choose a library and then a part.  My problem is when I type the
initial letters of the part name.

Yours is an OK solution for the guy who picks the library then the part within it.  This
is not the problem I have.

Your is not a good solution for my problem.   So lets think in terms of two problems.

If the part named 'R' is what I want, and there is no friggin way for me to select
anything but the 'R' returned via the search path, then the non selectable 'R' should not
be what is shown.  Then I can sidestep the warning.

If you want a nag warning for the second case, that would be fine.  Ultimately the UI may
be re-usable after there is a sane part lookup strategy.  But currently is does not match
with the real part lookup strategy allowed.

The type-ahead lookup needs to mimic the part lookup strategy. This is a partial re-write
and redesign, not just a nag window for my 'type-ahead' case.