There are no window decorations on Wayland

[paveloom]

Changed right after you introduced the Wayland backend. Seems like this autogenerated decoration doesn't work:

[wolfpld]

Hi, there's a tl;dr in release notes:

Please don't ask about window decorations on Gnome. Current behavior is the intended behavior. Gnome does not want windows to have decorations, and Tracy respects this choice. If you find this problematic, use a desktop environment that actually listens to its users.

For more context, the Wayland protocol (first released in 2008, 14 years ago) does not say anything about window decorations. This is a sound decision, as, unlike say X11, Wayland was designed not only with PC desktops in mind. Wayland use cases include things like car displays or mobile phones. In such cases, window decorations would only get in the way, as these environments typically have their unique way of managing displayed applications. For example, in a car, you may be able to switch from a radio to map navigation (both full-screen applications) only with a physical button on the steering wheel.

On the PC desktop side, things are no less complicated. You may use a tiling window manager, where applications are displayed not as classical windows that you can freely position and resize but as non-overlapping tiles automatically managed by the window manager. In such an environment, with no ability to perform window movement or resizing, it may make little sense to display any decorations.

Of course, the traditional PC desktop still exists and is strong as ever. People working in such environments expect windows to have decorations, expect them to be consistent across all applications, and expect common functionality to be provided by the window manager. For example, you may want to pin a window to all virtual desktops, draw drop-shadows to make windows more easily distinguishable, or you may want windows to be sticky to each other. This last feature was very prominent in Winamp, which enabled precise alignment of the application windows without the need to be pixel-perfect with window movement. You will surely agree that the best way to provide a unified solution for window decorations and behavior is to implement them in the window manager (or server-side, as it's called.) Otherwise it's the application's responsibility to implement all the behaviors you could possibly expect.

winamp.mp4

Unfortunately, not everyone has enough common sense to see this should be the way. To the ire of many, Gnome developers insist that the only way to decorate windows is by applications themselves (i.e., client-side). This has profound consequences for all application developers. First, you need to somehow detect if you should provide decorations (as you may be running with a tiling window manager). Then, you need to somehow draw window decorations that will at least try being consistent with the rest of the desktop. This is impossible to do, and the end result is a shit show, not only of clashing visual styles but also basic window management functionality provided by each application. To make things clear, the screenshot below shows how the Gnome developers intend your desktop to look (Tracy is running with Wayland-enabled GLFW here). This is not an exaggeration.

Of course, you're not first to notice this problem. Many users have requested server-side decorations in Gnome, and this is Gnome's non-explanation for not doing this: https://gitlab.gnome.org/GNOME/mutter/-/issues/217. Notice that they concentrate on proving the point that client-side decorations are required by Wayland. This is false. As mentioned earlier, the Wayland protocol says no word about decorating windows. This topic only appears in the xdg-decorations protocol extension (the file you have referenced), which Gnome does not implement. Hence, any wording in this extension does not apply to Gnome.

As you can see in the bug report, there is no reasoning with these people. It's their way or the highway, which is just sad. So I have chosen to interpret the protocol in my own way, because I can, just as they do. And my interpretation is that applications should expect to be decorated by the window manager. If Gnome does not want to do that, it's fine by me. If they want my program to look like shit in their desktop environment, that's their decision. One could say that it's purely political, to push users to only use Gnome applications. Please show your appreciation directly to Gnome developers (if you don't value your time) or switch to a better environment. KDE is a much more usable alternative that works as expected and does not constantly try to alienate its users.

Alternatively, you may build the profiler with LEGACY=1 make flag, which will revert to using the GLFW library, as before. Gnome decorates applications running on X11, but you lose high-precision touchpad scrolling input that is only available with Wayland.

I'm sorry this is not the answer you have expected, but things are how they are.

[paveloom]

Thanks for the write up! I actually did expect something like this, just wasn't sure whether it was an intentional change to stop supporting CSD. GLFW provided a solid color border with no buttons as a fallback (I mean, it's atrocious, no doubt, but at least I could resize the window). I did see the LEGACY flag in the Makefile and will make a use of it.

[wolfpld]

I think you can still move the window with Super + LMB and resize with Super + RMB.

[paveloom]

Oh, yeah, you're right.

On a side note, I found out that there is a small library called libdecor which allegedly provides native CSD if required, otherwise falling back to SSD. Seems like some folks using GLFW anticipate this, and the library itself has the origin there.

[wolfpld]

I am aware, but I don't like this approach. Using libdecor is basically saying it's ok to enforce broken policies on the whole open source community.

[AnErrupTion]

I love this. I absolutely love it. The dedication needed to write such a comment is incredible. Respect.