Perhaps this name should be configurable ("overridable" ?) by an env
variable ?Le 12/04/2018 à 15:29, Strontium a écrit : > kicad5 > kicad6 > etc etc works for me. I am not wedded to my suggestion, it was > illustrative only. > > For backward compatibility, "kicad" would be for kicad4 because that's > what it uses now, so there would be no "kicad4". > > I agree that a user selectable configuration directory would be useful > for some people. It should not be difficult to do either, once there > was a consensus on the how of it. However, being cognizant of how late > in the release stage for V5 it is, this proposal to only change the base > directory is to allow kicad4 and 5 to coexist (and nightlies) in the > absolutely simplest possible way, without creeping the scope, or > creating untested code paths or boundary cases. I also don't feel that > it creates a burden going forward, or precludes the development team > expanding on this or any other changes to this area that are felt > desirable. I think we should push anything more exotic than just using > a new base configuration directory to version 6. > > Steven > > On 12/04/18 18:39, Clemens Koller wrote: >> I would pretty much vote to use the IMO more common naming scheme for >> major package versions: >> >> kicad (the current one installed from the repository of your choice) >> kicad4 (currently: 4.0.7) >> kicad5 (currently: 5.0.0-rc2-dev...) >> kicad6 (tbd.) >> >> ...avoiding the ".v5" i've seen lately. >> >> I believe there is less demand for different minor versions installed >> next to each other, however it would be a nice-to-have. >> (So... a user-selectable configuration might help: $ kicad -c >> projectconfig.cfg) >> >> Regards, >> >> Clemens >> >> On 2018-04-12 09:33, Strontium wrote: >>> After considering my patch, what about the following proposal: >>> >>> Just change the hard coded string in common.cpp (at around line 243) >>> from: >>> >>> cfgpath.AppendDir( wxT( "kicad" ) ); >>> >>> to >>> >>> cfgpath.AppendDir( wxT( "kicad.v5" ) ); >>> >>> (or some other string) >>> >>> Thats it. Then Kicad Version 5 will have a unique configuration >>> directory that will not conflict with version 4. >>> >>> If an end user wants to bring their kicad V4 configuration over to v5, >>> they just copy it themselves. Otherwise it starts with a brand new >>> blank configuration. Alternatively packaging might be able to copy it >>> over. But i don't see any real need to do it for the user at that >>> stage. Its just a complication. >>> >>> Then when the development branch is forked, just rename this again to >>> something like: >>> cfgpath.AppendDir( wxT( "kicad.v6dev" ) ); >>> >>> (or whatever). >>> >>> Then an end user can have V4, V5 and a Nightly all on the same machine >>> and configurations won't conflict. >>> >>> Anything more exotic can be deferred to V6 development. >>> >>> Steven >>> >>> >>> >>> >>> On 08/04/18 13:33, Carsten Schoenert wrote: >>>> Am 07.04.18 um 17:34 schrieb Strontium: >>>>> Attached is a patch for discussion only. >>>>> >>>>> Its the minimum change I could come up with to implement a unique >>>>> version specific config directory. >>>>> >>>>> Nick mentioned changing XDG_CONFIG_HOME, that will not work on Windows >>>>> or Mac. >>>>> And on Linux, etc it will change from "~/.config/kicad" to >>>>> "~/somethingelse/kicad" which would work, but isn't a very friendly >>>>> naming scheme. >>>> Changing XDG_CONFIG_HOME itself wouldn't be correct. XDG_CONFIG_HOME is >>>> pointing to '$HOME/.config' and XDG_DATA_HOME is referencing to >>>> $HOME/.local/share. >>>> >>>> I'm sure Windows and Mac have similar variables for the folders that >>>> should contain the logical same content. >>>> >>>> The path to the KiCad user config must based on such variables plus the >>>> preferred name for the config folder, so like kicad-5 (for KiCad5) and >>>> kicad-6 (for future version KiCad6) and kicad-nightly (for devel >>>> version). GTK is doing this for a long time. >>>> >>>>> $ find ~/.config -type d -name gtk* >>>>> /home/carsten/.config/gtk-3.0 >>>>> /home/carsten/.config/gtk-2.0 >>>> If KiCad will introduce some version specific user config and data >>>> folders (which I appreciate to see) it will be needed to configured by >>>> the build environment and not hard-coded in the binaries. The variables >>>> can be overwritten with some additional value given while starting the >>>> applications. >>>> >>>> e.g. >>>> take the default folders >>>> $ kicad >>>> >>>> override the setting for the default config etc. >>>> $ KICAD_XDG_CONFIG_HOME=/my/special/folder kicad >>>> >>> >>> _______________________________________________ >>> 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
