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. _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
