Wayland: Windows have no border and title bar

[SDLBugzilla]

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Simple app source code to reproduce the problem (hello_world.c, text/x-csrc, 2014-08-29 20:35:50 +0000, 792 bytes)
• Wayland Bordered/Window Decoration Fallback (DRAFT) (test_decorations.patch, text/plain, 2016-11-07 09:04:40 +0000, 30426 bytes)
• Example when runing testshader (testdecorations.png, image/png, 2016-11-07 09:05:21 +0000, 122319 bytes)
• xdg-decoration support (xdg-decoration.patch, text/plain, 2018-11-04 20:26:35 +0000, 13037 bytes)

Reported in version: HG 2.1
Reported for operating system, platform: Linux, All

Comments on the original bug report:

On 2014-08-29 20:35:50 +0000, Felix Hädicke wrote:

Created attachment 1856
Simple app source code to reproduce the problem

All my application windows have no border and title bar when running in Wayland. This is even reproducible with the simple attached app.

On 2014-09-10 16:30:00 +0000, Gabriel Jacobo wrote:

Weston does not provide server side decorations (borders, title bar and such). KWin will provide these, but in any case I don't think it falls within SDL's domain to provide them, it's either the compositor job or a third party library dedicated to client side decorations.

On 2015-04-08 07:57:28 +0000, wrote:

Apologies for re-opening this but the resolution is far from satisfactory.

Ignoring the debate for/against client side decorations. It is (currently) possible that some major Wayland compositors will not support server side decorations.

In this situation then it should either be up to SDL to provide the client side decorations or some way for the application developer to know if they need to implement their own window decorations.

On some level SDL is essentially providing the same basic functionality as GTK or QT. Both of these will provide the client side decorations based on user themes in certain situations.

Having the application developer implement their own decorations seems quite a large change to the current API and a huge show-stopper for moving already shipped software over to Wayland just by simply dropping in a new shared library. The simplest solution would be to use a custom universal SDL theme for window decorations.

On 2015-04-08 11:40:48 +0000, Gabriel Jacobo wrote:

This is the job of an entirely different library, if the day comes where Wayland becomes the dominating force in the market, then I guess we could consider it, but then again...if that happens there's going to be much better alternatives than what we could provide.

On 2015-04-08 13:33:53 +0000, wrote:

