Maybe too late, but why does V5 have to overwrite the current install, or try to install to the same location as V4? IMO, it would be a lot more convenient if V5 just installed in its own location, always as a brand new software with no knowledge of any other versions. Just install to kicad5 or something, and when V6 comes out, it can be kicad6, etc.
This works really well for other software, and seems like it would solve a lot of problems I have been reading about when people are trying to move from V4 to V5. Iām in that boat right now. I really want to try V5, but Iām also finishing a project in V4 and I donāt want to change this close to being finished. However, if I could have both versions installed, and just make a copy of my libs, project, etc. specific for V5, then I could have both and try V5 while continuing to wrap up in V4.
Am I missing something obvious with this solution? It seems like making the install of major versions completely separate would solve a lot of problems and frustrations.
Given how different the versions are, I think itās a great idea to treat v4 and v5 as seperate programs, with seperate libraries and workspaces. People can transition over to the new version and shouldnāt have to fear the new version messing up their work or settings.
Is there something about V5 itself that would make it difficult to have it be its own install? Or are all the problems confined to the install, i.e. the installer tries to place V5 in the same locations used by V4? Also, is there any way to get this considered? I think V5 is very close to release, and I have no idea who is managing the installer and such?
Yes, this is problematic, and the problems are in the installer.
No, I donāt think so.
Hereās the source code for the installer:
I already filed a generic issue about v4->v5 transition. Maybe it could be a good idea to discuss about the perceived problems and possible solutions here first. The installer code isnāt difficult, but editing it would still require learning and specific knowledge.
I installed KiCad 4 with default settings. Everything is pre-selected. It installs KiCad to C:\Program Files\KiCad. It sets three environment variables: KICAD_PTEMPLATES, KISYSMOD and KISYS3DMOD.
It installs Start menu items. It also installs the uninstaller into Windows Control Panel.
Itās easy to install KiCad pre-5 (nightly builds) to a different location, just add ā5ā to the end of the path. The warning about overwriting the old installation can be ignored. This, however has some side effects because the version pre-5 installer ignores the old installation. It overwrites the start menu and the Control Panel uninstaller. Version 4 can still be used fully by opening it from Program Files\KiCad\bin\ and the uninstaller works, too, from Program Files\KiCad.
With default installation settings the environment variables come from KiCad 4.
Thatās a problem, as we already know. But it looks like the variables can be safely removed from the environment (I did it with regedit.exe) if they had the default values. KiCad 4 has saved the correct paths into the configuration. I havenāt tried yet what happens if custom locations are set with environment variables and then those are unset.
Here is a simple .bat script (write it with e.g. Notepad):
set "KICAD_CONFIG_HOME=%APPDATA%\kicad5"
start /d "C:\Program Files\KiCad5\bin\" kicad.exe
Save it as kicad5.bat and you can start it as a program.
Now thereās still the unfixed bug which sets wrong path for some important variables, see https://bugs.launchpad.net/kicad/+bug/1775796. You just have to set them manually, either in the KiCadās Configure Paths dialog or in the startup batch script.
Iām probably anticipating a bit, but there are chances we will face the same issues with the future v6. There should be version-dependent KICAD_CONFIG_HOME variables (like KICAD_CONFIG_HOME_V5, KICAD_CONFIG_HOME_V6 etc.) which take precedence over the general purpose KICAD_CONFIG_HOME. Once set, this wouldnāt require any batch file to launch correctly any version (v5 or future)
I donāt think we should use environment variables at all, it is an obsolete 1980s way of doing things and should be referred to the trashcan of history along with config.sys and autoexec.bat. On Windows it is particularly a PITA for users to deal with.
Modern applications install major versions into separate installs, and when first run give an opportunity to set up a workspace where settings are stored. Anytime later the user can create a new workspace, or switch between them. No environment variables necessary!
This is another one of those areas where someone needs to write down a coherent strategy for KiCad to follow, rather than add environment variables, search paths and hard coded default paths to non-existent folders, all in a piecemeal fashion to solve immediate problems which inevitably lead to a spaghetti style mess. It is a non-glamorous job though so no one wants to do it.
If you have a version-specific home directory (aka config directory) like weāre both suggesting, you can alter the kicad_common file (located in this directory), which includes these paths, in the [EnvironmentVariables] section. IMHO, a home directory per version is enough. At least, itās a good start.
Thatās true, KICAD_CONFIG_HOME would be enough. But if we accept the fact that KiCad now has other variables, too, and that KiCad 4 installer has set them, thereās no other option than to override them with something. Unfortunately thereās no way to override them except setting them from the environment. But if KiCad internals are changed the story is different.
I think, but Iām not 100% sure, that KiCad caches the standard KiCad variables, but user vars e.g MY_SYMBOLS must be configured directly in KiCad. The upshot is that KiCad v4 should have evyerthing saved in kicad_command and still work ok after deleting all env vars from user/system profiles. But, I havenāt verified that.
I started writing a procedure today but I left it at work I looked at the installer script and think I could adapt it, I just have very little time to do any work on it.
Iām not sure if I understood you correctly, but if by āuser varsā you mean that any arbitrarily named variable can be used in fp-lib-tables and sym-lib-tables, they can be set just like other variables: either from the environment or from the KiCad UI, and the former overrides the latter. However, it behaves oddly: If you set the variable from the UI, then override it with environment variable, then open and close KiCad twice, the variable vanishes from the configuration/UI.
KiCad doesnāt ācacheā environment variables. If the variable (KISYSMOD etc.) is set from the environment when KiCad is run for the first time, it doesnāt save the value in configuration. I think what happens is that if the value hasnāt been set yet, KiCad tries to find a sane value for it and then saves it to configuration.
Not using environment variables would be ideal IMO. The installer can create a data directory or specific config file that contains anything that environment variables would provide. This would also be operating system independent and easy for a user to change if they want. Always having the version as part of the path/filename, i.e. kicad5, kicad6, etc. would keep it unique and allow multiple versions to easily co-exist.
For the problem of the executable knowing where to look for the config file at startup, I can imagine two possibilities:
Use each OSes way of providing a software specific parameter. On Windows this would be the registry. On Unix is would be a dot-file in the users home directory. Not sure on the MAC, but they must have something.
Create a start-up icon during install that passes the config file location as a parameter to the executable.
I am willing to help and advocate for this change, since I believe now is the time to get it in. I just have no idea what needs to be done or who is responsible for actually allowing or making the change? I do know one thing though, if it does not happen now before V5 is released, it will not happen for the life of V5.
Ultimately, IMO, the install of V5 should not touch V4 or depend on anything related to V4.
I think so, since the registry entry would only be used to point KiCAD to the location of the config file, and the config file would live in the userās home directory on their OS. I can imagine something like this:
Installer: Where do you want your KiCAD5 config?
User: accepts the default or navigates to a directory
Installer uses supplied directory to write: kicad5.config file containing all kicad parameters that normally come from environment vars, etc.
Installer writes supplied directory path to registry: HKCU/SOFTWARE/KICAD/KICAD5/CONFIG_PATH or some such thing. On Unix it would create a file in the userās home dir called .kicad5_configpath with a single line that contains the path to the config file. Or maybe on Unix you can just skip that since there is always a user home directory and just use .kicad5.config directly. Not sure what to do on the MAC.
If the Icon approach was used, the installer would include the specified path as a parameter to the executable.
Also, KiCAD should not try to find any reasonable settings going forward. If it cannot find its one and only config file, it should prompt the user to navigate to the config at startup, or refuse to start. The config should also contain a parameter that identifies the kicad version, so the executable knows it is using the right config.
Edit: None of this would require admin rights. And any changes from within KiCAD would simply be written to the kicad5.config file, which means they would take effect immediately if changed within KiCAD, and of course used every time KiCAD is started. This also allows multiple users on the same computer to have their own settings. It would also be nice if KiCAD wrote all the UI and other settings to this one file, which would make moving your settings, or migrating to a new version, really easy!
I donāt know anything about the NSIS installer, but looking at install.nsi I get impression that making it version specific would need only changing some āKiCadā texts to āKiCad5ā. Adding batch files etc. would require more.
Before going further in the details, maybe the first step would be to fill a bug report / suggestion on the tracker to draw attention from the devs, and hope something will be done before the v5 is released.
I looked at the installer script and think I could adapt it, I just have very little time to do any work on it.