egui icon indicating copy to clipboard operation
egui copied to clipboard

Decouple directories from persistence in eframe

Open YgorSouza opened this issue 1 year ago • 2 comments

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.

YgorSouza avatar Aug 02 '24 19:08 YgorSouza

Good idea - this should be documented somewhere for users who will search for it

bircni avatar Aug 02 '24 20:08 bircni

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.

YgorSouza avatar Aug 03 '24 09:08 YgorSouza

@emilk which part do you want to be extracted?

bircni avatar Sep 01 '24 13:09 bircni

Basically all the code that was added in this PR :)

emilk avatar Sep 02 '24 07:09 emilk

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

bircni avatar Sep 03 '24 19:09 bircni

Issue tracker should be different in this line: https://github.com/bircni/file_storage/blob/1fbec8ed8c3d853a99cde7bab33a7f17eaf6bc79/src/os.rs#L73

Mingun avatar Sep 03 '24 20:09 Mingun

The question is what to do with the os.rs ? Put it in the crate too or get it via egui as a dependency

bircni avatar Sep 04 '24 13:09 bircni

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.

YgorSouza avatar Sep 04 '24 17:09 YgorSouza