Implement extend to title for Windows and Linux

[Hilderin]

• Implements proposal Add an editor setting to enable border-less mode on Windows and Linux (client-side decorations) godot-proposals#4846

This PR implements the EXTEND_TO_TITLE flag for Windows and Linux X11. Implementing this flag allows Windows and Linux to use the editor without the default title bar. Additionally, it makes it possible to use this flag in any Godot project outside the editor.

Since Windows and Linux don’t natively support this mode, it is "simulated" by providing a resizable borderless window with minimize, maximize, and close buttons rendered directly in the Window class. New properties were added to the Window Theme to define the button icons, positions, and styles.

Here’s a little demo:

Windows:

godot.windows.editor.dev.x86_64_5zKbXLNLPu.mp4

Linux:

[bruvzg]

I'm not sure if we want a separate flag for it, might be better to merge it with FEATURE_EXTEND_TO_TITLE (it's the same, but OS draw the buttons) and move window min/max/close buttons from a separate controls to Window class (for non macOS).

[bughandler]

I've been working on the same feature for the past few days and have a few questions.

1. I wonder if we really need to add a new flag instead of using the existing WINDOW_FLAG_EXTEND_TO_TITLE, which is already widely used in the MacOS implementation.
2. As shown in the screenshot below, I believe your implementation may not work on Windows 7/10 when the editor is in windowed mode, as it could result in a white border around the window. You may need to leverage the DWM APIs to resolve this issue.
3. Additionally, the project manager window should have the same no-title-bar appearance when the corresponding setting is enabled.

[Hilderin]

I'm not sure if we want a separate flag for it, might be better to merge it with FEATURE_EXTEND_TO_TITLE (it's the same, but OS draw the buttons) and move window min/max/close buttons from a separate controls to Window class (for non macOS).

That's a interesting suggestion, I'll think about it. It should be easier to implement in the Project Manager or other windows in the future if the buttons are drawn directly in the Window class. I thought it could be interesting for games/app created with Godot to be able to create resizable without without the window min/max/close buttons. It could be added later.

[Hilderin]

I wonder if we really need to add a new flag instead of using the existing WINDOW_FLAG_EXTEND_TO_TITLE, which is already widely used in the MacOS implementation.

I'll look into it, bruvzg made the same suggestion.

As shown in the screenshot below, I believe your implementation may not work on Windows 7/10 when the editor is in windowed mode, as it could result in a white border around the window. You may need to leverage the DWM APIs to resolve this issue.

I'm curious how you implemented it.

Additionally, the project manager window should have the same no-title-bar appearance when the corresponding setting is enabled.

Indeed.

[bughandler]

I'm curious how you implemented it.

FYI: https://learn.microsoft.com/en-us/windows/win32/dwm/customframe

The screenshot below shows the project manager window run in windowed mode on Windows 10, notice the shadow around the window.

[Hilderin]

I fixed the issue with the white border on top of the window on Windows 7/10. Thanks bughandler!

If you want to work on that together @bughandler, I'm available in the Godot Contributors Chat: https://chat.godotengine.org

[Hilderin]

@bruvzg I was working on using the already existing flag WINDOW_FLAG_EXTEND_TO_TITLE and implementing the rendering of the window buttons directly in the Window class. I have no problem using this flag, but I'm concerned about rendering the buttons directly in the Window class.

Should I create a control for that and add it to the scene? That would be the easiest way, but my concern is that these controls would be present in the scene tree at runtime for any project that uses WINDOW_FLAG_EXTEND_TO_TITLE.

The other alternative could be to manage the rendering manually, like in Viewport::_sub_window_update, but that seems to be very complex, especially for handling mouse over, clicks, etc.

What’s the best approach?

[Hilderin]

Added support for Linux x11...

[Hilderin]

@Calinou
I changed a bit the icons to be smaller and less "chunky" (1 pixel path width instead of 2 pixels). Now that the window icons are not aligned with the buttons in Godot, having a different style was essential because it look just not aligned. The buttons are now 32x32. It's like that in Steam, I personally like the smaller buttons, it saves a couple of pixels, but I can make them the same size as the default Windows 11 size.
Also removed the background when not hover the buttons.

When maximized:

What do you think?

These changed are not pushed yet, I still need to fix the full screen mode, the margin to put the menu in the corner, the border in splash screen of the Project Manager, and the distorting bug when any form of pillar/letterboxing is applied.

[Hilderin]

Made some fixes/adjustments:

