Clean and simplify Game Embed toolbar#118664
Conversation
|
Hiding the reset button for the time scale makes so that everything to the right changes positions when it appears again. This breaks muscle memory, and gives an unpolished look. |
jaydensipe
force-pushed
the
mr-clean-game-toolbar
branch
from
43de6f4 to
493e60b
Compare
Gotcha, @AdriaandeJongh suggested nuking the speed reset button, so I have removed it. |
|
A great visual improvement, looks modern, I would suggest this for other menus where there are buttons |
|
I would suggest something like this for the right side, for embed & floating window. Maybe the icon for embed should be bespoke, but I think it really needs to be eye-catching. 
They are two toggles, not a row of options, but if this [inset buttons container + dropdown] style (which I really like) makes it to the rest of the editor interface, then a similar paradigm to this would eventually be observed here, in the 3D viewport. 
The floating toggle is also disabled in whatever state it was in, which I think is incorrect. It should be styled 
|
Agreed, I plan to tackle that toolbar after this. |
Great idea, I'll add this next push. |
Added:@vaner-org's suggestion for the embed options 
-- @arkology's suggestion for classic theme support Dark: 
Light: 
|
jaydensipe
force-pushed
the
mr-clean-game-toolbar
branch
from
493e60b to
09e1302
Compare
jaydensipe
force-pushed
the
mr-clean-game-toolbar
branch
from
09e1302 to
ba9f92e
Compare
|
Looking good! The accent mixing with the red of the icon I picked looks unsavoury though... haha. I think maybe a better choice or unique icon is warranted... I will try to come up with something, please do as well. Also, indication of window floating being locked into true could be better... I know the lock toggle in the 2D/3D editor toolbars changes its icon depending on state, and so does the mute button in the leftside block. Something like this? 
If not unique icons for each, maybe the icon could be accented when locked? I'm not sure if I've seen that elsewhere though. Finally, if these buttons are to remain on the right, this dropdown could do with repositioning, since it awkwardly pops out of the playable window right now.
|
jaydensipe
force-pushed
the
mr-clean-game-toolbar
branch
2 times, most recently
from
7d3dbad to
e9e341d
Compare
|
This embed button design looks like a record button with a mouse cursor on it and it's very confusing to me. Taking the bird eye perspective and from a user perspective (and explicitly not from a engine dev / technical perspective), there are essentially 3 run modes:
I still think this user decision should be part of the run bar (as per my proposal) and not part of the corner of the game view... but if we really, desperately want to make this in-between version while someone hopefully addresses improving the run bar, I think we should already head into the direction of framing the three options as such. |
|
I was just working on this! The documentation defines embedding as three states too. That way, the "box of options of which only one can be selected" rule for this new themed box is consistent. 
|
AdriaandeJongh
left a comment
AdriaandeJongh
left a comment
There was a problem hiding this comment.
- As we've removed the reset button, perhaps there would be a way to indicate the 1.0x in the game speed list as the default, to quickly see at a glance where to click after you've set it to something else. Perhaps, if anything but the 1.0x option is selected, the selected option should always be yellow in the list, and the default could be blue maybe? Just brainstorming here.
- The mute game audio button isn't square for me.
|
@vaner-org your designs are certainly going into the right direction! Could you perhaps make a test to also put the blue bar at the top of what you call the EmbedFloating option? That way, we can already nudge at the difference between embed floating and embed disabled: that there is or isn't a game bar at the top. |
|
The separator can be removed from this design; the label and the box with options are already separated enough through the option box background. |
|
I tried this initally, felt a liiiittle cramped to me. But yeah, makes more sense to have it. Also, the same in the Godot blue, if that matters at all. It does represent the "engine" after all, and won't change with accents. |
Added:New icons for embedding options from vaner-org. 
--
@vaner-org I used the original gray icon for the "Disabled" button, but the gray was lost when it was selected, so I changed it to blue, let me know if you wanna modify it further. |
|
Great work everyone involved! |
|
Why does selected 1x speed show as outline? EDIT: |
Fixed! Recording.2026-05-01.191934.mp4
Fixed!
Also fixed. 
|
jaydensipe
force-pushed
the
mr-clean-game-toolbar
branch
2 times, most recently
from
1a58f7e to
09b2584
Compare
|
Sorry it seems I'm a bit late to the party. Things like this seem to move quite fast! Thanks for your work on this! It seems this PR makes the game view bar 24% taller. On my screen that means 12 pixels are lost (62 pixels tall instead of 50 pixels). Is there any way we can work this to stay slim and still solve the usability issues that this PR aims to resolve? Regarding the window options menu and its changes: 
I've read through the comments, but I haven't been able to find the rationale that describes why these should be presented as three buttons that do not have labels and that the resolution/HDR options should be moved away from the resolution/HDR label. This design has the following problems:
Here are some ways to resolve these issues: Approach A
When this new button is tapped, a Approach BAnother option is to make the above changes to the existing (before this PR) window options menu. I prefer this approach over Approach A because I think it is a bad user experience to move the embedded window option around (again) if the long term plan is to move these (again) to the run buttons of the editor. 
(Note: The concern that "The embed options are hidden under a button with no dropdown icon next to it." that was raised in godotengine/godot-proposals#14445 has already been resolved with #118079, which makes the embedded options much easier to find under a three stacked dots icon rather than hidden under a button that does not suggest a Approach CSimply remove all changes to the window options popup menu from this PR and leave changes for another followup PR that implements Approach A, B, or godotengine/godot-proposals#14491 after further discussion. This is obviously the simplest and easiest approach. I'm also happy with this, but it does leave the existing usability issue regarding two checkboxes representing three floating/embedded options. Notes
|
See comments onward from here.
I have to change this setting all the time, pretty much every single time I need to record a gameplay clip for promotional purposes. The default setting being a floating window also pretty much guarantees that no user will ever organically discover the true use of the game tab (encasing the game window within the editor), were these options to be as hidden as they currently are. |
I 100% agree. I like this PRs design because it exposes the window embed options in a way that the user will want to know what they are instead of never realizing that the options exist at all because they are hidden behind a nondescript option menu button. I use also use these options all the time for testing so having them like how they are in this PR is very appealing for me as well |
|
I do agree with @allenwp on the subject that the toolbar is way too thick now. Not just slightly reducing the available area for the game, but also making it stand out in comparison to other toolbars in the editor. There has be a way to slim it down while still keeping most of the styling changes. |
jaydensipe
force-pushed
the
mr-clean-game-toolbar
branch
from
09b2584 to
86813d5
Compare
So I got rid of the weird scaling code I had, and set a maximum height that mimics the other toolbars. My plan is to apply this styling to the other toolbars as well, so we could argue a point to increase the size a bit if needed, but I think this new one looks ok. 
-- One thing I am unsure of is a clever way to tackle this, where the buttons that are inside the panel are obviously more squished then the outer buttons. Not breaking, but something to note. Recording.2026-05-14.160533.mp4 |
|
I think the majority of Allen's remarks would be addressed if we move the embed options to the run bar where they belong 😏. I wasn't bothered by the height, but the latest version looks good to me. Regarding the outer buttons: unless we make them shrink to become square (which would be prettier, but not better per se) there isn't really another solution. It's fine like this 🤷🏼 |
With this in mind, I believe it's best to go with "Approach C" that I suggested. |
I think we should keep them, though I won't die on the hill to keep the current design. Either the current design or your option A make the run modes a lot more discoverable than they are in |
jaydensipe
force-pushed
the
mr-clean-game-toolbar
branch
from
86813d5 to
bb83381
Compare
|
Pushed an update that is like @allenwp's "Approach A", so we can play around with that vs. the original 3. Only thing I kind of don't like is how verbose the wording is for it, but I couldn't think of anything much better either. Recording.2026-05-19.181911.mp4 |
|
At first glance I don't think I like this more than just having the 3 icons there, but it does reduce the minimum width. So... 🤷🏼 |
In my opinion discoverability of the options stranded on the right edge matters more than minimum width... it's the main game window, it's one of the widest panels we have. |
|
Please do not change the resolution/HDR label and the three dots |
|
That would mean the right-sided elements appearing in the order: 1. embedding buttons, 2. resolution and 3. three dots button. The resolution indicator is optional, and doesn't appear until the game is running. Earlier, the reset button was removed from beside the speed setting in order to not have elements move, for the sake of muscle memory, here. What you're saying would make the resolution label move the embedding options, when it appears on game run. It has been noted here, here and in your closed PR here that the three dots menu is ambiguous, and including it on the right edge is confusing due to the amount of times its used there to manage docks in the editor. This PR generally replaces them with the dropdown arrows, so I apologise if I'm beating a dead horse here but I am truly puzzled by the fixation with the three dots, in this place. |
|
I explained this problem with my initial comment on this PR:
My fixation is on placing the resolution and HDR Again, the embedded window options (with toolbar, without toolbar, and embedded) will later be removed entirely from the game view's toolbar and moved to be beside the run button. So when we do this, it would be better to not need to rework the resolution and HDR label and options again. |
This issue is resolved by moving the embedded window setting (with toolbar, without toolbar, and embedded) to be beside the run button where we all agree it belongs. This is why I think it's better to just implement this change to the run button in a later PR instead of this intermediate change that might even get discarded before 4.8 goes stable. |
|
Okay. I think it's safe to say we all agree about the run bar in the future, and it's safe to say that we all agree about the discoverability issue in the current On the right hand side, we could follow this order, for 4.7:
As a result:
If that migration thing doesn't make sense for one cycle, we can remove the separator and move the embedding options back to where they were before #118079, as the rightmost member of the left row, with just the facelift and three state improvement, and leave the right side entirely for the resolution label and newly-added HDR switch. This way, we don't impact pre-exisiting features until the time comes to actually move things around. Hoping this makes sense. I agree that changing something's placement just for one release cycle isn't the smartest idea, but unfortunately that's what #118079 did, so maybe undoing said merge of HDR (which will stay here) and embedding (which will soon leave) into the same menu would be best. |
This is effectively my original design proposal in godotengine/godot-proposals#13903. It was made abundantly clear by a large number of people that dedicating a button on the game view's toolbar to HDR was very undesirable because this is a feature that very few people would use. To be clear, the end goal is something like this: 
I apologize that it seemed like I was stuck on three dots icon: the reason the three dots is needed right now is simply because that's where the "embedded/floating" options are in |
|
Unfortunately the TabBarInner style, used in this PR and across the current engine only houses buttons, so enlarging to fit the resolution label in your mockup feels a bit out of place. There isn't currently a separator; their relatedness will be obvious.
If this is the case then I don't think we can have it both ways. The HDR switch is either important enough to demand its own very specific place in the layout, or unimportant enough for it not to matter that the shared dropdown it lives in is a few buttons away from its closest relative: that too one that only appears when the game is running. We have an opportunity in 4.7, via #118079, to teach users to look to their right, where resolution once sat alone, for window options. This, in a later version, can become asking them to look ever so slightly up at the overhauled Run Bar for run options specifically. When that happens, the embedding buttons will probably leave, while the sizing options (fixed size, keep aspect, and stretch to fit) would stay in the dropdown along with the HDR toggle, and be perfectly adjacent, as @allenwp desires, to the resolution label. Even setting all of this aside: if the first half of the info label - the resolution - is universally, if not exclusively, affected by first six buttons (three outside and three in dropdown), and the second half of the label, the HDR postfix, is affected by the last button in the dropdown, doesn't the order already make sense? If the window state didn't already make it obvious which embedding level we were on, I'm sure it would predate the resolution block in the label too. Also, HDR might not be important enough to need its own button now, but other window options added in the future might. The theme for this space on the right can be made clear now, by moving and foregrounding something that users are either likely to look for, or would behoove us to educate more users about: embedding. Even if it gets removed one version later, the association will remain, which should benefit both the toolbar's organisation and the run bar's future role. All of this can happen organically, across versions, with the already-approved design of this PR. I hope what I'm saying makes sense. I don't mean in the slightest to come off as aggressive, I'm only trying to lay out my rationale for sticking with the approved design. |
|
The only point I’ve been trying to make is that the button that brings up the By placing the run modes between the resolution and dynamic range label and the button that brings up the resolution and dynamic range I really did not expect this to be such a big deal to reorder some buttons to address this. |
|
What I'm trying to explain is that it is directly beside it. The whole grey block is currently composed of two radios of options and one toggle, all of which control the game window. At the moment, it just so happens that the first radio set is outside the dropdown as a button group for the sake of quick access and discoverability.
The dropdown is just an overflow for all game window options, of which many more might be added, that aren't specifically to do with the label. Then, it might be worth it to fragment things. But at a more abstract level, all of these options are for changing perceivable elements of the game window, not for changing the label. The label is tertiary, it's there to reinforce visible parameters with exact metrics, should the user need it, while the game runs. |
13 participants
Also renamed a couple tooltips to better match other parts of the editor, this can be removed if wanted.
--
Screen.Recording.2026-04-17.000755.mp4
Screen.Recording.2026-04-19.044535.mp4