FileSystemDock: Add "Rescan Filesystem" option to context menu

[cruglet]

This adds a new "Rescan Filesystem" button when right-clicking the res:// folder in the filesystem dock in order to give the ability to trigger this manually, which as far as I know cannot be done as of now.

Oftentimes when switching between workspaces in my display manager the filesystem scan fails to run or detect any changes in the project filesystem. The only way I've been able to remedy this is to either reload the project entirely or keep switching in/out of focus for the window and hope it triggers the filesystem rescan.

Although this PR seems to mostly fix the issues for me, I’d like to know whether this option should also be given a shortcut like some of the other menu actions, and if there are any other implementation details I missed or should consider

Bugsquad edit: Closes godotengine/godot-proposals#12940

[AdriaandeJongh]

I obviously don't know the details, but I can imagine that addressing filesystem scan failing is a better solution to your issue than this workaround.

[cruglet]

I obviously don't know the details, but I can imagine that addressing filesystem scan failing is a better solution to your issue than this workaround.

Of course, but I believe this is mostly a compositor issue, not necessarily on Godot's end. I'm not well versed enough in Wayland or Hyprland's source code to identify the issue let alone fix it just yet.

To specify, I think the issue might have to do with a failure to notify godot of the window being focused/unfocused properly, so although I can interact with the engine just fine, processes that rely on these notifications like the filesystem scan doesn't end up running

[KoBeWi]

You can workaround it with an EditorContextMenuPlugin that calls EditorFileSystem's scan_changes().

Also fun fact: FileSystem dock used to have a reload button, but it was unused for a long time: #103762
It shouldn't be necessary anymore; if editor doesn't automatically find changes, it's a bug.

[cruglet]

You can workaround it with an EditorContextMenuPlugin that calls EditorFileSystem's scan_changes().

Yeah I ran into this while researching before this PR, I just feel as though using a plugin here feels like overkill for something this trivial.

Also fun fact: FileSystem dock used to have a reload button, but it was unused for a long time: #103762
It shouldn't be necessary anymore, if editor doesn't automatically find changes, it's a bug

In some display managers changes can be made externally when the window still believes it's in focus, and I don't think there's necessarily a guarantee those issues will completely disappear (especially when the bug is on the DM's side), so it's nice to have an option to be able to trigger this scan when the alternatives are to rely on plugins or reloading completely.

But yeah I get where you're coming from. This just provides users with a quick recovery as opposed to either using plugins or waiting for each individual bug causing this issue to be identified and fixed.

[KoBeWi]

Seems like there is a proposal: godotengine/godot-proposals#12940
But based on the activity, you are the second person to run into this problem. Looks like a niche corner case, which is exactly what addons are for.

[cruglet]

Seems like there is a proposal: godotengine/godot-proposals#12940

But based on the activity, you are the second person to run into this problem. Looks like a niche corner case, which is exactly what addons are for.

Yeah I get that it might look niche based on activity, but I think it's likely more about underreporting than rarity. It’s probable most users wouldn’t file a bug report or write a plugin for something like this, they’ll just reload the project or live with the inconvenience (I’ve done so until now, and the proposal mentioned seems to have done the same).

In addition, the proposal also notes that addons are more effort than the simple recovery option users expect. With using addons,it is also therefore expected to have the same addon functionality be placed throughout all user projects just to remedy this one issue, which again seems unnecessary.

Having this builtin is an easy way to remove that friction some people experience, and it's not a heavy implementation either. At the very least, I think it’s clear that a nontrivial number of users do or at the very least can encounter this, and labeling it as niche doesn’t seem to really justify leaving the onus up to the user to work around this, especially when it's a bug.

But once again, I do get where you're coming from. It's just a matter of providing that quick and easy option to the user as opposed to making them deal with it on their own, if encountered.