Add ability to see all files to FileSystem dock, even files that can not be used from Godot

[winston-yallow]

Describe the project you are working on:
Irrelevant for proposal, but hey it is a top down hide and seek game.

Describe the problem or limitation you are having in your project:
Files that are not recognized by godot are not shown in FileSystem dock. This is also true for subfolders that contain a project.godot file. This can be confusing for new users as the name "FileSystem" suggests that all files from the OS file system are shown.
See this (closed) issue for an example: godotengine/godot#37671
If it is planned to support nested projects then this part would become obsolete, however the issue for unsupported files still exists.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
The ability to show all files will help users to see that godot treats some files as usable and others as unusable.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
I see two things that would help to achieve this goal:

1. Always show all files/directories:
Directories that can't be accessed would be shown in a different way, see images. If the mouse hovers them a tooltip would explain why the file is inaccessible.

2. Add a toggle to show all files:
This would add the ability to decide what is or isn't shown.

I think a combination of both would be the best option. This way users are able to see all files if they want, but they can still hide them if the file tree is too crowded. It could look similar to this mock up:

If this enhancement will not be used often, can it be worked around with a few lines of script?:
Not really.

Is there a reason why this should be core and not an add-on in the asset library?:
The file system is an elementary part of the engine, it would be nice if it has this ability by default. Also I am not sure if an addon should mess with the internal filesystem dock, probably not a good idea.

Bugsquad edit (keywords for easier searching): non-resource, nonresource

[KoBeWi]

Related: godotengine/godot#25665

[chucklepie]

Hello, what's the likelihood of this ever happening? The suggestion is essentially how most IDE's function, for example Visual Studio has a 'list all files' option. Whether there's a facility to open it is irrelevant (most provide either an option to specify a command to run, or simply 'open in default configured editor for file extension'.

An example being json files that we save to be loaded as a dictionary or parse as text. Inside the Godot editor you do not even know such files exist or where they are so you have to have separate windows open just to manage the files for your Godot game.

[anderlli0053]

Also adding the ability to open not just JSON files as text files inside the code editor, with possible option to be edited like in the code editor, clicking on project.godot inside of Godot filesystem dock could also either open the project settings window for editing the settings like it does in Unreal and in Unity, or it could also just open it up as a text file for manual editing like code editors do... or maybe even an option to choose when it is clicked.. to either "visually open" or just in "textlike manner"

[winston-yallow]

@anderlli0053 The possibility to open text files was already merged godotengine/godot/pull/53025

So all that this proposal is now about is the ability to display arbitrary files in the file dock. I still think this would be useful, even if we already can see and edit text files (like json, csv and so on).

[Skaruts]

To be honest, I think Godot should even, by default, list .txt, .cfg, .json, and any other file types that can in some way be part of the project. (Or even allow specifying other types for listing.)

• .txt can be part of the project as a readme or manual. But they can also be handy for taking notes or making todo lists, etc.
• .cfg (and .ini as well?) and .json and maybe others, because there are classes in the engine (ConfigFile, etc) that work with those files, and it can be handy to easily double check how they look while implementing things.
• .md because it would make it easier to manage the information on a repo from inside godot.

