Re: [Kicad-developers] [proposal] Handling conflict between projname-cache.lib and an updated library
Any more thoughts on this from any other devs? If nobody objects, I think I'll get started coding this up in the next day or so. -- Chris On Mon, Mar 23, 2015 at 01:27:35PM -0400, Wayne Stambaugh wrote: On 3/23/2015 1:16 PM, Chris Pavlina wrote: On Mon, Mar 23, 2015 at 01:07:33PM -0400, Wayne Stambaugh wrote: On 3/23/2015 12:12 PM, Chris Pavlina wrote: I like your idea - I proposed it myself, but it was not well received ;) [[snip]] 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. Haha, just kidding, I know :) 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. Actually, I quite like this idea. I know it's more work but it solves the component name clash issues and the user will still be able to use their normal libraries. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [proposal] Handling conflict between projname-cache.lib and an updated library
What I always do myself with my own designs is when I finished the schematic, I add the cache file on top of library list, then remove all other entries. that way even if you reopen the project on another machine, components are still the same. But I agree it would be great if something automatic was implemented to always keep the right component. I find very interesting asking the user what to do when detecting a library change. Le 23/03/2015 18:27, Wayne Stambaugh a écrit : On 3/23/2015 1:16 PM, Chris Pavlina wrote: On Mon, Mar 23, 2015 at 01:07:33PM -0400, Wayne Stambaugh wrote: On 3/23/2015 12:12 PM, Chris Pavlina wrote: I like your idea - I proposed it myself, but it was not well received ;) [[snip]] 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. Haha, just kidding, I know :) 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. Actually, I quite like this idea. I know it's more work but it solves the component name clash issues and the user will still be able to use their normal libraries. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [proposal] Handling conflict between projname-cache.lib and an updated library
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. 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 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 : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp -- S pozdravem Ladislav Láska la...@kam.mff.cuni.cz Katedra Aplikované Matematiky, MFF UK tel.: +420 739 464 167 ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [proposal] Handling conflict between projname-cache.lib and an updated library
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. 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 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 : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp -- S pozdravem Ladislav Láska la...@kam.mff.cuni.cz Katedra Aplikované Matematiky, MFF UK tel.: +420 739 464 167 ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [proposal] Handling conflict between projname-cache.lib and an updated library
On 3/23/2015 1:16 PM, Chris Pavlina wrote: On Mon, Mar 23, 2015 at 01:07:33PM -0400, Wayne Stambaugh wrote: On 3/23/2015 12:12 PM, Chris Pavlina wrote: I like your idea - I proposed it myself, but it was not well received ;) [[snip]] 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. Haha, just kidding, I know :) 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. Actually, I quite like this idea. I know it's more work but it solves the component name clash issues and the user will still be able to use their normal libraries. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [proposal] Handling conflict between projname-cache.lib and an updated library
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 : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp -- S pozdravem
Re: [Kicad-developers] [proposal] Handling conflict between projname-cache.lib and an updated library
On Mon, Mar 23, 2015 at 01:07:33PM -0400, Wayne Stambaugh wrote: On 3/23/2015 12:12 PM, Chris Pavlina wrote: I like your idea - I proposed it myself, but it was not well received ;) [[snip]] 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. Haha, just kidding, I know :) 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. Actually, I quite like this idea. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
