Use renderer icons instead of text to reduce the topbar width.

[WhalesState]

The Renderer button now only displays the item's text when pressed, helping to reduce the top bar width.

When the Renderer is overridden, the icon will turn red and will only show the full name with (Overridden) when it's pressed.

Icons when not hovered or pressed:

[Calinou]

• Related to Replace editor renderer dropdown with icon next to version button #103042.

[syntaxerror247]

I want to minimize the width as much as possible, so I prefer #103042 since it reduces the width more effectively and I don't see issue with removing the renderer change option from there. However, if removing it is a deal breaker, then this alternative seems like a good compromise.

[WhalesState]

I want to minimize the width as much as possible, so I prefer #103042 since it reduces the width more effectively and I don't see issue with removing the renderer change option from there. However, if removing it is a deal breaker, then this alternative seems like a good compromise.

• Another fix similar to this one Fix BottomPanel excessive width. #97878 will help reducing the size of the top panel if we apply it to the main screen editor plugin buttons.

like this:

Screencast.From.2025-08-06.19-04-23.mp4

• Also I was thinking about applying a fix for the MenuBar inspired from VSCode:

Screencast.From.2025-08-06.19-11-29.mp4

It should be discussed with the Godot devs first to see which fix is better to be implemented, the first one is ready and the second one will require much work and discussions to find the best way to implement it without breaking compatibility or causing regressions, also if we apply the second option it will reproduce the issue when having many main screen editor plugins.

[dsnopek]

While I like the idea of using icons here, when only the icon is visible, they don't feel very visually distinct from each other. Like, if I was looking at only one of the icons at a time, I personally would have trouble remembering which renderer it represents.

[WhalesState]

While I like the idea of using icons here, when only the icon is visible, they don't feel very visually distinct from each other. Like, if I was looking at only one of the icons at a time, I personally would have trouble remembering which renderer it represents.

There are 3 different colors used for Renderers, Green for Forward+, Pink for Mobile and blue for Compatibility, but I'd agree with any better icon ideas to make them more unique.

[Meorge]

Perhaps Forward+ could be depicted by a "modern" computer monitor, Mobile a phone (as it does now), and Compatibility an older-looking monitor?

[WhalesState]

Perhaps Forward+ could be depicted by a "modern" computer monitor, Mobile a phone (as it does now), and Compatibility an older-looking monitor?

Or maybe we can make the Forward+ icon have a + sign.

[bruvzg]

Perhaps Forward+ could be depicted by a "modern" computer monitor, Mobile a phone (as it does now), and Compatibility an older-looking monitor?

macOS network icons style? It won't be easy to make it clear enough with 16×16 monochrome icons.

[WhalesState]

I have tried to do this before and I didn't like the + sign for Forward+, that's why i have used a - sign for Compatibility instead.

[passivestar]

I agree with Clay's comment and with syntaxerror's comment, unless switching between renderers mid-project is a common operation the button is probably not needed. You'd expect a very visible top-level button to support a common workflow, if it's not the case it adds unnecessary UX friction

[Meorge]

macOS network icons style? It won't be easy to make it clear enough with 16×16 monochrome icons.

Definitely, yeah. I think it could be more feasible by exaggerating the monitor types used - an old, closer-to-square monitor like this could work for Compatibility, while a wider monitor like this could be Forward+. The former isn't super representative of the kinds of hardware it'd be likely to run on, and I could see some people feeling mildly insulted about their rendering method being represented by a "ye olde" computer. But at such a small icon size, we'd need that difference in shape to be very clear.

I have tried to do this before and I didn't like the + sign for Forward+, that's why i have used a - sign for Compatibility instead.

Admittedly, it didn't even cross my mind that the Compatibility icon had a minus in it; I just saw it as some kind of an abstract mark. 😅 IMO a minus doesn't really make sense for "Compatibility" anyways, since it supports a wider variety of devices than Forward+ (albeit with fewer graphics features), and doesn't have a minus in its name.

unless switching between renderers mid-project is a common operation the button is probably not needed

I do agree with this, yeah – in my experience, the renderer is something that tends to get set once at the beginning of a project, and then isn't (or is very rarely) touched again. If there are people who toggle renderer modes more frequently, perhaps it could be made into a setting whether to appear in the top corner or at the bottom? Or always keep it at the bottom, and have a setting to toggle its visibility at the top?

[bruvzg]

Definitely, yeah. I think it could be more feasible by exaggerating the monitor types used - an old, closer-to-square monitor like this could work for Compatibility, while a wider monitor like this could be Forward+. The former isn't super representative of the kinds of hardware it'd be likely to run on, and I could see some people feeling mildly insulted about their rendering method being represented by a "ye olde" computer. But at such a small icon size, we'd need that difference in shape to be very clear.

In case of macOS icons, the colors and contrast, not the shape (blue screen and beige border vs. bright screen and black border) probably make it more clear at a small size.