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

Reply via email to