Our own backend for Wayland

[kekekeks]

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

[martindecker]

Does "Our own backends for X11/Wayland " mean , you plan to write (more) code to interact with X11 ? I think, because Wayland is the future, it is not necessary to support X11 anymore. Keep it simple and only support Wayland. But I am not expert regarding this question, currently I am a WPF developer.

[kekekeks]

Wayland haven't yet reached the feature parity with X11 and judging from their mailing list will never do so, because some features aren't implemented on purpose. X11 will also be more widespread for a half a decade, at least.

[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

[kekekeks]

According to https://lists.freedesktop.org/archives/wayland-devel/2017-September/034967.html wayland doesn't support dpi awareness. Great.

[jkoritzinsky]

It looks like there's support on the Wayland side (and in Weston) as of 1.2, but there isn't support in the XWayland front end.

https://github.com/wayland-project/weston/blob/1a2adfedea74ae264eca7d4b8cbe6d1f04e552bf/man/weston.ini.man#L415

[kekekeks]

Yep, wl_surface::set_buffer_scale seems to be the way for per-window scaling factors

[iMonZ]

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

So xcb doesn't work on modern systems.
Maybe dropping gtk2 support would help with the problems.
But full Wayland support without X11 or XWayland or xcb should be on the roadmap.
Ubuntu LTS will switch to Wayland in 22.04 and most other popular distros already switched to Wayland.
And most feature aren't implemented in Wayland for security reason, so yes it's on purpose.

It would be great if the support in AvaloniaUI would be there until Ubuntu will switch in the LTS