kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 8/19/2014 3:23 PM, Dick Hollenbeck wrote:
> 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.
> 

It looks like the type ahead find sorts the library list which is a
no-no.  It needs to find the first R in library order defined by the
user.  I haven't looked at the code Henner wrote so I don't know how
much work it will be to fix it.