XDG Base Directory Specification

[openBrain]

For your convenience the user.cfg will be copied from the old to the new location but it's up to you to manually transfer all other files to their new destination. This affects 3rd party macros and workbenches you have installed via the add-on manager.

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 ?

[wmayer]

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).

[openBrain]

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.

OK. Important thing to me is that users are aware of that behavior.

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).

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.

[onekk]

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.

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"

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.

[adrianinsaval]

0.20 release should come with an explanation of how to migrate manually.

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.

[user1234]

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.

Nice, just one thing: i can not edit the path.

0.png (95.04 KiB) Viewed 4526 times

Many thanks for your work!

Greetings
user1234

[wmayer]

Nice, just one thing: i can not edit the path.

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]

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.

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 parameters

what do you think?

[chennes]

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.

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.

Also, if it were configurable the user could map it to /tmp and this IMO can be quite harmful

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.

[chennes]

what do you think?

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.