Use class icons for script and documentation page buttons in script editor

[fire-forge]

Describe the project you are working on

A 2D top-down shooter game.

Describe the problem or limitation you are having in your project

All scripts and documentation pages have the same icon in the script list.

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

The icon shown to the left of each script in the list would be the icon of the class the script extends. If the script extends a custom class, it will use the custom class' icon (unless it doesn't have one, in which case it will use the class that the custom class extends instead). If the script doesn't extend anything, it will use the Object icon.

The documentation page icon will be moved to the right side of the button to easily differentiate between scripts and documentation pages.

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

I made a mock-up of what this would look like. The left is what we currently have, and the middle and right are two potential options.

I prefer the middle one, as it makes it easier to differentiate between scripts and documentation pages. But there could be reasons for keeping the gear icon so I included both.

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

The script editor cannot be modified by a script.

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

An add-on cannot modify the script editor, and the script editor is core.

[GMJin]

if this is implemented I would like to put one vote for the right-most editor that keeps the gear icons

[CTRLRLTY]

Perhaps instead of changing both the scripts and docs item icons, it would be more feasible to just change the script instead. Removing the need to add a second icon on the far right.

[YuriSizov]

Ideally we would still need to have a script icon. I personally don't find the type of the script class to be that important to use a colorful icon in the list. However, some script specific things I did find important in the past - whether the script is in tool mode, whether it is built-in, which language it was written in. I would prefer that information to be visible, even just with an icon change.

[CTRLRLTY]

Perhaps instead of changing both the scripts and docs item icons, it would be more feasible to just change the script instead. Removing the need to add a second icon on the far right.

Here's an example of what I mean:

https://user-images.githubusercontent.com/52656050/142641798-7feaa011-c380-4812-8189-d2e750cd76dd.mp4

[fire-forge]

This is fantastic! Not having class icons for docs pages isn't a huge deal as you usually don't have that many open, so this is an acceptable compromise.

Did you actually modify Godot's code for this? If so you might make a PR to get it fully implemented.

[CTRLRLTY]

Did you actually modify Godot's code for this? If so you might make a PR to get it fully implemented.

Yes, I modified the editor source code.

[CTRLRLTY]

Ideally we would still need to have a script icon. I personally don't find the type of the script class to be that important to use a colorful icon in the list. However, some script specific things I did find important in the past - whether the script is in tool mode, whether it is built-in, which language it was written in. I would prefer that information to be visible, even just with an icon change.

If it's in tool mode, which icon would it use?

[YuriSizov]

Some new icon that would indicate that it's in tool mode.

[CTRLRLTY]

Would built-in scripts need their own script icon as well?

[fire-forge]

For tool mode and built in script icons, perhaps icons could be added on the right side of the script buttons similar to the signals, groups, script, etc. icons in the scene tree.

The problem is, this can't be done currently because the script list uses ItemList. It would have to be changed to use VBoxContainer and buttons to allow for more icons to be added.

[CTRLRLTY]

The problem is, this can't be done currently because the script list uses ItemList. It would have to be changed to use VBoxContainer and buttons to allow for more icons to be added.

Using a Tree would be more doable.

[bmolyneaux]

I'd love to see this feature especially for custom class icons (those using class_name). I didn't see this mentioned yet, so I think it's worth bringing up. I prefer to add icons to most of our custom types to make things better for our designers. Also showing them in the script editor would make custom icons even better. For the project I have open now, I think it would make the open scripts more navigable:

I personally don't find the type of the script class to be that important to use a colorful icon in the list.

I disagree. It should make it easier to visually identify which script you will edit. This includes the color: At a glance, I can find my HUD script by looking for a green icon, for example.

However, some script specific things I did find important in the past - whether the script is in tool mode, whether it is built-in, which language it was written in. I would prefer that information to be visible, even just with an icon change.

You could achieve some such customization by using a custom icon if you were willing to assign it a class_name. But actually in Godot 4, the icon for tool scripts is shown in blue:

