wayland uses non-native decorations and can't be resized or moved [arch+gnome]

[mitchmindtree]

The following is an image of a program I'm working on that uses winit with the wayland backend (via glutin via glium via conrod):

The window decorations are thin gray bars rather than the native gnome decorations that look like this:

Does anyone know why this might be? @vberger any ideas on what's happening or where I could look to fix it? Any advice appreciated :)

[mitchmindtree]

FWIW when running "gnome with xorg" the window decorations look normal, however I also run into other issues with HiDPI and would prefer to get wayland working nicely anyway.

[elinorbgr]

Well, on wayland (especially gnome), decorations are drawn client side. As such, the decorations are currently handled for winit by my wayland-window crate.

For now, this crate only draws basic grey decorations, because I haven't yet done the work to make them prettier and include buttons to close/minimize, etc... But there is no simple way to make them look native. This would require either:

• manually parsing the GTK configuration and reproduce the behavior of the GTK engine (this is kind of a lot of work, and similar work would need to be done for Qt for KDE environments).
• using GTK to open the window (which kind of defeats the the purpose of winit).

However, resizing the window (by clicking and dragging the border) and moving it (by clicking and dragging the large top decoration) should work. If not, it is either a bug of wayland-window or of gnome.

[real-felix]

I understand the fact that there is no decoration due to wayland policy of client decoration, but what about the resizing?

Also, when I use piston_window with SDL2 backend, the window has the GTK decoration. Do you mean that the libsdl is using the GTK lib to draw those decorations?

[elinorbgr]

Just to clarify, by "no decoration" do you mean that the window is completely borderless, or are there just grey borders with no buttons, as in the first screenshot of this issue?

The resizing problem has been diagnosed as a bug in mutter : https://bugzilla.gnome.org/show_bug.cgi?id=781811

Regarding SDL, if I believe this discussion https://bugzilla.libsdl.org/show_bug.cgi?id=2710 it looks like SDL makes no attempt to draw any border. So maybe mutter recognises SDL windows and decorates them itself? Or maybe your version of libSDL2 does not have wayland support and uses XWayland, in this case mutter will decorate it in all cases.

A simple way to test this last hypothesis would be to run your program using SLD2 with the environment variable WAYLAND_DEBUG=1 set. If nothing is printed in the console, it's likely you aren't using wayland.

[real-felix]

There are grey borders as in the screenshot, no problem.

Indeed, you were right about SDL : with the Wayland debug, there is no output. The libsdl2 provided by the Debian repository uses XWayland as you thought.

The lack of window decorations makes this crate not really useful under wayland, IMO. Maybe a solution exists to ask the decoration to the desktop… but I have no idea about the way Wayland works.

[mitchmindtree]

I think it would be worth making it an explicit goal of winit to get native decorations working with wayland, even if it didn't have the highest priority.

I realise this is not a part of wayland's policy, however winit's aim is to provide a portable native window API across platforms - users will naturally be disappointed if they can get native windows on macos, windows and x11 but not on wayland.

I agree it'd probably take a lot of effort. At least if we maintain that this is something winit would like to have, a potential contributor may be more willing to come along and champion it, knowing that their contribution would be very welcome :)

That said, I wonder if this is even possible with winit which does not have access to any graphics context (OpenGL or otherwise). I guess they could be drawn using software rendering? Is this how decorations are normally drawn? 🤔

[elinorbgr]

Regarding the decorations under wayland, If the goal is to have functional decorations, even if they do not match the look&feel of the desktop environment, this is just a question of implementing the missing parts in wayland-window (aka, the close/maximize/minimize buttons and the name in the titlebar, I think?). And it's certainly possible to adapt wayland-window to make the borders more pretty than these plain grey rectangle.

If the goal is to match the look&feel of the desktop environment, this is going to be much more difficult: there is no unified look&feel in linux, and even less with wayland where clients are supposed to draw their own decorations. Already GTK and Qt try to each provide the tools to mimic the styling of the other, with more or less success. So I see two possible alternatives:

• "Simply" use GTK/Qt/etc... to create the window instead of using wayland-window
• Try to find and parse any available GTK/Qt configuration to manually mimic it

The first choice add some large dependency to winit (GTK or Qt or...), the second seems plainly unrealisable to me.

[remcokranenburg]

KWin supposedly provides an API to make it draw window decorations for the application: https://blog.martin-graesslin.com/blog/2015/12/server-side-decorations-coming-to-kwinwayland/

Gräßlin planned to add something to the Wayland protocol so that it can be supported by other window managers besides KWin, but I don't know what happened with that plan.

[newpavlov]

While working with vulkano it seems I've encountered this problem. (see link to vulkano issue earlier)

On Debian 9 with Wayland and Gnome everything worked fine (i.e. with native controls), but after installation of libwayland-dev (which is in the libgtk-3-dev dependency tree) I've got the same gray window decorations as in the OP, also window could not be resized or moved. Also full-screen application got affected too, after launching app part of the rendered image appears, but nothing else.

[elinorbgr]

If you had native controls prior to installation of libwayland-dev, it means that winit was actually connection to Gnome as an X11 client, using the compatibility layer. Installing libwayland-dev made it possible to use the wayland backend so it used it.

The gray decorations are what winit currently draws, as there is no "native decorations". Improving them is tracked by Smithay/wayland-window#19 and Smithay/wayland-window#4.

The move/resize issues have been tracked to a bug in mutter, see https://bugzilla.gnome.org/show_bug.cgi?id=781811. I don't know how long it will take for the bugfix to reach your repos.

Could you open a new issue for the fullscreen problem, possibly with a minimal reproducing example? It seems to me like it's probably an other issue, not clearly related to the decorations.

[newpavlov]

Is it possible to add ability to enforce use of compatibility layer, perhaps through feature gate in the winit?

I'll try to write a minimal example for fullscreen issue next week.

[elinorbgr]

If I'm not confusing things, starting with version 0.7.1 of winit you can set the environment variable WINIT_UNIX_BACKEND=x11 to force the use of the X11 backend of the wayland one (and thus use the compatibility layer).

[elinorbgr]

Closing in favor of #306