| Summary: | Wayland: Windows have no border and title bar | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Felix Hädicke <felixhaedicke> |
| Component: | video | Assignee: | Ryan C. Gordon <icculus> |
| Status: | ASSIGNED --- | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | CC: | bugs, dos, eephei, eliashogstvedt, gabomdq, x414e54 |
| Version: | HG 2.1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Attachments: |
Simple app source code to reproduce the problem
Wayland Bordered/Window Decoration Fallback (DRAFT) Example when runing testshader xdg-decoration support |
||
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. 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. 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. (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. 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. 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? I've reported this on the KDE bug tracker as well: https://bugs.kde.org/show_bug.cgi?id=368389 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. 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. Created attachment 2604 [details]
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.
Created attachment 2605 [details]
Example when runing testshader
*** Bug 4122 has been marked as a duplicate of this bug. *** The old KDE protocol has now evolved into standardized xdg-decoration: https://github.com/wayland-project/wayland-protocols/tree/master/unstable/xdg-decoration (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. Created attachment 3445 [details]
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.
(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. > This looks great! I’ll apply this when I get home in a bit.
ping :)
(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. |
Created attachment 1856 [details] 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.