Feature request "own hidden folder" for devl Versions

[herbk]

Hi all,

atm FC uses for storing preferences the same .FreeCAD folder.
Sometimes this makes, or could make, some trubble, if things stored at this folder are different. - Or, in other cases, if i want to have different setups in stable and devl version.

My sugestion is to use a own .FreeCAD-devl folder for it.

[kisolre]

You could already do that by specifying command line parameters to the executable: Start_up_and_Configuration

[herbk]

yes, but you have to know that... I don't and i'm pretty sure a lot of user which use a stable and a devl version at same machine don't know it to.

And im in mind, that different .FreeCAD-devl folders things make more easy for the developers to.

[Kunda1]

yes, but you have to know that...

Really good point. I constantly see that people say that different versions of FC can work on the same machine but do not mention this important distinction. I wonder if we should have a test to check and ask the user if they want to use the current .dotfiles they have or create a new one and associate it to this instance of FC?

[jmaustpc]

I am not sure if that is a good idea from a debugging point of view. We need to know if something in an older version config file causes problems in the dev version. My understanding is that the older FreeCAD on finding an unrecognised option (from the dev version) should just ignore it.

[kisolre]

Since I try to run always the latest dev build having different config for each version will be real inconvenience. I download the build, extract and move everything to specific folder. I have a shortcut to there for easy start. It will not be a bug hassle to create different shortcuts with different startup options if one needs them.
If you have different config folders and are not informed about that then when you run dev version to check if a problem is fixed there will be questions "i had this option set, wb installed, .. " and they are missing when i run the dev version.

[chrisb]

I am in most cases very happy that different FreeCAD versions use the same config files; especially the recent files list makes it easy to test the same file on different versions.

My understanding is that the older FreeCAD on finding an unrecognised option (from the dev version) should just ignore it.

Remembering FreeCAD's behaviour during the switching to and fro between 0.16 and 0.17 I'm pretty sure that's how it works.

[ifohancroft]

I am in most cases very happy that different FreeCAD versions use the same config files; especially the recent files list makes it easy to test the same file on different versions.

I agree with this and also, I don't think it's the software's job (not just FreeCAD but in general) to make it easy for the user to run multiple versions on the same machine at the same time. That is why such software as GNU Stow exist, also FreeCAD, like mentioned above, has the option to let you point it to other config.
So I am against the feature requested in this request.

[chrisb]

We often promote to use several versions on the same computer. So I can understand that it should be more comfortable to have different config files.
The current procedure for installing another FreeCAD version is very simple, just unzip7 an archiv. Since there is no installer involved it is not possible to change the calling parameters. And it is probably impossible to do it from a running FreeCAD.

I see one possibility though: FreeCAD can look first in its current program folder if a config file is found, and next in the common user place (%APPDATA% on Windows, ~/.FreeCAD on Linux).
In the Preferences this could be indicated and swapped.

[jmaustpc]

In theory, it should be possible to create a more advanced FreeCAD configuration handling system (FreeCAD configuration manager). After FreeCAD has been started, It could allow saving, naming, copying and creating the default set of a configuration.

However for some aspects of configuration, FreeCAD requires a restart.

So after doing the first part and saving a new set of configuration options, you would then have to restart FreeCAD to reliably use the complete set of config changes.

So then someone could write a small program "FreeCAD launcher" that one runs to start FreeCAD rather than starting FreeCAD directly, this launcher could behind the GUI just be a fancy way of adding the command line launch options of FreeCAD, including which set of config parameters to use. It could also offer the other start time FreeCAD options, like no GUI, create log, etc.

Creating a FreeCAD launcher as a separate application could do the above, of course it could be incorporated into FreeCAD which would mean it is there for everyone regardless of whether or not they wanted the extra complications and probably clicks, to start FreeCAD every time.

Jim