Open kothawoc opened 2 months ago
To add to this, I wonder if the app storage directories should just be created at the root with the appID (~/.config/com.someapp/
, ~/.cache/com.someapp/
, etc) instead of being nested under a fyne
directory. Users who go looking for the config files (linux users often do this) may not find it since they're not expecting it to be under a fyne
directory
I'm not sure how this applies to macOS?
When discussing the issue on discord, @dweymouth pointed out that the location was an issue on Macs too:
yeah new APIs could use a new location. A cache API would be especially handy to store things in ~/.cache/... and ~/Library/Caches/... (Mac)
The XDG standard places don't apply to Macs, that information can be found at: https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFileSystem/Articles/WhereToPutFiles.html
I just mentioned Macs as @dweymouth mentioned them, I can update the issue to reflect the Mac stuff, or remove it?
I just mentioned Macs as @dweymouth mentioned them, I can update the issue to reflect the Mac stuff, or remove it?
Well, the title mentions it but the body does not explain. If the source is a chat elsewhere the relevant info should have be pasted in here for people to follow. I can see from the document that cache applies to both. Not sure about data or state on Mac.
To add to this, I wonder if the app storage directories should just be created at the root with the appID
Just be sure we don't simply change location in an upgrade - would result in a lot of lost data.
Checklist
Is your feature request related to a problem?
According to the XDG spec, I should be able to use cache and data directories. https://specifications.freedesktop.org/basedir-spec/latest/index.html
This is also an issue for Macs too, but with their standards at: https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFileSystem/Articles/WhereToPutFiles.html
Is it possible to construct a solution with the existing API?
I don't believe so.
Describe the solution you'd like to see.
I think it would be sensible to some additional APIs used for these, rather than the existing
myApp.Storage().RootURI().Path()
, possibly have aCacheURI
,ConfigURI
,DataURI
andStateURI
. I believe theRootURI
could point at theConfigURI
for the current version so as to be 100% compatable. And the RootURI could be deprecated in v3 or when desired if you wish. For other platforms, they can just point at the same place.