It's also worth noting that VisualScript, NativeScript, and C# scripts have their own gear icons in Godot 4:

If someone were interested in working on this feature, maybe they could take look at this related issue as well: https://github.com/godotengine/godot-proposals/issues/2084

[akien-mga]

We discussed this in a proposals review meeting and agree that this seems like a good improvement.

However we'd prefer to keep the script/doc icons on the left side as it currently is. The class icon could be put on the right (and could possibly be clickable to go to the class documentation).

[Calinou]

The problem is, this can't be done currently because the script list uses ItemList. It would have to be changed to use VBoxContainer and buttons to allow for more icons to be added.

This can be done by either allowing ItemList to have icons on the right, or use custom drawing to draw the icons on the right (NOTIFICATION_DRAW in C++). I don't think we should switch to Tree to achieve this.

[Valla-Chan]

would you be able to post the code for this so it can be implemented into custom branches?

[Mickeon]

Regarding the visualization of the class reference pages, I'm going to send the following mockup here for future reference:

Note that implementing anything like this is not as easy as it may seem.

[aXu-AP]

I think it's doable, and doesn't require big modifications to my pr either. I'd add a dark box around DOC. Scripts should get the same treatment then: We could use either the familiar gear icon or something like "gd" icon (translates better to C# icon)

However, I'm not sure if I prefer this to separate icons. Now it's harder to see the difference between docs and scripts 🤔

[Mickeon]

Yeah, the mockup does not affect non-documentation pages. Doing so makes things way more confusing and noisy. I don't think many would champion for it.

[tetrapod00]

I also think adding icons on the right uses up more horizontal space that it doesn't need to. Perhaps for script files, we could use the script's custom icon with a quarter-size gear icon in the lower left corner?

---

It might be worth looking at the shader editor for an implementation, which already draws another icon (red dot) over the shader icon, to indicate compiler errors. I was actually just considering trying to port that ability over to the script editor.

I was also considering whether that same functionality could be used to indicate unsaved files (with a yellow dot), as currently the script editor cuts off the unsaved (*) indicator even for new_script.gd when at minimum width. I bring this up as another example of how horizontal space is at a premium.

See also https://github.com/godotengine/godot-proposals/issues/218 which is not implemented because of horizontal space concerns. If I personally had to choose between a close button and a node icon, I would choose a close button.

[aXu-AP]

Yeah, the mockup does not affect non-documentation pages. Doing so makes things way more confusing and noisy. I don't think many would champion for it.

If I were to choose between icons for docs or icons for scripts, I would take the latter. Opening scripts from the list happens a lot more often. I rarely open docs from the list, I either ctrl+click identifiers or F1 them, because I need some certain property or method explained.

Perhaps for script files, we could use the script's custom icon with a quarter-size gear icon in the lower left corner?

Might be hard to see on standard/low resolution displays. The icon should be redesigned for 8x8 grid then.

Edit: While I do understand that people use different screens (4:3, portrait or small screen), on regular 1080p display and 100% editor scale there's plenty of space for the code editor (about 120-130 characters even if you make docks wider than they are by default). I think script list panel could be a tad wider by default.

[tetrapod00]

I think script list panel could be a tad wider by default.

If you make this change, it should probably match the minimum width of shader editor list panel. That could involve changes to both panels to unify their minimum widths at some intermediate values:

I would argue against any more minimum width in the editor, but that's a larger discussion that I think has happened elsewhere?

[seppoday]

I will just post simple idea. Make 2 sections. One for scripts one for doc and just change icons to classes.

[aXu-AP]

Idea is otherwise good, but it doesn't differentiate between normal and tool scripts. Maybe a blue dot over the icon? Also no difference gdscript and potentially other script types like C#. Altough the editor doesn't really support scipts other than gdscript, so I don't know if this is a problem.. For other file types than scripts we can use existing icons.

