[Draft] Implemented dedicated shader editor

[Chaosus]

I've decided to attempt to implement: #26229 (gradually) since it is accepted in UI proposals:

The result will look almost exactly like in the proposal:

ToDo List:

• Basic layout
• Spatial preview options
• Canvas Item preview options
• Dynamic switch possible previews for each shader type
• Shaders list (recent list)
• Vertical dock option
• File menu
• Sky preview options
• Particles preview options
• Dedicated Visual Shader Editor (?) - maybe later, in other PR

Show GIF Presentation

[aaronfranke]

Here's an alternate proposal:

With Godot 4.0, we will have the ability to use multiple windows in the editor. Why not allow opening the shader in the regular script editor, then allow popping out the script editor to a separate window? This would be simpler, and in many ways nicer. You could arrange the windows however you like, on multiple screens, or side by side like in the image in OP:

[Riteo]

Why not allow opening the shader in the regular script editor, then allow popping out the script editor to a separate window?

+1 on this. This would actually allow some quite nice stuff too, such as multi-script editing (I don't know if there's already a way to do it, but I didn't find it when I needed it)

[YuriSizov]

Why not allow opening the shader in the regular script editor, then allow popping out the script editor to a separate window?

From the look of the image in the OP, the preview part on the right is not the same as a 2d/3d viewport. It's a part of this new editor, only shows the object that is being edited, doesn't allow modifications (because it doesn't preview a scene) and has several preview modes.

[groud]

I am not sure where you got this spreadsheet from, I don't remember this was discussed. Personally, I don't understand why a resource editor would have a dedicated tab at the top, making it more privileged than any other editor. If we start to allow this, why does the TileSet editor, the UV polygon editor or the Theme editor don't have their own tabs then?

Aside from that, I am not against adding a preview of the shader next to the editor, but for now, it should be kept at the bottom.

[YuriSizov]

Personally, I don't understand why a resource editor would have a dedicated tab at the top, making it more privileged than any other editor.

If you look at it this way, the Script editor is a resource editor. And it's on the top bar. As a user I don't see much reason for some of those tools to appear at the bottom panel. It just feels like a gutter for things we didn't find another place for. And a shader editor, among other editors, definitely needs more space than the bottom panel provides. Yes, I know you can extend it. But as the nature of the bottom panel is to be shared with other tools, you don't necessarily need it extended for those as well. So it is a constant game of adjusting its size when switching tools.

But maybe we should solve this with a dedicated UI relocation PR.

[aaronfranke]

Editing shaders would fit right at home in the Script editor (including visual shaders), the only problem is that we are missing the ability to view the object while the shader is being edited (which will not be a problem in Godot 4.0 if you pop out the script editor).

[groud]

If you look at it this way, the Script editor is a resource editor

Yes, and to be honest, I don't like this either being here.

What I mean is that moving every editor lacking space to a new tab is not a viable solution to me (that's why I mentioned the TileSet editor, which is a little bit cramped too). I understand all the problem the current situation causes, especially to the shader editor, but I don't want to allow for a workaround-ish specific solution, while the problem is common to a lot of resources editors.

So for now, I'd keep everything at the bottom, and wait for a good proposal solving the space problem for all cramped resources editors first.

[fire]

I don't see why we should be blocking this proposal over the location of the entry ui. The shader editor is a good proposal.

Why can't the shader editor have its own editor? It makes sense to use additional space to display the most amount of workspace for the purpose of a task. Phones and other space constrained uis have solved this problem.

Many phones have 4 slots in the dock and then the choice to choose from like 8 pages of apps.

[vitorbalbio]

This is a very bad UI proposal. It aggravates even more the lack of meaning of the top bar mixing 2 viewport options a browser (asset lib) and two script views. It's a mess.

Here's my long explanation why:
godotengine/godot-proposals#1508 (comment)

[fire]

We discussed in chat about the dock.

It's not how many options are on the top menu, but it's a matter of the consistency of what is there on the menu.

There are also two inconsistent separate menus—one at the top and one at the bottom.

We also noted that each editor could scale from a smaller size to full-screen.

---

I don't think this proposal needed to change except by making ensuring there is only one editor that can expand to full screen.

I propose to enhance the dock via ribbon style or progressively collapsing navigation. We can also make the dock more consistent by forcing the grouping of separated items and removing the second menu at the bottom.

Sources:

• https://kyusuf.com/post/completely-css-progressively-collapsing-navigation/
• https://en.wikipedia.org/wiki/Ribbon_(computing)

[Calinou]

As for solving the shader editor real estate issue, see #36040.

[Chaosus]

I think the @Calinou proposal is compact and better and lost interest to develop this PR futher. Thanks for the discussion. Closed.