search

fluxxcode / egui-file-dialog

Full featured and customizable file dialog for egui
MIT License
91 stars 14 forks source link

Network mapped drive support? #168

Closed dbalsom closed 1 week ago

dbalsom commented 1 month ago

Thanks for the excellent crate! It's nice to have such a feature-filled file browser for egui.

Just one issue - apologies if I missed something in the config, but I am not seeing mapped drives on Windows 10.

image

I don't really expect egui-file-dialog to find network paths, but if we have mapped them to a drive letter, I would have naively assumed they'd show up when enumerating drive letters.

Most of the files I need to access via my program are on my NAS, mapped to V:

fluxxcode commented 1 month ago

Hey, thank you for the issue!

I would personally also expect network file systems to be included in the file dialog. Could you please try entering the path to a network filesystem directly via path edit in the top panel?

The file dialog is currently using the sysinfo crate to fetch the individual disks. So it seems that sysinfo::Disks does not contain any network-based disks 🤔

dbalsom commented 1 month ago

I'm doing something wrong in my code as when I click the pen icon I see the path edit turn into an edit control for one frame then switch back...

It works in the save file example, although there are some issues.

immediately after entering V:\ it goes there, but the path edit is blank: image

going down one dir shows a path:

image

so I assume in the first example we should see 'UNC\synologynas\Vault' by itself.

The other issue, is that this directory contains 2,000+ items (directories and files). The widget becomes basically unresponsive at that point.

fluxxcode commented 1 month ago

I assume the reason the first segment of the path is not displayed is because the file dialog currently assumes that the path prefix \\?\ exists on windows. I have to look into making the code more robust in this area. I've had problems with this in general on Windows.

Are you currently building the binary in debug or release build? With 2000 elements there should be no problems in the release build 🤔

fluxxcode commented 1 month ago

But even in the debug build this shouldn't cause any problems. It could be that loading the directory elements over the network simply takes too long. If the dialog becomes unresponsive, have the elements already been loaded?

dbalsom commented 1 month ago

Yes, it's very sluggish in release mode.

The elements do load after a few seconds. It's still working, technically, you can scroll, although it takes a few seconds to update.

It does seem to be network-related, as I can view a similar directory on my SSD without so much lag (although there is a bit)

dbalsom commented 1 month ago