[seppoday]

Idea is otherwise good, but it doesn't differentiate between normal and tool scripts. Maybe a blue dot over the icon? Also no difference gdscript and potentially other script types like C#. Altough the editor doesn't really support scipts other than gdscript, so I don't know if this is a problem.. For other file types than scripts we can use existing icons.

Maybe subcategories could help with that "issue" but I don't know if it won't overcomplicate stuff.

Kinda like that:

[Zireael07]

For differentiating tool script, the best idea imo would be to just reuse what the filesystem dialog does for tool script (tinted icon iirc)

[aXu-AP]

If you make this change, it should probably match the minimum width of shader editor list panel. That could involve changes to both panels to unify their minimum widths at some intermediate values:

Made a pr for this: godotengine/godot#96909 It makes both minimum size smaller, and default is the same as shader editor's default is currently. Everybody wins 🥳

[aXu-AP]

For differentiating tool script, the best idea imo would be to just reuse what the filesystem dialog does for tool script (tinted icon iirc)

This doesn't work well with different colored icons. For example here's Node3D's red icon tinted blue in the list:

EDIT: I tried implementing @seppoday 's idea, altough I didn't yet separate the list into 2. Eventually it's needed as item list doesn't offer enough flexibility to create good looking headers. Used blue icons for tools, IMO looks good (thanks @tetrapod00 for hinting to look how it's done in shader editor, it's actually something ItemList does out of the box, no custom drawing code needed). I wanted to add red dot for errors as well, but didn't yet find a way to get error state of a script.

[tetrapod00]

Used blue icons for tools

IMO this is not quite the right UI - the dot indicator on the upper left is like a notification. It should be an indicator about a potential action that should be taken. So it makes sense to use a red dot for errors in script, or potentially a yellow dot for warnings in script or for unsaved changes. IMO it doesn't make sense to use for a consistent fact about an item in the list, like a blue dot script being a tool script, or a green dot for the documentation being documentation.

I think a second icon overlayed on the lower left or bottom of the main icon would make sense, like my mockup for a quarter size gear, or the half-gear mockup, or the mockup with "DOCS" across the bottom of the icon.

[aXu-AP]

Hmm, you do have a point there.

Drawing 2 dots on one 16x16 icon might be a bit much (covers half of the icon). But at the same time error/unsaved dot is temporary, it's not bad if it grabs some extra attention. One alternative I thought up is using borders around the icon (not sure how I feel about this, but anyway):