But I do like the idea of being able to see all hidden files and folders. One advantage of that is to be able to create .gdignore files from inside godot (#1809), because windows users can't easily create them in the windows explorer. Another related advantage is that that would allow Godot to do some clean up: if you use the FileSystem docker to create a .gdignore in a folder, Godot could automatically remove all .import files in it.

[KoBeWi]

To be honest, I think Godot should even, by default, list .txt, .cfg, .json, and any other file types that can in some way be part of the project. (Or even allow specifying other types for listing.)

This is already done in 4.0. By default these extensions are visible: txt,md,cfg,ini,log,json,yml,yaml,toml and can be edited in the built-in text editor.

[sosasees]

@KoBeWi this is great 🙂
seeing the README and LICENSE files in the Godot Editor is the feature i wanted to propose today, so i'm glad that it's already discussed and implemented in Godot 4.

[Calinou]

@Zireael07 Please don't bump issues without contributing significant new information. Use the 👍 reaction button on the first post instead.

[Zireael07]

Why is that not significant? Android filesystem browsers are extremely limited in what folders they can access, so the workaround of "go to project folder via filesystem" that is perfectly doable on desktop is NOT an option on Android. Hence this is very important with the Android editor version

[Calinou]

@Zireael07 I'm aware, but mentioning this on its own will not help the feature be developed faster 🙂

Remember that every comment sends a notification to every person watching the repository, so make sure breaking the silence is worth it.

[hsandt]

I found another use-case today: script templates

The official doc on script templates itself tells us to add .gdignore to the script_templates folder since it's likely that template format breaks syntax parsing (starting with the first line extends _BASE_).

However, having the script templates under the eyes would be very useful, whether I use my own templates, or I have imported an add-on which dropped its own templates in script_templates.

This also means that we need to add some subtlety in the code editor if we want to allow opening text files directly in Godot's code editor:

1. Non-Godot scripts such as raw .txt or .cfg files would be opened without parsing (although we could have just syntax coloring for formats like .json to help user)
2. Godot scripts that are ignored via .gdignore would be opened without parsing to avoid errors. However, they could have basic syntax coloring to help (either using GDScript standard coloring despite giving not great result on things like _BASE_, or a dedicated template syntax coloring; but probably overkill if there is only _BASE_)
3. To support Find in Files, we'll need to add extra checkboxes such as "non-Godot scripts" and "script templates"

The reason why script templates is particularly useful to open in Godot compared other text files is that it's very close to actual scripts. In fact, when creating a template, I would probably copy the content of an existing GDScript as a model, strip some method implementations and insert _BASE_, while using syntax coloring to make sure that I'm not breaking the script's structure.

I do acknowledge however that without complete parsing (such as testing whether a variable is of correct type, or a method is called with the right signature), the utility of this is decreasing a lot. This is a general problem with template and macro editing, and I'm not sure if there's an easy way to deal with that, except hardcoding a special check for _BASE_ and parsing the rest normally.

[hsandt]

By the way, Jetbrains apps like Rider have a similar system as proposed except they use completely different views selected via dropdown:

a. In Unity projects, Unity view shows about the same files as the game engine embedded browser:

This is close to what we have now.

b. Solution view focuses on the assemblies, distinguishing runtime, editor and plugins easily:

This probably only makes sense in .NET project, so Godot with C# in our case.

c. File system shows all the files, as proposed:

I always use it to edit my .gitignore.

That said, in common cases, we only need two views like a. and c., so a toggle as proposed in the first post should be enough.

[aqt]

To be honest, I think Godot should even, by default, list .txt, .cfg, .json, and any other file types that can in some way be part of the project. (Or even allow specifying other types for listing.)

This is already done in 4.0. By default these extensions are visible: txt,md,cfg,ini,log,json,yml,yaml,toml and can be edited in the built-in text editor.

This is great, as long as the files you want to show have an extension. For example README won't show up. You change the list with the editor settings property docks/filesystem/textfile_extensions.

You can also use this to make binary files show up, but it's important to not open them in Godot, so you don't accidentally save over them which will destroy them! These files can instead be opened by right-clicking and selecting Open in External Program. This is how I will open my aseprite project files from now on.

[sosasees]

This is great, as long as the files you want to show have an extension. For example README won't show up.

most Godot projects have a README in Markdown format, so the file is named README.md.
a README without a file extension implies that

1. the README is in Plain Text format (not Markdown), so the right file extension to add is .txt
2. the README is for a very old software project (from before it was estabilshed that it's good practice for the README to have a file extension)

so the detection of README files without a file extension is not worth making Godot more big and hard-to-maintain:

this is just one small feature, but adding a lot of not-useful-enough features would quickly make Godot much more big and hard-to-maintain than it needs to be.

[awardell]

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
I see two things that would help to achieve this goal:

1. Always show all files/directories:
   Directories that can't be accessed would be shown in a different way, see images. If the mouse hovers them a tooltip would explain why the file is inaccessible.

2. Add a toggle to show all files:
   This would add the ability to decide what is or isn't shown.

I would prefer, if this proposal were implemented, if there were a distinction between unsupported filetypes, hidden files/directories, and "inaccessible" files/directories. I realize that this distinction would add more complication to the matter, but it's also possible to implement each kind separately. An option to show files with unsupported extensions can exist on its own, for instance.

Adding support for displaying a file doesn't even necessarily mean support for opening the file. On the old issue for this proposal, one person said:

IMO the fact that the Godot Editor can't open a file type is not a reason to not show that file type in the FileSystem Dock, and when the user tries to open a file that the editor don't know how to open, it should send it to the default OS application.

Which sounds relatively simple and straightforward, but even if it isn't we could just print an error message.

Here is how I would break down this proposal:

1. Add FileSystemDock functionality for unhandled files and directories
   • Display unhandled items but red or grayed out
   • Add a context menu with basic, limited functionality
   • Ensure all files can be moved, renamed, deleted without issue (Likely not a problem)
   • Handle user opening the file: either ->OS or print an error
2. Add EditorSettings toggle for displaying files with unhandled extensions
   • FileSystemDock reads from settings when determining whether to display files
     • Optional: add setting to new settings menu accessible from FileSystemDock
3. Add EditorSettings toggle for displaying hidden files and directories
   • FileSystemDock reads from settings when determining whether to display hidden file or directory
     • Optional: add setting to new settings menu accessible from FileSystemDock
4. Add FileSystemDock functionality for inaccessible files and directories
   • Add EditorSettings toggle for displaying inaccessible files and directories
     • Optional: add setting to new settings menu accessible from FileSystemDock
   • FileSystemDock reads from settings when determining whether to display inaccessible file or directory
   • Inaccessible items display red or otherwise clearly broken
   • Inaccessible items cannot be interacted with. Attempting to do so prints an error
5. Forward unhandled file extensions to the OS if we haven't already done that in 1.
   • Bonus: This could later also be used to simplify text-editor-handling of script files. No need to define an external editor in settings, just let the OS handle it if Godot doesn't want to.

The core of this proposal IMO is point number 1. It's ideally packaged with number 2, but could exist without.

Number 3 does not necessarily depend on number 1. Hidden files and directories can behave in the way any other files would.

Number 4 is its own thing. It just fits the proposal theme of seeing ALL files.

I think people could be more likely to agree upon specific details if the proposal is broken down in this manner, and I think people would be more willing to tackle and actually implement the distinct parts.

[crystalthoughts]

I also think this is an important feature. Whilst the initial assumption might be that hiding unusable files reduces user confusion, I don't think this is true once a project becomes larger than toy-sized.

It's reasonable to assume a user might be dealing with files that godot doesn't natively support. Having to rely on switching between the system file browser and the godot file tree, just to confirm existence of a file, is cumbersome and more confusing than other options. A potential situation would be working on a custom loader or plugin - a common scenario.

A greyed out filename is a common signifier and is the best middle ground in my opinion and should be defaulted (perhaps with a more obvious warning symbol like in the original post). The user could then optionally choose to hide unusable files as is the current way.

[Spongeloaf]

RE @crystalthoughts:

I also think this is an important feature. Whilst the initial assumption might be that hiding unusable files reduces user confusion, I don't think this is true once a project becomes larger than toy-sized.

Absolutely. My project consumes data from an unsupported filetype, for which I've written a library that renders them into usable game assets. I have dozens of them, and not being able to see them in the filesystem dock is really annoying. The contents of this unsupported file are just human readable text data, and I edit them in notepad++.

So, if option 5 (suggested by @awardell is implemented, then I could just double click them in the Godot file dock and I'm off to the races.

[passivestar]

To be able to open Affinity .afdesign files from godot I have to add it to text file extensions and open it by clicking Show in File Manager then double clicking on it in the OS file manager. That's hacky and a lot of clicks

If the dock showed and let open everything it would be a massive improvement

[cccyberwolke]

I just started using godot for a project myself and it really confused me that godot did not display the files i needed for my project. (In this case a .db file containing a sqlite db). It looked like godot didn't support the file at all, not sure if it would even be usable or included in the exported build. It took me a while to figure out i can edit the supported extensions, but i think the best and easiest solution would be to just have the option inside the dock to toggle view of all the files in the folder. Every IDE has this feature and i don't see a reason why godot shouldn't.

[sscovil]

Just adding another use case here. I'm developing a plugin (Godot Style Sheets) and want to be able to open text files with the custom file extension .gss in the script editor, so they can be edited like any other text file (maybe with a custom syntax highlighter). This has proven to be way more challenging than I had originally expected, and it's starting to look like I'll need to build a special file editor just for this type of file now.

I'd love to just be able to add a file extension to the list of supported text file extensions via an API, and register a syntax highlighter for it.

EDIT: I just discovered ResourceFormatLoader and am looking into that now. At first glance, it seems like this is the way forward for my particular use case...

[mmyse]

Adding another perspective. I'm trying to make a game where I would greatly benefit from being able to use MIDI files. I have no idea how the lovely people making and publishing these plugins made them work in their projects, as not only do MIDI files not show in Godot's file system, but Godot generally does its best to refuse to acknowledge their existence, so I can't use the plugins I want to because I start running into import errors too.

I don't think it's reasonable for Godot to just assume which file types are usable and which aren't. That should be left to the developers. If I have a plugin available to me that is able to handle it all, it would be good to allow it to do its work properly.

[Calinou]

The code in FileSystemDock that handles whether a file is shown or not is here:

https://github.com/godotengine/godot/blob/4cb6e9994a34e3c489bd635dcf5601511c8accd7/editor/filesystem_dock.cpp#L273-L276

Commenting out this block does not let non-resource files show up in the FileSystem dock though.

Just adding another use case here. I'm developing a plugin (Godot Style Sheets) and want to be able to open text files with the custom file extension .gss in the script editor, so they can be edited like any other text file (maybe with a custom syntax highlighter). This has proven to be way more challenging than I had originally expected, and it's starting to look like I'll need to build a special file editor just for this type of file now.

You can add gss to the TextFile Extensions editor setting. An editor plugin can append to this setting when the plugin is enabled (it's a comma-separated string). When doing so, make sure to check whether gss isn't already part of the list though.

as not only do MIDI files not show in Godot's file system, but Godot generally does its best to refuse to acknowledge their existence, so I can't use the plugins I want to because I start running into import errors too.

If the MIDI plugin registers a new import format, it will appear in the FileSystem dock if the plugin is enabled in the editor. Otherwise, it meansthe MIDI plugin is designed to perform runtime loading only, not importing.

As far as I know, most MIDI playback plugins currently available only handle runtime playback, not importing. This means you need to add the relevant file extension(s) to the non-resource export filter in the Export dialog.

[chucklepie]

So what's the issue, why the need to hide things from view?

[Calinou]

So what's the issue, why the need to hide things from view?

Implementing this is nontrivial given how the FileSystem dock is currently implemented. It does not try to read the raw filesystem and filter out data based on this. Instead, it relies on data given by EditorFileSystem¹, which itself has many special cases in place to allow TextFile extensions to show up (even though they are not valid imported resources by themselves).

I see 2 ways to implement this in a toggleable manner:

• Make the toggle change entirely how the filesystem gathers its data, making it read from the raw filesystem when the option is enabled. This means having to maintain two separate codepaths for a feature that only the FileSystem dock would use (EditorFileSystem is used in many other places). This solution is more local, so it seems more likely to be implemented.
• Try to add more hacks to EditorFileSystem to allow all files to show up within it. That said, at this point, there probably isn't much point in having an EditorFileSystem class anymore...

Footnotes

1. Search for all instances of textfile in that file. ↩