• Fixed fullscreen mode where the space for the buttons was left empty.
• Fixed issue when exiting fullscreen mode where the buttons were not visible again.
• Fixed Project Manager and Editor showing a border for a brief period during startup.
• Made the icons for Minimize, Maximize, and Restore a bit smaller.
• Adjusted the button size depending on spacing settings in the editor.
• Fixed an empty line at the bottom when maximized at startup.
• Fixed Right-To-Left layout.
• Fixed stretch mode.

Default theme:

Compact:

No spacing at all:

Fullscreen mode:

Right-to-Left:

@Calinou This should fix everything you mentioned in your previous post, except for moving the main menu to the top-left corner. There are already some settings in the editor to specify spacing, and the editor uses these to define the global margin. I'm not sure I want to change that behavior in this PR?!?

[Riteo]

Hi, I finally have a patch for Wayland. You can find it in my branch: https://github.com/Riteo/godot/commit/wayland-no-title-bar/

I had trouble adding drawing tablet support on sway so I left that out for now.

Also keep note that if the backend detects and uses libdecor, our current "stopgap" decoration library, it won't be able to disable borders on natively decorated windows due to an upstream bug. #96825 would be useful in this case.

[Geometror]

Needs a rebase after #97333.

[Geometror]

While the project manager is working for me, opening a project results in a fully transparent window on Win11.

[Hilderin]

Rebased to fix conflict with master and fix a transparent line at the bottom when starting in extend to title mode and maximized on Windows.

[Hilderin]

@Geometror

While the project manager is working for me, opening a project results in a fully transparent window on Win11.

First, thanks for testing it! Second, that's weird ;) Can you share with me your editor_settings file, there's probably something that interfere.
You can find it here: C:\Users[username]\AppData\Roaming\Godot\editor_settings-4.4.tres

Can you try restarting the editor after you move all the editor_settings*.tres somewhere else? Just to test if there's really a setting that causes the issue.

Another possibility could be a wrong settings in .godot\editor\editor_layout.cfg in your project folder. This is the file can keeps the position and the state of the last time the editor was used and Godot tries to reapply these settings on startup. Can you also share the with and retry if you move or rename this file?

Also, do you have multiple monitors??

[Geometror]

System info:
Windows 10.0.22631(Windows 11 23H2) - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 Laptop GPU (NVIDIA; 31.0.15.4692) - 12th Gen Intel(R) Core(TM) i7-12700H (20 Threads)
Main screen: 2560x1600, 165Hz
Second screen: 1920x1080, 60Hz

The problem persist even on a fresh config (removed C:\Users[username]\AppData\Roaming\Godot folder).

I have a monitor connected to my laptop right now, which seems to cause the issue: the editor becomes visible when I disconnect the monitor.

[Hilderin]

Thanks a lot, that is very helpful, I'll look into it.

[Mickeon]

I was waiting for the implementation to settle in.

[Hilderin]

Thanks for the review @Mickeon, I made the suggested modifications the best I can.

[scgm0]

The project manager that extends to titles is not a good experience under Linux X11:

1. Moving the window and changing the window size will not trigger desktop effects, such as window shaking.
2. Moving the window isn't smooth and the cursor style doesn't change.
3. The delay in changing the window size is very high.

Maybe it should call the x11 start moving window and start resizing api, instead of directly setting the window position and size?

This pr:

2024-10-21.09-45-46.mp4

My experimental project:

2024-10-21.09-46-40.mp4

My project code:

[Mickeon]

Many other descriptions in the PR would have to be adjusted as follows:

Suggested change

	Horizontal position offset of the maximize/restore decoration button, when [member extend_to_title] is true and the button is rendered by Godot.
	Horizontal position offset of the maximize/restore decoration button, when [member extend_to_title] is [code]true[/code] and the button is rendered by Godot.

[scgm0]

Perhaps the window dragging and resizing in this pr can be replaced using the api provided by these two pr's?
#100532
#100464

[scgm0]

This pr's minimize button differs from the native minimize button: you need to click the taskbar icon twice to redisplay the window after minimizing, and it won't keep the window maximized, which is a bug of directly setting the window mode to MODE_MINIMIZED.
My desktop environment is archlinux + kde6 + wayland.
https://github.com/user-attachments/assets/c16b5f4d-1a7a-4018-869e-2b08e70e078d

2024-12-20.02-14-28.mp4

[bruvzg]

Perhaps the window dragging and resizing in this pr can be replaced using the api provided by these two pr's?

At least for Linux it definitely better to do so, this will add Wayland support and is an improvement over manually moving window on X11. Windows code is OK as is, but can be replaced as well, for consistency.

[TheESN]

Though some Wayland environments (for example KDE) prefers to give titlebars themselves, so you need to give proper preference through xdg-decoration protocol (Also maybe make the default for server side titlebars for such environments if their such preference is detected)