On 3/23/2015 12:12 PM, Chris Pavlina wrote: > I like your idea - I proposed it myself, but it was not well received ;) > > (Bah, still getting used to the fact that Launchpad doesn't set reply-to) > > On Mon, Mar 23, 2015 at 05:06:08PM +0100, Ladislav Laska wrote: >> Hi! >> >> That is unfortunate. I really would like this: use the cached version, >> unless >> you choose to update from library (in a global menu, or per >> component). This is >> really handy, since you don't have to do anything, unless you >> specifically want >> to (for example, there is a new, better symbol), and you can still use >> the up to >> date library (for new parts). A win-win situation.
Please see the discussion here on why this will not work. https://bugs.launchpad.net/kicad/+bug/1435338 I see no point in replacing one bug with another bug that doesn't fix the underlying problem. >> >> On Mon, Mar 23, 2015 at 11:52:48AM -0400, Chris Pavlina wrote: >>> When loading an old schematic, it's fairly common for it to be >>> broken, if >>> symbols have changed significantly in the libraries. An example: >>> https://i.imgur.com/7cVBneA.png >>> I've thought of a major improvement to this solution. This is why I asked you to propose this on the developers list. Some times you have get other peoples input to come up with a better solution. Rather than just copy the cache file, rename all of the footprints in the copied library with a prefix or suffix, i.e. 74LS00 in the cache becomes 74LS00_SCH in the new library. Then rename all the components in the schematic accordingly if the user chooses the new library option. This way there will be little chance of conflicting component names and the library search order is less likely to be an issue. This gives you the best of both worlds. You keep your existing components in the schematic and you can still use the updated components from the your libraries if you so choose. Obviously this still wont fix the library search ordering issue but it would be a more robust solution. Everyone who isn't aware how components are loaded from libraries and end up in your schematic, please understand that this is a stop gap measure and will not fix the underlying issue with library search ordering. This issue will not be fixed until after the next stable release because it requires modification to the schematic file format which is going to be replaced with an s-expr format like Pcbnew along with a new component library file format and component library management tool during the next development cycle. Also please note that this topic is not open to discussion at this time. We've beat this horse to death already. Please grep the developer mailing list archives for more information on the new schematic and component library file formats. I will open the topic up on last time for fine tuning before development begins. >>> A workaround suggested by Wayne is to make a local copy of the >>> projname-cache.lib file, and add it to the project as a library, at >>> the top of >>> the list. This way, components in it will override the system libs. >>> >>> I think it will be friendlier for newer users if we can detect this, >>> and offer >>> to solve it. What if we were to display something along these lines, >>> when >>> loading a schematic where projname-cache.lib has symbols with >>> significant >>> differences from system versions? >>> >>> "This project appears to use different versions of some components >>> from what >>> is installed on your system. What would you like to do? >>> >>> [] Update this project to use the new components. There may be parts >>> that >>> longer fit correctly, and you will have to fix them yourself. >>> >>> [] Create a new library containing the versions of the components >>> used in this >>> project, and add it to the project. >>> >>> [] Choose manually for each component. >>> >>> === >>> >>> [] Never ask me again, I can handle this myself. >>> " >>> >>> The first option would do what it does now - components will be >>> loaded from >>> the system libraries. The second version will save a copy of >>> projname-cache.lib into the project directory and add it to the top >>> of the >>> library list. This may require a way to make sure that a library is >>> loaded >>> directly out of the project directory rather than checking the entire >>> search >>> path - I'd think this could be relatively simple, perhaps load from the >>> project directory if a library filename in the list starts with ./ ? >>> The third >>> option will display all the conflicting components with a list of the >>> references using them, allowing only *some* of them to be exported to >>> the new >>> library. >>> >>> I know that there are plans to completely change the way libraries >>> work, but >>> this problem really seems to confuse some beginners, and this seems >>> to me like >>> a decent stopgap. What do you think? >>> >>> Chris >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >> >> -- >> S pozdravem Ladislav Láska >> <[email protected]> >> Katedra Aplikované Matematiky, MFF UK tel.: +420 739 464 >> 167 > > _______________________________________________ > 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
