Expose more of the FileSystemDock to GDScript

[dark-penguin]

By design, we are trying to have as many things as possible implemented as addons instead of in the core. At the moment, it's often impossible because addons are very limited in what they can do.

The file system dock is the integral part of the editor, it's "where everything begins", but its exposed functionality is very limited.

Let's use this issue to keep track of requests for what do people need exposed from it, or discuss possible implementations.

Describe the project you are working on

An editor plugin. To be specific, an attempt at better Git integration. But this is mostly irrelevant.

Describe the problem or limitation you are having in your project

• I can not see text files in the filesystem dock and open them in the editor (plugin.cfg, TODO.TXT, .gitignore...) (I'm not the only one: Option for showing more/all file types in FileSystem dock godot#25665 )
• I can not create an addon that makes that possible (which is closer to my point)
• I can not create an addon that has an editor for its own file format and allows opening those files simply by clicking them
• I can not create an addon that implements an editor for a new file type that can "just open them" (people will DIY those if you give them the tools)
• I can not highlight files in the FileSystemDock with different colors
• I can not create an addon that adds a new item to the context menu of the files in the filesystem editor
• There are other requests about exposing more of the filesystem dock: Expose FileSystemDock to EditorInterface and restructure the FileSystemDock "*_moved" and "*_removed" signals godot#26709

Describe the feature / enhancement and how it helps to overcome the problem or limitation

I would suggest exposing as much of the filesystem dock as possible to avoid future requests to expose more. If possible, its whole structure, with all the nodes and all their properties. If it's hardly possible, then try to mimic it. The point is, instead of "please expose one more thing" or "please implement one more feature", it's "please export them all so we can implement any feature ourselves".

Since Godot is proclaimed to be "a game itself", extensible with easy to make addons written in GDScript, I assumed that it means "each UI component can be fiddled with, using GDScript". Turns out you can't, and so we are all waiting for the core instead.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

I don't exactly know how the filesystem dock is implemented, other than what I can see in the editor scene tree (not much). What I can imagine is a scene tree with readable names of each sub-item in that dock, with all their properties.

However, I really don't know if this is at all possible, or is it harder than it seems. The dock is just a bunch of Nodes, right? Why don't just give them legible names and a way to find the root node? It's probably not that simple, is it? :)

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

This change can enable a lot of "yes"-es here.

The only "workaround" is "give up and don't use the filesystem dock" - and instead create another one yourself:

• To edit text files, you can open the editor, click "File - Open", change the extension filter and find your file
• To make an editor, you can implement your own interface for opening files in a similar bothersome way
• There is no easy way to implement your own filesystem dock if you want to highlight items or add menu items
  Still, being able to use the normal filesystem dock for everything would improve the user experience.

Is there a reason why this should be core and not an add-on in the asset library?

This change will make it possible to implement things as addons instead of core.

[Calinou]

I can not see text files in the filesystem dock and open them in the editor (plugin.cfg, TODO.TXT, .gitignore...)

This is already covered by #677.

The point is, instead of "please expose one more thing" or "please implement one more feature", it's "please export them all so we can implement any feature ourselves".

The problem always comes first. With such a vague scope, this proposal will never be addressed in a way that keeps decent usability. It's why we ask people to open small, focused proposals rather than lumping many ideas together in the same proposal 🙂

The issue with exposing low-level access to editor docks is that things can quickly go wrong, especially if multiple plugins try to do things with the FileSystem dock at the same time.

[dark-penguin]

I think this has more to do with items 6 and 7 from that list: it's about "give low-level API" (5) so that we don't have to add multiple core feature whenever a new small problem arises (6).

If I open multiple features instead:

• Expose the extension type filter from the filesystem dock (to add .gitignore and text files)
• Expose the file tree from the filesystem dock (to set attributes on per-item basis)
• Expose the item colors from the filesystem dock (to mark files with different colors)
• Expose the item label attributes from the filesystem dock (to mark files with bold/italic)
• Expose the item context menu from the filesystem dock (to add "Add to Git" and "Ignore")

...then they will be either consolidated in one issue, or (much more likely) refused because "each item has a very limited and rare use case". And even if all those things are added, the next thing we know is someone has filed a request to expose another specific property of a specific sub-item, and they have to go through discussing it and waiting for the core again.

With such a vague scope, this proposal will never be addressed in a way that keeps decent usability.

Actually, I think that in this specific area, usability can come second. In fact, could it be possible to introspect the filesystem tree as it currently is? I did not succeed the last time I tried, but maybe I did not try hard enough...

OK, so the root node of the filesystem dock is apparently called "filesystem". Its children are kind of untitled, but it should be possible to figure out what's what and DIY it, if we can determine their types. Could you point me in the right direction about whatever object introspection we have in GDScript? I know there is typeof(), but that does not return the actual node type.

[jonbonazza]

Rather than say "i need feature x", it's better to say "i need to do y", where y is a high level task. What are you ultimately trying to accomplish? It sounds like you are often creating a bunch of addons. For each of your bullets, i suggest creating a separate proposal that is more abstract and high level in your problem statement.

What you are doing here is putting the cart before the horse so to speak, but using the lack of a solution (maybe not even the best solution) as your problem statement.

[dark-penguin]

So should I do a "less vague scope, more specific problems", or "less specific problems, more high-level scope"?!.. :)

The high-level problem is: I'm trying to enhance the editor interface with addons, but what addons can do in terms of interaction with the existing interface is very limited. On the other hand, I don't think it's worth the effort to try to expose each part of the interface separately with the same level of careful deliberation as the rest of GDScript has. So maybe there is some way to make the whole interface more hackable in general without exposing it piece-by-piece?..

The "more specific" problem that I've actually encountered at the moment is that I want to edit the filter on the displayed file types, and highlight displayed files with different colors (or maybe with bold/italic fonts). The former is already known (for over two years...), and the latter is too much of a corner case to waste time on. So instead of that, maybe there is a way to expose the interface all at once to open a way to deal with such issues?..

By now, I've realized that the file filter problem can't be fixed that easily, and the files' attributes and menus are probably only relevant to this one corner case (so even I wouldn't want the core team to waste time on it). And I shouldn't try to imagine more problems I don't have yet. :) And if I do, then I should probably come up with a more specific implementation proposal rather than "is there any solution to make things more hackable?". :)

Apparently, there is not, and seems like no easy introspection either, so I'll close this. It might be possible with GDNative and reading the sources, but I won't go there for now.