Maybe I'm wrong, but reading the code I think there is a quirk that (super)users should be aware. If you use the new locations and delete the user.cfg file (we often advise to do so to reset the FC config) but still have the old location files -- they don't seem to be deleted by the new commits --, the new user.cfg file created at startup won't actually be a blank one but a copy of the former one (from old location). Am I correct ?
XDG Base Directory Specification
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: XDG Base Directory Specification
Re: XDG Base Directory Specification
That's correct. But it's rather unlikely that both config files get corrupted. To simplify the deletion we can add a button to open a file manager window at the new location.
The function to copy the file from the old to the new location will be present only temporarily. I would remove it after a while (maybe some months).
The function to copy the file from the old to the new location will be present only temporarily. I would remove it after a while (maybe some months).
Re: XDG Base Directory Specification
OK. Important thing to me is that users are aware of that behavior.
IMO either the function should be present in 0.20 release version (so people using only stable will have their preferences migrated) or 0.20 release should come with an explanation of how to migrate manually.The function to copy the file from the old to the new location will be present only temporarily. I would remove it after a while (maybe some months).
Re: XDG Base Directory Specification
Ar ethis change affect the way you are using AppImages:
I usally use this script to launch different version of FreeCAD, like stable, development and LS3.
So all the settings in the example above will go into "/home/common/FreeCAD/config-dev" or other dirs for other versions.
But I've noted if I don't make modifications it seems that also it load files in ~/.FreeCAD/ and I have made this dir a symlink to another dirs to use them across two different distributions.
Regards
Carlo D.
I usally use this script to launch different version of FreeCAD, like stable, development and LS3.
Code: Select all
export FREECAD_USER_HOME="/home/common/FreeCAD/config-dev"
urxvt -T "FreeCAD-launcher" -e "/home/common/FreeCAD/FreeCAD_weekly-builds-26202-Linux-Conda_glibc2.12-x86_64.AppImage"
But I've noted if I don't make modifications it seems that also it load files in ~/.FreeCAD/ and I have made this dir a symlink to another dirs to use them across two different distributions.
Regards
Carlo D.
GitHub page: https://github.com/onekk/freecad-doc.
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.
Blog: https://okkmkblog.wordpress.com/
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.
Blog: https://okkmkblog.wordpress.com/
- adrianinsaval
- Veteran
- Posts: 5544
- Joined: Thu Apr 05, 2018 5:15 pm
Re: XDG Base Directory Specification
IMO this would be best to avoid such unwanted behavior, it's sometimes hard enough to get people to understand how to clear their config, explaining that they might have to do it twice because the old configs got copied over again will be a PITA. I suggest providing macros to migrate config, macros and addon so they are copied at the users discretion. Optional symlink creation to keep configs in sync in case it's desired would be neat too.
I do have to ask that the auto created macro path parameter be handled please, without user intervention it is keeping the old folder in use instead of the new one. It's bound to create a lot of confusion when the new documentation will talk about putting macros in one folder that will not get recognized by FreeCAD unless you clear a parameter you never explicitly set.
Re: XDG Base Directory Specification
Nice, just one thing: i can not edit the path. Many thanks for your work!wmayer wrote: ↑Mon Nov 15, 2021 10:57 pm git commit d5726bd7af5f9a restores /tmp for temporary files (App.getTempPath()) and adds a new function to access the path to the cache (App.getUserCachePath()). At the moment only the document's transient directory will be created in the cache directory.
Greetings
user1234
Re: XDG Base Directory Specification
It's not intended to make this path configurable. As said above at the moment only the document's transient directory will be created there and actually it shouldn't happen that it will be filled up with a lot of trash.
Also, if it were configurable the user could map it to /tmp and this IMO can be quite harmful because when the user clicks the "Check now..." button (or the automatic check at start) and the size exceeds the defined limit a dialog comes up where the user can clean the directory. However, in /tmp many other programs put their files there and I don't know what will happen if they got deleted.
As said above the function App.getTempPath() again returns /tmp by default so that any operation using it won't clutter up the disk. At the moment there still is a way to configure the Temp path as a workaround to avoid to automatically delete the transient directories if after a crash a reboot was needed.
Since documents use the cache directory now the workaround can be removed.
Further up you wrote that FEM may create huge mesh files. However, these files still will be written to /tmp and not to the cache directory.
- adrianinsaval
- Veteran
- Posts: 5544
- Joined: Thu Apr 05, 2018 5:15 pm
Re: XDG Base Directory Specification
Another option could be to use a new parameter name for 0.20 and ignore the old one, and this time around don't autofill the parameter, let it be only used if explicitly set by the user like most other advanced parametersadrianinsaval wrote: ↑Tue Nov 16, 2021 7:03 pm I do have to ask that the auto created macro path parameter be handled please, without user intervention it is keeping the old folder in use instead of the new one. It's bound to create a lot of confusion when the new documentation will talk about putting macros in one folder that will not get recognized by FreeCAD unless you clear a parameter you never explicitly set.
what do you think?chennes wrote:
Re: XDG Base Directory Specification
I am planning on moving the AddonManager's cache to this location as well: it also should not be very large, of course, but it reminds me that we don't know what other Addons will use the cache for.
I think we can work around this by always creating a subdirectory inside the specified directory, and only deleting that subdirectory. The user does not expect to be able to control the fine details of the cache structure, so if everything actually is stored in $USER_SPECIFIED_DIRECTORY/FreeCAD_Cache instead of directly in $USER_SPECIFIED_DIRECTORY I think that would be OK.
Re: XDG Base Directory Specification
I think the AddonManager should handle migrating from the old structure to the new, optionally leaving a copy in the old location so that installed older versions of FreeCAD don't lose their macros and workbenches. We can't go back in time and fix the fact that the parameter is being written automatically by the Macro dialog, so it always looks to FreeCAD like the user has set a custom directory for this. So we cannot just do the migration without asking first, but I think it would be nice to offer the ability to do the migration by just clicking a button in FreeCAD, rather than digging around in your filesystem manually.