godot
godot copied to clipboard
Add filename filter field to FileDialog
Added possibility to filter files and folders through a text entry. The text entry is hidden by default, and can be opened by pressing Ctrl+F or by clicking the appropriate filter button.
Closes https://github.com/godotengine/godot-proposals/issues/9099
This Pull Request features a filter bar for FileDialog
.
It enables to search a specific term in the current folder. The matching subdirectories are first displayed alphabetically, and then the same happens to files.
https://github.com/godotengine/godot/assets/121762735/b9137acd-f1e4-4e47-9fe7-b0cf7a0df373
I've got an error saying that if (match and files.front()->get().to_lower().contains(filename_filter_match.to_lower())) {
was a syntax error, how am i supposed to write it?
With &&
, don't use and
in c++
With
&&
, don't useand
in c++
That's weird because it worked with and
when I tested my code
Yes it's an alternative syntax, but it's not allowed (and fails on MSVC)
That's weird because it worked with and when I tested my code
MSVC do support alternative syntax, but require inclusion of iso646.h
(this is true for all compilers, but GCC will work with a lot of omitted includes). Syntax exist to support ancient encodings without some characters like &
and in general should not be used.
Same for the second dialog.
Note: This feature will be impossible to implement in the native dialogs (on any of the supported platforms). But native dialogs usually have search functionality of their own.
@bruvzg ~I'm trying to figure out why, but your suggestion broke the filter~
EDIT: Fixed, my fault
Great PR, I would really love filters inside the dialog, but I'm against the idea of adding a new box to the dialog to the list. The UX of the dialog is already painful.
We should instead refactor the whole dialog, as filters should be in the top bar, aside a unified path editor/dropdown. I think I'll create a proposal for this.
(I know I have been requested to take a look at the docs here but I am not sure if the new methods/signals have been stabilised)
Great PR, I would really love filters inside the dialog, but I'm against the idea of adding a new box to the dialog to the list. The UX of the dialog is already painful.
We should instead refactor the whole dialog, as filters should be in the top bar, aside a unified path editor/dropdown. I think I'll create a proposal for this.
That's right, but I think that's better to have this feature implemented in a simple way until a FileDialog refactor is done, than not have it at all
(I know I have been requested to take a look at the docs here but I am not sure if the new methods/signals have been stabilised)
what do you mean by stabilised
?
I meant I was not sure if anything about the exposed API in the PR was going to change drastically, but judging by the above discussion it does not seem to be the case. Will take a look when I can.
Tested locally, it works as expected. Thanks for working on this feature :slightly_smiling_face:
However, I believe this filter field should be hidden by default and should be shown when pressing / instead (pressing Escape while focused on it would hide it). This is because there's a high chance users will confuse it for the filename field if it's always visible. Moreover, it takes valuable vertical space and it's not something most users will need to see all the time.
See how it works in KDE's Dolphin:
https://github.com/godotengine/godot/assets/180032/6b8a260f-fee5-46b5-ac4e-0bde113ace2f
It would have only a shortcut? no icon needed?
also I don't know how to bind a key in the source code
Tested locally, it works as expected. Thanks for working on this feature 🙂 However, I believe this filter field should be hidden by default and should be shown when pressing / instead (pressing Escape while focused on it would hide it). This is because there's a high chance users will confuse it for the filename field if it's always visible. Moreover, it takes valuable vertical space and it's not something most users will need to see all the time. See how it works in KDE's Dolphin:
dolphin.mp4
It would have only a shortcut? no icon needed?
I'd rather use Ctrl+/ instead of / because / is used in paths
like this
ED_SHORTCUT("file_dialog/open_filename_filter", TTR("Open Filename Filter"), KeyModifierMask::CMD_OR_CTRL | Key::SLASH);
I'll be away for 3 days, I'll continue when I'm back
Tested locally, it works as expected. Thanks for working on this feature 🙂 However, I believe this filter field should be hidden by default and should be shown when pressing / instead (pressing Escape while focused on it would hide it). This is because there's a high chance users will confuse it for the filename field if it's always visible. Moreover, it takes valuable vertical space and it's not something most users will need to see all the time. See how it works in KDE's Dolphin:
dolphin.mp4
It would have only a shortcut? no icon needed?
I'd rather use Ctrl+/ instead of / because / is used in paths
like this
ED_SHORTCUT("file_dialog/open_filename_filter", TTR("Open Filename Filter"), KeyModifierMask::CMD_OR_CTRL | Key::SLASH);
how can I get it to work on a Azerty keyboard? sounds like / key doesn't work
how can I get it to work on a Azerty keyboard? sounds like / key doesn't work
Add true
as the last parameter of ED_SHORTCUT()
(it's an optional parameter). This makes the shortcut use a physical key location instead of the key label.
Note that in Dolphin, I only need to input / on its own to make the filter show up, not Ctrl + /.
how can I get it to work on a Azerty keyboard? sounds like / key doesn't work
Add
true
as the last parameter ofED_SHORTCUT()
(it's an optional parameter). This makes the shortcut use a physical key location instead of the key label.Note that in Dolphin, I only need to input / on its own to make the filter show up, not Ctrl + /.
that's right, but I don't want the thing to pop every time someone is writing a path
for the same reason, I used the shortcut as a toggle rather than a toggler, cause ESCAPE closes the window instantly
I want to use Ctrl + F for the shortcut, as it works on almost every keyboard and it's easy to guess
I'm struggling with the conflicts, if someone sees something wrong, please tell me
I'll fix the failures tomorrow
https://github.com/godotengine/godot/pull/88673#pullrequestreview-1907532897
I implemented the requested changes
I have a commit with the content of .github folder why?
I have a commit with the content of .github folder why?
in fact it happens only with github mobile
The required changes are done, and the commit problem is fixed: everything is ready !
I tested the latest revision of this PR locally, I noticed an issue in FileDialog where the filter icon appears activated but the filter LineEdit isn't shown if you press Ctrl + F to toggle it:
This only occurs the first time you use the shortcut after using popup_centered_ratio()
on a FileDialog. Subsequent presses of the shortcut are fine.
This doesn't occur with EditorFileDialog. It also works fine if you click the filter button instead of using the keyboard shortcut.
Testing project: test_file_dialog.zip
I tested the latest revision of this PR locally, I noticed an issue in FileDialog where the filter icon appears activated but the filter LineEdit isn't shown if you press Ctrl + F to toggle it:
This only occurs the first time you use the shortcut after using
popup_centered_ratio()
on a FileDialog. Subsequent presses of the shortcut are fine.This doesn't occur with EditorFileDialog. It also works fine if you click the filter button instead of using the keyboard shortcut.
Testing project: test_file_dialog.zip
The thing is I have other issues with the shortcut management: my french keybord isn't handled at all, making it hard for me to test
so if you have any idea on how to fix the bug, feel free to say
Alright the bug is fixed
I have problems with the merge conflict... again 🥲