Anyway, when you start working with the new system and beginning to know its content, you quickly discover that typing a partial or complete footprint name in the search box gets much faster than going through the whole list, looking for it. I am not sure if such a sorting mechanism would be that beneficial.
If offline use is required, then the fp-lib-table.forpretty can be used along with the new footprint format. On Mon, Nov 3, 2014 at 11:13 AM, LordBlick <[email protected]> wrote: > In response to a message written on 03.11.2014 16:17, from Wayne Stambaugh: > >> On 11/3/2014 10:06 AM, LordBlick wrote: >> >>> In response to a message written on 03.11.2014 15:27, from Carl Poirier: >>> >>>> Why use the legacy footprints (…)? >>>> >>> In legacy footprints have stay cleanup by user preferable order(I've own >>> footprint editor developed much time, then new, messy format arrives). >>> Alphabetically sorted is not the same, that somebody needs… It's bad >>> idea, because it's easy to end with many doubled/tripled footprints. >>> >>> Duplicate footprints are no longer an issue with fp-lib-table. Prior to >> fp-lib-table, is was possible to load the wrong footprint if the path >> search order was not correct. This cannot happen with fp-lib-table not >> matter how many duplicate footprint names you have. >> >> I'm not sure what "messy" new format you are speaking of but the current >> board and footprint library formats are significantly better the legacy >> format and the fp-lib-table is far superior to the old path search >> method of looking up footprint in libraries. >> > I mean, it would be nice if every directory has a file named something > like ".sort", which would result in the footprints of the library would be > displayed in the desired, not necessarily alphabetical order(Something like > body of „$Index/$EndIndex” legacy format). Absence of the file, or its > invalid format, would result in only the default sorting. > For example, I have a library of IDC, in which I have the elements are > arranged according to the amount of pins, when the names of the version > with the hooked-snaps start with SCM, not IDC. This is the true order, when > you can sequentially arranged according to your preferences. Until I had my > own program to manage legacy library, I had no problem with it - all the > elements are in one file, so inevitably they were stored in the desired > order. > Such a small blueprint. ;) > -- > Best Regards, > LordBlick > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
