Yup, that's what I proposed. On Mon, Jul 16, 2018 at 9:16 AM Nick Østergaard <oe.n...@gmail.com> wrote: > > Why does this need to be so complicated? > > I think we could just rename the kicad config folder created and > searched by kicad from "kicad" to "kicad5" and be happy in the 5.x > branches. > Den man. 16. jul. 2018 kl. 15.11 skrev Bob Gustafson <bob...@rcn.com>: > > > > There is a tool which allows developers to quickly switch between different > > versions of Ruby (and their associated gemsets). > > > > Perhaps it could be used for KiCad? Or perhaps just some of RVM's ideas > > could be adapted for KiCad > > > > https://rvm.io/ > > > > > > On 07/15/2018 09:52 AM, Adam Wolf wrote: > > > > I guess the fact that environment variables are tricky to set for graphical > > applications for the Mac may be a blessing here :) > > > > Should we try to package a macOS version that installs to > > /Applications/KiCad5 and /Library/Application Support/kicad? > > > > Adam > > > > On Sun, Jul 15, 2018, 2:41 AM Eeli Kaikkonen <eeli.kaikko...@gmail.com> > > wrote: > >> > >> There are some people in the user forum who have spent time with these > >> v4->v5 problems, including me and Rene. The consensus about the > >> environment variables seems to be what Rene already said, that they should > >> not (without explicit user intervention) be set for the system, but from > >> KiCad itself. Nick confirmed that the current v5 installer won't set them > >> by default. They are still a problem if they have been set by v4 installer. > >> > >> su 15. heinäk. 2018 klo 5.04 Strontium (strnty...@gmail.com) kirjoitti: > >>> > >>> I honestly think each major revision of KiCad should be considered a NEW > >>> program, installs to a new place has its configuration and libraries all > >>> in a new location. Only Incremental updates 5.0 -> 5.1 should be > >>> considered upgrades. > >>> > >> > >> I agree. It's probable that many users will want to continue with v4 for > >> old projects but v5 for new, and in the future the same thing will be true > >> for v5 vs. v6, because they break the file/project compatibility. But > >> where the compatibility is kept it's more likely to be considered as just > >> an upgrade. > >> > >>> > >>> Kicad configuration isn't complex or onerous so if a user wants to bring > >>> a Kicad4 config into Kicad5 or 6 or whatever, then they do that > >>> themselves, otherwise after install Kicad5 is a fresh blank sheet with > >>> no relationship to anything that happened on the users computer in > >>> Kicad4. I am not familiar with the issues on Windows, but I would have > >>> thought now this is mostly a packaging issue only?? > >>> > >> > >> I tried modifying the Windows installer, I only needed to replace some of > >> "KiCad" strings with "KiCad5" and it can install v5 alongside v4 > >> independently. The only problem is the configuration and the environment > >> variables set by v4. They can be handled with a startup script. See > >> https://forum.kicad.info/t/does-v5-have-to-overwrite-on-install/11282 for > >> some details. > >> > >>> I also agree if it can't work this way now on Windows, then its all a > >>> bit late for V5, but maybe V6 can consider itself a new program distinct > >>> from V5. This would also help with testing, because users could use V5 > >>> for daily work, but also easily install a V6 daily side by side. > >> > >> > >> All this could be done with the Windows installer, provided that a startup > >> script would be offered. > >> > >> To make this all, at least the startup script, as simple as possible I > >> would suggest one (or three) small changes to KiCad (for 5.1, or even > >> 5.0.1?). Add command line options --config=/path/to/config and > >> --ignore-env-vars. The former is obvious and would override > >> KICAD_CONFIG_HOME system environment variable. The latter would make KiCad > >> ignore all system environment variables and use the current internal logic > >> and the path settings UI instead. That way the old variables could be left > >> for v4 and the newer versions would be completely independent if the > >> command line switches were used. The command line switch for the config > >> path would be mostly for convenience. In Windows starting a program with > >> custom environment variables is tedious and error prone to write (see the > >> above mentioned thread). Command line switches are much easier. > >> > >> It could also be possible to make --ignore-env-vars=true by default. > >> Sharing the environment variables would be a special case if the user > >> wants that. > >> > >> The general problem with using system environment variables is that they > >> are good for situations when there's only one version of a program on the > >> system, and/or several processes share the same variable values. Neither > >> of them is true for parallel installations of KiCad. > >> > >> Eeli Kaikkonen > >> _______________________________________________ > >> 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
_______________________________________________ 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
