-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
egui-file-dialog very slow when opening a disconnected/broken network drive #236
Comments
Hey wiz21b, Thank you for the issue! Yes, that doesn't actually sound right. I'll have to see if I can reproduce this myself. I'm also a bit confused as to why the file dialog appears to be requesting something from the network when querying the volumes. The drives and their names should be queried from the operating system, but nothing from the external server. At least not as long as the drive is not selected in the file dialog. Which operating system and which version of the file dialog are you using? |
Hello! I've tested that with the latest version of egui-file-dialog and on Windows. I have investigated your code and dunce seems somehow at the root of this. I have open an issue there and the answer is pretty good (and it's a "not my fault" one :-/ ). Moreover in your API there's a flag to not canonicalize the paths but somehow it is not possible to acknowledge it when enumerating the drives. So I guess that's a bit of an API issue. |
Hi, so it's once again a Windows only problem... Thanks for taking the time to look into and debug this issue. |
Ye, I know what the problem with the canonicalization flag is. Will fix it now. |
The |
I'll have a look |
Hello Fluxxboxx,
I think I have found an issue with the file dialog.
When you create a FileDialog for the first time, it queries the list
of drives. This list includes the network drives. On my PC, one of these
network drives is disconnected. Because of that, it takes time
to the "dunce canonicalize" function to complete (that can be up to 10 seconds).
So this induces a freeze.
I think it could be fixed by delaying the drives listing up to the
moment where the ui of the FileDialog is displayed. In that case
you could display a little "waiting" cursor. I propose that because if
I try to open the drive from the file dialog that's what it does and
it helps the user to wait (and you even display an error message which is great!).
And thank you for this project, it really helps!
The text was updated successfully, but these errors were encountered: