Our own backends for X11/Wayland

There are way too many limitations and tradeoffs that GTK/GDK have to support both of them, while not allowing us to do things that we want to do. Notable examples are separate-thread rendering (we have to use our own X11 connection to do that) and issues with absolute window positioning on Wayland (Wayland has xdg_surface_set_window_geometry which isn’t used by GTK for some reason which leads to our popups being broken, we are forcing GTK to use X11 backend because of that).

There are some major caveats on that way:

1. System dialogs (open/save file, folder selection, etc). We need to either still load GTK or have them out-of-proc somehow. The out-of-proc way will cause issues with making dialogs modal to the parent window on X11
2. Input methods. Right now we are relying on GTK do support them
3. Client-side window decorations. Some of the wayland shells are requiring applications to draw window frame, title and buttons, we need to support that somehow

[timunie]

Wayland is planned afaik and the preparation work where we need breaking changes is already in progress. In the 11.x time frame we hope to be able to add wayland support. @affederaffe already did a great job on this backend.

[kekekeks]

Shower thought: GTK is not, in fact, a “native” UI toolkit for Linux. Some popular distros are using KDE and Qt. So our dependency on GTK isn’t free. Our file dialogs also don’t look native everywhere.

So we should use libX11/libxcb for UI and separate backend system for file dialogs, that should support:

• GTK2/3
• Qt 3/4/5
• our own managed implementation that doesn’t depend on anything