(In reply to Gabriel Jacobo from comment # 3)

This is the job of an entirely different library, if the day comes where
Wayland becomes the dominating force in the market, then I guess we could
consider it, but then again...if that happens there's going to be much
better alternatives than what we could provide..

If you are saying it is the job of a different library this library would also need to receive input events to process the hit tests in the decoration area. It would either have to use SDL internally or can create its own wayland surfaces and then pass them to SDL using SDL_CreateWindowFrom. This would be very complex to implement, not cross-platform and you would begin to loose the benefit of using SDL.

SDL has a certain API contract that it has to guarantee in a cross-platform way i.e. when SDL_WINDOW_BORDERLESS is not specified and the window is not fullscreen there should be window decorations if the WM expects them.

Otherwise this will lead to a situation where software is tested on one WM/Compositor that uses server side decorations and then will not work correctly on another.

SDL should currently implement a fallback decoration (disable-able with an environment variable), to at least allow current Weston and GNOME Shell users to move/close the window.

Possibly in future it should have its own theming config files stored in ~/.config/sdl-theme that the distribution can provide. Or dlopen whatever theming library you discussed.

On 2015-04-08 14:19:25 +0000, wrote:

TLDR - Window Decorations would have to be done using wl_subsurface and need events. This would all have to be done in SDL_waylandwindow.c so a third party library would not work.

On 2016-09-07 10:50:15 +0000, wrote:

This is happening to me as well using the kde plasma desktop under wayland. As stated before I'm simply expecting there to be window decoration when I create a window without SDL_WINDOW_BORDERLESS.

If this is really up to some other library, where do I start? Is this an issue that needs to be reported to QT or KDE?

On 2016-09-07 12:18:58 +0000, wrote:

I've reported this on the KDE bug tracker as well: https://bugs.kde.org/show_bug.cgi?id=368389

On 2016-09-08 20:03:56 +0000, wrote:

A statement from Martin Gräßlin (KWin maintainer) was made:

Wayland uses client-side decorations by default. Of course there are no decorations, that's the (stupid) idea of client-side decorations. KWin has an additional interface to negotiate window decorations, so that KWin can add window decorations.

So SDL could implement this so that it can get decorations, the protocol is described at: https://quickgit.kde.org/?p=kwayland.git&a=blob&h=8bc106c7c42a40f71dad9a884824a7a9899e7b2f&hb=29d6bbd92a20ced2c1a3301f5df9e605999cf894&f=src%2Fclient%2Fprotocols%2Fserver-decoration.xml

And KWayland also has an implementation for it.

If SDL does not like the (stupid) default behavior of client-side-decoration I highly recommend them to "complain" on the Wayland developer mailing list. They will have mine and Qt developer's fully support.

On 2016-11-03 05:13:44 +0000, wrote:

Unfortunately I do not think we will get anywhere by complaining about it, they've made their decision. We just have to deal with it.

Its not just the decorations that cause an issue if its done client side, everything like widgets, scrollbars, etc. are all effected. IMHO I do believe everything should be created server side via views/surfaces and a widget protocol similar to Windows and macOS. Then its up to the compositor to theme all applications exactly the same however it chooses. You then do not limit your windows to be flat 2D objects and can be easily adapted into VR (Vive) or AR (Hololens) without having to redesign the entire compositor protocol every-time.

Anyway If I get time this month I will see if I can implement a fallback and submit a patch.

On 2016-11-07 09:04:40 +0000, wrote:

Created attachment 2604
Wayland Bordered/Window Decoration Fallback (DRAFT)

I have created a test/draft patch for implementing a fallback window decoration. This allows you to drag the window around by the titlebar, and also close the window via a button in the top right. It would also allow a third party library to be loaded, all the library has todo is write the image to shared memory buffer or to an SDL_Surface.

The only issue I can see is that the titlebar text is going to be difficult to implement as a fallback directly in SDL.

This is just a test so please do not use it as it needs a bit of re-factoring. I will try to improve on this as soon as I get more time.

It would also be pretty simple to add the k-win specific interface but not sure how many window managers will support that interface and we could potentially end up with 20 different interfaces just to support server side decorations.

On 2016-11-07 09:05:21 +0000, wrote:

Created attachment 2605
Example when runing testshader

On 2018-04-21 19:49:35 +0000, wrote:

*** Bug 4122 has been marked as a duplicate of this bug. ***

On 2018-10-27 20:43:21 +0000, Sebastian Krzyszkowiak wrote:

The old KDE protocol has now evolved into standardized xdg-decoration: https://github.com/wayland-project/wayland-protocols/tree/master/unstable/xdg-decoration

On 2018-10-28 19:32:43 +0000, Ryan C. Gordon wrote:

(In reply to Sebastian Krzyszkowiak from comment # 13)

The old KDE protocol has now evolved into standardized xdg-decoration:
https://github.com/wayland-project/wayland-protocols/tree/master/unstable/
xdg-decoration

Yes! I've been waiting on this. :)

--ryan.

On 2018-11-04 20:26:35 +0000, Sebastian Krzyszkowiak wrote:

Created attachment 3445
xdg-decoration support

I'm attaching a patch to use xdg-decoration alongside the old KDE SSD protocol, which is already being phased out by compositors. Tested with rootston.

On 2018-11-04 21:04:06 +0000, Ryan C. Gordon wrote:

(In reply to Sebastian Krzyszkowiak from comment # 15)

Created attachment 3445 [details]
xdg-decoration support

This looks great! I’ll apply this when I get home in a bit.

Thanks!

--ryan.

On 2018-11-21 17:45:27 +0000, Sebastian Krzyszkowiak wrote:

This looks great! I’ll apply this when I get home in a bit.

ping :)

On 2018-11-21 23:46:49 +0000, Ryan C. Gordon wrote:

(In reply to Sebastian Krzyszkowiak from comment # 17)

This looks great! I’ll apply this when I get home in a bit.

ping :)

It took me awhile to get home! :P

This patch is now https://hg.libsdl.org/SDL/rev/779d711b6b5e, thanks!

I'm leaving this bug open until we have a simple fallback for client-side decorations, but my hope is that xdg-decoration is the way forward for most people, eventually.

--ryan.

[flibitijibibo]

Resolved by #4068's merge