Decouple directories from persistence in eframe
It is now possible to enable the persistence feature without depending on the directories crate, for uses who wish to provide their own paths from another source.
When the directories feature is not enabled, a simpler naive approximation of its output is used, which covers the most common target systems.
- Closes https://github.com/emilk/egui/issues/4884
- [x] I have followed the instructions in the PR template
Good idea - this should be documented somewhere for users who will search for it
Good idea - this should be documented somewhere for users who will search for it
I fixed the comment style in the Cargo.toml. Now it should be automatically added to the Feature Flags section in the docs, thanks to the document-features crate. Thank you.
@emilk which part do you want to be extracted?
Basically all the code that was added in this PR :)
Just started a bit @YgorSouza if you want I'd be happy to get some help via PR or whatever :-) https://github.com/bircni/file_storage
Issue tracker should be different in this line: https://github.com/bircni/file_storage/blob/1fbec8ed8c3d853a99cde7bab33a7f17eaf6bc79/src/os.rs#L73
The question is what to do with the os.rs ?
Put it in the crate too or get it via egui as a dependency
Do we really want to make a new crate just for that? I mean, previously eframe was getting all this code from the directories crate, but the linked issue asked to remove it because the author added an MPL-2.0 dependency that could be replaced by a single line of code, and refuses to remove it. Note that egui accepts the MPL-2.0 license, and there are 5 other dependencies with this license in the lockfile. The suggested alternative was the etcetera crate, which does the same thing as directories, but as it isn't updated often, I figured it would cause duplicated dependencies in the long run (it already uses a different version of windows-sys than winit does, but so does directories), so I just put the code directly in eframe. The only non-trivial bit of code is the roaming_appdata function for Windows, which can be replaced by the known-folders crate as I mentioned above. So if we don't want to have this code in eframe, there are plenty of existing options already: either use etcetera for everything, or use known-folders for the Windows part, or just revert this PR and go back to directories. I feel like rewriting everything in a new crate would just be redundant.