-
-
Notifications
You must be signed in to change notification settings - Fork 21.9k
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
Make FileDialog
filtering case insensitive
#85789
Make FileDialog
filtering case insensitive
#85789
Conversation
d9ba32f
to
c036593
Compare
You also need to register these enums in |
You also need to document these methods, use |
I've updated the doc xml now, is this correct? Documentation isn't my forte so the wording might need tweaking. |
ce20f90
to
99590f2
Compare
4d50f88
to
22a2e5c
Compare
22a2e5c
to
28deffd
Compare
I noticed a merge conflict, so I've rebased and resolved it. |
It looks like one of the tests failed due to a ubuntu keyserver issue. Could a maintainer request a rerun of the failed test? I appologise if the ping is innapropriate, but Yuri also requested requested @bruvzg to re-review the PR in December. Is there anything else which needs to be done before it can be approved for merging? |
Tested locally on Linux (on a case-sensitive filesystem), I'm a bit confused about the behavior. The only behavior that seems desirable to me here is the one where case sensitive is set to False: simplescreenrecorder-2024-02-15_20.19.39.mp4Otherwise, you get a double extension appended. Is there a point for keeping case sensitive True (and OS Default on case-sensitive filesystems)? Also, the file filter is always case-insensitive regardless of this option, but I guess that's expected. |
That behaviour looks as expected. Having the option for true and OS Default is so it doesn't break anything which might be reliant on a case sensitive file picking for whatever reason. I agree, having it set to false is the desirable option in all the use cases I could think of but I didn't feel comfortable making that assumption for everyone, hence having the option and defaulting to match the OS's case sensitivity. The file filter was case insensitive for listing the files in the dialog originally, it was just the functionality of the detecting the extension on the selected filename and appending if it was missing which wasn't case insensitive, which resulted in the doubling of the file extension. I could remove the setting and just make this always be case insensitive, or I could have it default to false and leave the option for the rare situtation it might be wanted? I'm open to whichever option is most suitable. |
28deffd
to
30fdcaa
Compare
FileDialog
filtering case insensitive
IMO this makes sense. The change only affects extension checking and I don't see why would you care about extension casing and make a double extension, like currently happens on mismatch. The same change should be done in EditorFileDialog. |
30fdcaa
to
a9e7e16
Compare
Good shout, I've added the change to EditorFileDialog too, I also noticed |
Needs to be squashed into 1 commit. |
Change FileDialog and EditorFileDialog to use case insensitive string comparisons when saving files to avoid duplicate file extensions.
a9e7e16
to
cd269b8
Compare
Commits squashed 👍 |
Thanks! And congrats for your first merged Godot contribution 🎉 |
When using FileDialog to save files on non-case-sensitive file systems (Windows and often macOS), a file may have an uppercase file extension (
file.TXT
) but the filter is set as lowercase (*.txt ; Text Files
). The FileDialog will list the file but selecting it to overwrite will not detect that the file matches the filter and append the lowercase extension after the existing uppercase file extension and would result in the selected file beingfile.TXT.txt
As most other operating systems can be case sensitive, my suggestion is to add a
CaseSensitivity
enum with the values ofTrue
,False
andOS Default
to the FileDialog for toggling between usingf.match(str)
andf.matchn(str)
in the checks which would allow it to either be explicit based on the developer intent or implicit based on the standard of the operating system.Currently if
OS Default
is used then the code uses a case-sensitive check if the OS is not Windows or macOS. Is there a better approach for this? Are there any other supported OS's are not case-sensitive by default?Attached is an MRP similar to the one provided in the issue, with the addition of an OptionButton for changing between the CaseSensitivity setting when running the project.
FileDialogCaseSensitivity.zip
Fixes #85788