Reorganize Output dock

[KoBeWi]

• Moves the buttons to the bottom, next to the filter.
• Removes filter toggle (it's now always visible).
• Reduces minimum size.

godot.windows.editor.dev.x86_64_EwnG5LlkW1.mp4

I also extended #111499 to support default sizes (by using default layout as fallback), so the Output does not start small.

Fixes #26392

[passivestar]

tested, the output panel is using the smallest possible height by default which is too small:

[KoBeWi]

Should be fixed now.

[akien-mga]

Moves the buttons to the bottom, next to the filter.

How does it look when getting spammed errors/warnings at runtime? I worry going to 2, 3, 4 digits etc. will cause jumps which may be jarring (mainly 1->2 digits I guess).

Does it impact the min width of the Output dock / main viewport when on a tiny form factor?

[passivestar]

setting min width on those to fit 2 digits should be fine, realistically the searchbar doesn't need to fit a lot of text

I'm also not sure why the copy button exists, everywhere else in the editor copying is only exposed via a context menu button and it seems to be enough

[KoBeWi]

Yeah seems like Copy button can be removed.

Does it impact the min width of the Output dock / main viewport when on a tiny form factor?

The editor can't get small enough to hit minimum size of the new Output bar, so for now it's not a problem. Although I didn't test with more digits.

[KoBeWi]

This is the smallest I managed to shrink the Output:

The filter box should probably have a minimum size, but it's unlikely someone will get it as little. Most often the minimum size of the editor is determined by the main screen buttons, or by the the toolbar (2D/3D/Script, Game seems to have the smallest width).

EDIT:
With HFlowContainer:

[AdriaandeJongh]

I didn't look at the code and will test a bit more later (after a rebase), but would love to see this PR merged eventually as the layout change makes a lot of sense to me: for one, the ability to further reduce the output panel's height is great for dock management.

[PoshIndie]

I only included those two for less verbose typing of references to the buttons (I am on mobile). I, personally, am having a hard time thinking of a situation where knowing exactly how many there are (of any of them) solves a real problem. At 100+ you are almost definitely filtering them vs reading them one-by-one (I would hope).

In any case... why not include a tooltip when hovering the buttons that shows exact count (For those that need it)? Everyone wins, haha.

[arkology]

Anyway, this is something that could be improved in following PRs and letting people touch new output dock in next dev build to get more feedback will be not so bad idea, right?

[PoshIndie]

Of course!

I was just dropping some ideas in here for potential solutions to status quo vs concerns while reading through. I saw this one in passing as I was digging through the 4.7 milestone, is all. Consider me a Godot Github Transient at this time, haha.

[arkology]

@PoshIndie Please don't take this personally, it was not directed at you personally, but at the discussion in general :)

[PoshIndie]

Nothing taken personally! It is good to get counterpoints; It drives discussion and helps narrow to an optimal end result. I can honestly see pros and cons to both sides (I am mostly indifferent here).

(Likewise, my comments were directed at the general discussion/topic itself!)

[KoBeWi]

Eh, any suggestions how to set minimum size to fit specified number of digits? I can't just hard-code it, because it depends on theme scale, font size, icon size, etc.

[PoshIndie]

Valid question, and I lack a definitive answer to that one, as you are correct in the current context (Godot source code. I would need to dig in and investigate options) when it comes to "needs" to achieve it.

In the absence of anyone with more knowledge of Godot's source having a solution... it could be something to look into later.

I only have "general case" knowledge of how I achieved it in the past with similar things:

• Utilize a String with "WWWW" (4 in this specific case. "W" usually being one of the widest characters in Fonts). I guess it could be simplified as "Choose the widest character, get its width, and multiply that by 4". I also guess the character selection for necessary width is more limited (0-9 and +), so "W" was just "for example".
• "Get the width of the String" (This is kind of the "Finish the Owl" of the process, as if and/or how this can be/is achieved is very dependent on existing implementations/internal features determining viability (For instance, one would need to get the width of a character in the current font). I just do not have that level of intimate Godot source knowledge).

I keyed in on the "String width" as I would think the UI elements housing everything would adapt for UI Scale and such?

I could also be way off here, so I will leave it at that, haha.

[YuriSizov]

@arkology

...and "Clear" button will remain in the same position in the Output Dock if we enable horizontal expand for box container (if it's not already enabled).

Sure. Although shoving the most used (IMO) button into the furthest corner is kinda awkward. It feels to me that the usability is compromised just to make this particular change work, rather than usability being the goal of any change.

That's a different issue, and I think it should be addressed separately.

Not at all. It's the big argument in favor of this change, to be able to reclaim vertical space by allowing shorter output log. I'm just putting it in the context of the entire editor UI. There remain bottom editors and docks which will take as much or more space. And there is a limit to how much you could even potentially reduce them before it becomes ridiculous and unusable.

I'm not sure what split screen mode you refer to, but assuming it's about showing the editor and the game (or code editor) side by side, reducing vertical size of bottom docks doesn't really help with that. Besides, why is that even a goal? Is that useful to a lot of people to shrink the editor so much? Like, I'm not saying it isn't, but this PR closes a 7 year old ticket for Godot 3.1, and you working on PRs isn't really a measure of public interest or practical need of many. No offense.

So I believe my original point stands. Though it has been ruled a non-blocker already, so ¯_(ツ)_/¯

[YuriSizov]

Eh, any suggestions how to set minimum size to fit specified number of digits? I can't just hard-code it, because it depends on theme scale, font size, icon size, etc.

The cleanest solution would probably be outside of scope of this PR. You add 2 properties to the button (either via theme, or normally), one for the number of characters and another for the character itself. You then use the string of that character repeated that number of times as the minimum for the computed text size. That part is straightforward with TextLine.

That way, you only need the font and the font size, and don't hardcode anything other than the desired length.

[arkology]

Eh, any suggestions how to set minimum size to fit specified number of digits? I can't just hard-code it, because it depends on theme scale, font size, icon size, etc.

Maybe using this

godot/scene/gui/button.cpp

Line 483 in bfbe95e

Size2 Button::get_minimum_size_for_text_and_icon(const String &p_text, Ref<Texture2D> p_icon) const {

[KoBeWi]

Yeah I forgot get_minimum_size_for_text_and_icon() exists. Done.

5WjgAUf9BO.mp4

[ryevdokimov]

The output dock is unexpectedly intercepting the open_search shortcut when I try to search in at least the asset library now.

2026-03-07.00-26-06.mp4

[KoBeWi]

Fixed.

[ryevdokimov]

LGTM

[kitbdev]

This doesn't seem to work correctly for me, its not big enough for 3 characters so it changes size. display scale at 100%, default theme settings.
It does work at 75%, and its worse at 125%, only digit fits there before resizing.

100:

125:

[akien-mga]

Might work better with www to be safe? Not sure if 9 is considered the wider number in all fonts.
I also wonder if button->get_minimum_size_for_text_and_icon properly considers the editor theme or if that's applied after the fact?

CC @bruvzg

[KoBeWi]

Changed to MMM and multiplied by EDSCALE. It guarantees at least 3 digits.

[kitbdev]

Something is still off about the scaling, but it does have a minimum of 3 digits at each scale so its fine for now.

In the future we should investigate it more, at 175% it has a minimum of 10 digits:

[KoBeWi]

The digit count could be correct if the font and icons scaled with the buttons 🙃

[Repiteo]

Thanks!

[pippenpaddleopsicopolis]

Noticed a small UI "issue" that is not present in the latest release.
This happens when "interface/theme/follow_system_theme" is changed from the editor setting.

The "Filter Messages" input takes an entire line and the buttons are bigger.

This is my system info

Godot v4.7.dev2 - macOS Tahoe (26.3.0) - Multi-window, 1 monitor - Metal (Forward+) - integrated Apple M4 Max (Apple9) - Apple M4 Max (16 threads) - 64.00 GiB memory

[arkology]

@pippenpaddleopsicopolis Please open separate issue.
Maybe get_minimum_size_for_text_and_icon() has bugs.

[plyoung]

Will there be an option to revert to the old layout? I've never used the filter but if I did I could turn it on quickly and then off again. I do regularly need the buttons to filter message types. Now it will waste vertical space on displays with more horizontal space available.

It is also does not seem to follow the Spacing Preset properly and presenting the whole bar with bigger height than it should. 1st shot is "Default" vs the 2nd "Compact". Compact looks bad. [edit] seems like editor restart kinda fix it but it feels like the filter bar and buttons are still bigger than they should be for compact mode.

[plyoung]

Opened an older project today and this is the result. This is with the spacing preset on default. it happens every time I restart the editor on this project. I have to go into editor settings and switch between presets to get this new bar to adopt a more reasonable height. This feels very unpolished and broken.