This also would need some changes to allow ItemList to draw even more icons (this "tag icon" functionality isn't exposed, so it should be fine).

[tetrapod00]

Borders around icons might look too close to the existing focus styles? This is a hard problem...

[aXu-AP]

Okay one more mockup before going to sleep. How about blue triangle in bottom-right corner? Seems to work well even when there's red/yellow notification dot.

[aXu-AP]

I made a proof of concept pr for the alternative version: godotengine/godot#96956 (it's mostly functional but needs some tweaking) If this is agreed as the better way, I can finish it.

[timothyqiu]

To be honest, I think showing different icons according to classes creates too much visual clutter.

The various shapes, especially the various colors, compete with the actual filenames for my attention.

[Pacomatic1]

I find it quite the opposite, I think having the icons makes it more readable (and doubly so if you're someone who makes custom icons for their stuff, see above)

[Mickeon]

To be honest, I think showing different icons according to classes creates too much visual clutter.

The same can be said for any way to approach this problem. One may as well remove the icons outright if excessively worrying about visual clutter (the file extension or lack thereof can speak for itself)

[Mickeon]

@seppoday 's mockup is very similar to this comment I don't forget on a related discussion. Just adding fuel to the fire.

One problem that all seem to agree on is that there needs to be a better way to distinguish between documentation pages and text files, while still showing notable icons. Splitting them in 2 categories sounds like a good thing regardless of the final opinion.

[tetrapod00]

If it helps anyone else think about this, here's a table of the current information being displayed in the script editor's list and some of the potential changes discussed in this thread:	Information	Current	Potential
Is script?	Uses gear icon.	Use overlayed half-gear icon. Use overlayed quarter-size gear icon. Separated from the documentation, either under a "Scripts" header or implicit.
Is documentation?	Use a docs icon instead of a gear.	Overlay text on icon. Placed under a "Documentation" header.
Is tool?	Gear icon is blue.	Blue triangle. Blue dot indicator. Blue outline.
Script language	Language overlayed over gear icon if txt or cs. File extension also shown.
Has compile errors?	In shader editor, shown with red dot. In script editor, not shown in list but shown in bottom panel.	Red dot in both script and shader editor.
Has compile warnings?	Not shown.	Yellow dot indicator.
Is saved?	Append (*) to the end of script name.	Yellow dot indicator.
Is currently open?	Line is highlighted.
Is used by open scene?		Line is highlighted (in https://github.com/godotengine/godot-proposals/issues/10750).
Script node type		That's what we're trying to solve here :)

[aXu-AP]

Thanks @tetrapod00 for good overview of the situation.

I posted in reddit to get more opinions from users, and results are mainly positive (96% upvote rate, standing at +178 atm). Comments reflect much of what has been discussed here, with some feel that the idea is helpful and a few are against.

It might be best if this is implemented, it could be setting.

As for collapsable structure, it would go hand in hand with separating documentation. Moving the list into Tree could be a reasonable option then, without need to hack in multiple lists which operate essentially on same data.

[seppoday]

@seppoday 's mockup is very similar to this comment I don't forget on a related discussion. Just adding fuel to the fire.

One problem that all seem to agree on is that there needs to be a better way to distinguish between documentation pages and text files, while still showing notable icons. Splitting them in 2 categories sounds like a good thing regardless of the final opinion.

I forgot about that discussion 😅

[tetrapod00]

I'd say that as a starting point, separating the docs and scripts under categories with does not necessarily need a setting. If enough people really do miss the current single list a setting can be added. Whether to use unique icons per type or the current gear and docs icons does need a setting. There are already plenty of people who strongly prefer the current less busy icons.

[aXu-AP]

And that setting could have none as a third option, as somebody could prefer that also (as the gear icon doesn't give much info or if they need all the space they can have).

[timothyqiu]

The same can be said for any way to approach this problem.

The point is, if most items have a unique icon, then no item has an icon. The icon becomes a pure decoration. Thus visual clutter.

That's why it needs extra effort to distinguish between scripts and documents with this solution.

[aXu-AP]

The point is, if most items have a unique icon, then no item has an icon.

Keep in mind that these mockups are a bit exeggerated with every script having different icon. I tried opening some real projects of mine with custom build and this is how it looks for me:

Btw, I don't even know about these class icons, that new yellow highlight is super attention grabbing (and of warning color no less) 🧐 EDIT: It seems that the yellow highlight is not new, but old feature which I accidentally enabled in my custom build 😂 Details in #10750

[aXu-AP]

One point that has been brought up only briefly for discussion is (scene) built-in scripts. Currently editor uses different icon for them (gear outline). Seeing that the filename already sets it very far from anything else on the list, I wouldn't worry about losing this feature.

[Pacomatic1]

Since horizontal space is at a premium, what if we use some of the vertical dead space?

For example, what if we used a line on the bottom of the selected script instead of using a yellow dot to indicate a compile warning?

Or we could do something like this: Yes, horizontal space is at a premium, but this is dead space so it's not being used anyways.

[Calinou]

For example, what if we used a line on the bottom of the selected script instead of using a yellow dot to indicate a compile warning?

A line at the bottom might be misleading, as it might be interpreted as being a line at the top of the script below it. A line on the left looks like a better choice to me.

[Pacomatic1]

Double that, I was also worrying about that while making the mockup. That's the reason I used a photo with a script already selected.