If it helps any, I was hoping to migrate from egui-file (https://crates.io/crates/egui_file)

It's not quite as nice looking, but it does show drive V: in the drive list, and after a second to initially load the Kryoflux directory, it scrolls through every item in there with no issues.

fluxxcode commented 1 month ago

Ye that doesn't sound right. I have to see if I can reproduce this.

Does egui_file load the available system drives?

fluxxcode commented 1 month ago

Before I start reproducing - which file dialog and egui version are you on?

dbalsom commented 1 month ago

Does egui_file load the available system drives?

yes, it shows all drives.

I was attempting to use 0.6.1 with 0.28.1 of egui in my project, because I don't use eframe and I am stuck on winit 0.29 for the moment due to custom rendering code that has to be completely rewritten for 0.30's api changes.

But I compiled the 'save_as' example to reproduce using a fresh clone of the repo:

egui-file-dialog v0.7.0 (D:\newdev\egui-file-dialog)
|-- directories v5.0.1
|   `-- dirs-sys v0.4.1
|       |-- option-ext v0.2.0
|       `-- windows-sys v0.48.0
|           `-- windows-targets v0.48.5
|               `-- windows_x86_64_msvc v0.48.5
|-- egui v0.29.1
|   |-- ahash v0.8.11
|   |   |-- cfg-if v1.0.0
|   |   |-- once_cell v1.20.2
|   |   `-- zerocopy v0.7.35
|   |   [build-dependencies]
|   |   `-- version_check v0.9.5
|   |-- emath v0.29.1
|   |-- epaint v0.29.1
|   |   |-- ab_glyph v0.2.29
|   |   |   |-- ab_glyph_rasterizer v0.1.8
|   |   |   `-- owned_ttf_parser v0.25.0
|   |   |       `-- ttf-parser v0.25.0
|   |   |-- ahash v0.8.11 (*)
|   |   |-- ecolor v0.29.1
|   |   |   `-- emath v0.29.1
|   |   |-- emath v0.29.1
|   |   |-- epaint_default_fonts v0.29.1
|   |   |-- nohash-hasher v0.2.0
|   |   `-- parking_lot v0.12.3
|   |       |-- lock_api v0.4.12
|   |       |   `-- scopeguard v1.2.0
|   |       |   [build-dependencies]
|   |       |   `-- autocfg v1.4.0
|   |       `-- parking_lot_core v0.9.10
|   |           |-- cfg-if v1.0.0
|   |           |-- smallvec v1.13.2
|   |           `-- windows-targets v0.52.6
|   |               `-- windows_x86_64_msvc v0.52.6
|   `-- nohash-hasher v0.2.0
|-- serde v1.0.213
|   `-- serde_derive v1.0.213 (proc-macro)
|       |-- proc-macro2 v1.0.89
|       |   `-- unicode-ident v1.0.13
|       |-- quote v1.0.37
|       |   `-- proc-macro2 v1.0.89 (*)
|       `-- syn v2.0.85
|           |-- proc-macro2 v1.0.89 (*)
|           |-- quote v1.0.37 (*)
|           `-- unicode-ident v1.0.13
`-- sysinfo v0.32.0
    |-- libc v0.2.161
    `-- windows v0.57.0
        |-- windows-core v0.57.0
        |   |-- windows-implement v0.57.0 (proc-macro)
        |   |   |-- proc-macro2 v1.0.89 (*)
        |   |   |-- quote v1.0.37 (*)
        |   |   `-- syn v2.0.85 (*)
        |   |-- windows-interface v0.57.0 (proc-macro)
        |   |   |-- proc-macro2 v1.0.89 (*)
        |   |   |-- quote v1.0.37 (*)
        |   |   `-- syn v2.0.85 (*)
        |   |-- windows-result v0.1.2
        |   |   `-- windows-targets v0.52.6 (*)
        |   `-- windows-targets v0.52.6 (*)
        `-- windows-targets v0.52.6 (*)

rustc 1.79.0 (129f3b996 2024-06-10) Microsoft Windows [Version 10.0.19045.5011]

fluxxcode commented 1 month ago

I created a directory with 50,000 elements. The performance in the debug build is not good, but in release build you can notice that the file dialog runs a little slower, but its definitely still usable with minimal input lag.

But I also tested on Linux. I'll run the same test on Windows. Also tested v0.7.0

Edit: also works with v0.6.1

fluxxcode commented 1 month ago

Ye alright on Windows, a directory with 50,000 elements is not usable at all. Interesting 🤔

So to summarize the todos of the issue:

Is something missing?

dbalsom commented 1 month ago

I can test in linux as well, at least in a VM

your list looks good. I appreciate you taking the time to look at this!

edit: on Windows, the file name entry field of the native dialog sort of works as editing the path selection too. So if I hit V:\ as a filename and hit enter, it will change drives. I am not sure if that's something you'd want to implement, but it was my first instinct to try initially!

fluxxcode commented 1 month ago

Found the performance issue. It's because the directory items are filtered every frame. Interestingly, this doesn't cause any performance problems on Linux, but on Windows. I will now change it so that the file filter and show hidden files/folders are applied when loading the directory. This means that every time these filters are changed the directory needs to be reloaded. However, the performance will be significantly improved. The text-based search will still take place every frame. As far as I could test it on Windows, with 50,000 directory items this does not lead to performance issues.

fluxxcode commented 1 month ago

edit: on Windows, the file name entry field of the native dialog sort of works as editing the path selection too. So if I hit V:\ as a filename and hit enter, it will change drives. I am not sure if that's something you'd want to implement, but it was my first instinct to try initially!

Do you mean that if you enter "V:\" as the filename in a file save dialog in Windows, the partition will be loaded instead of the file saved? This is interesting, but I don't think it fits the file dialog here. Because we have the path edit at the top, which can also be opened with / :)

dbalsom commented 1 month ago

Do you mean that if you enter "V:\" as the filename in a file save dialog in Windows, the partition will be loaded instead of the file saved? This is interesting, but I don't think it fits the file dialog here. Because we have the path edit at the top, which can also be opened with / :)

yes, see below file_dialog

of course, your call whether to implement that or not. it may be something windows users are in a habit of taking advantage of.

fluxxcode commented 1 week ago

I created an issue at sysinfo for the network mapped drives: https://github.com/GuillaumeGomez/sysinfo/issues/1384

I'll wait for the maintainer's response there before I implement my own version here.

fluxxcode commented 1 week ago

@dbalsom All todos are now fixed on develop. Are you able to test the changes?

dbalsom commented 1 week ago

i'll let you know as soon as i can

dbalsom commented 1 week ago

Tremendous improvement! I see my NAS mapped V:, and the loading-spinner keeps egui responsive while it chews through the file listing, and once it is loaded it is very responsive.

one minor suggestion (don't shoot me) would be to cache the directory contents , if i go into a subfolder and then back out, it looks like it has to load everything again.

not a huge deal though. Thanks for your hard work. Now I just need to update my winit so I can use this :)

fluxxcode commented 1 week ago

Awesome, thanks for testing!

Caching is not quite so easy, because we do not know whether something has changed in the directory. This means that we would then have to work with modify timestamps of the directory, which depends on the platform and filesystem.

But I think that's something we can think about in the future. Can this issue be closed for now? If you have any further ideas or problems, feel free to create new ones :)

dbalsom commented 1 week ago

I'd say we're good. Thanks again.