On numerous tickets I see the answer to issues is 'clear the cache'. This isn't a real answer to a larger issue. If the cache is going to need to be cleared every time we make changes to Cura 2 with a new release, users are going to be running into issues non-stop.
- Mentioned In
- rCT1e818fe5d83b: T1175: Fixed logic
rCT318f259bbab8: Revert "T1175: Re-introduce _updateVariantContainer."
rCT09b581bf24dd: T1175: Re-introduce _updateVariantContainer.
rU511e33366987: Revert "T1175: Added removing old cache"
rU4cc4172bbba1: T1175: Added removing old cache
T1183: Not able to use the Save Screen after viewing layers
T1194: Blank 'Open File' Window
- Mentioned Here
- rCTedd0b9c1a63f: Merge branch 'master' into devel
@Steven Yes, we can use different folders for minor releases, but user wit every new update will have "clear" program, without any settings or user profiles. So, this will be not user friendly, we need find another way to solve this problem.
Ultimaker publish only major releases and provide plugins that update old settings to new, but we also use minor releases, and making new plugin every release(everyday) is very bad idea.
Maybe better to raise this issue on meeteng?
@victor_larchenko: I see that cura is actually creating
directories for every subversion. I think the problem is that some older dirs there get loaded instead of the current one. The best way that works for me is to completely remove
all these directories at every new install.
The cache files are all stored on a per user basis. When the application is being installed it is being run as root or adminstrator. We don't know, in general, what users on the machine would want their cache files removed.
The proper solution would be to have the Cura 2 application do this when it runs. Maybe this could be done as a plugin, similar to the way the ChangeLog plugin shows the release notes when a new version of the application is run for the first time. Then we wouldn't need to modify Cura itself (assuming we can get the plugin to run before Cura reads all the settings).
We would need to know what file we want to remove. I imagine we don't want to remove the settings for the printer, custom materials, etc. Or we could just ask the user.
A simpler fix could be to just add a button somewhere in Cura that removes the cache files, probably with a suitable warning and confirmation dialog.
@victor_larchenko we talked about the cache issue more last Friday and think having the cached clearing prompt is going to lead to more confusion. Can you please revert the commit with the cache clearing tool?
In discussion the real fix really needs to be dealing with profile and slicing changes between releases. I think this is something we should address in v3 so I'll leave this ticket open.
@victor_larchenko: I looked through the logs and noticed couple of crashes in cura/Settings/MachineManager.py
The functions that were crashing were: resetMachine and isMachineChanged they both were referencing non-existent function:
_updateVariantContainer. After looking at history it was removed in rCTedd0b9c1a63f816895c0a4dc402f44117b2addd6 so
I've re-introduced it and now logs a much more cleaner than they used to be with no crashes.
I'm not sure if re-introducing this function is the right thing to do though, so could you please check it?