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

[jgcodes2020]

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

File dialogs can be handled via desktop portals: https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.FileChooser

[maxkatz6]

@jgcodes2020 yes, and it was #8217

[microhobby]

Hey, my dear Avalonia maintainers, let me say that this is important. Some users that are using Avalonia for embedded system does feel more comfortable having a desktop environment than using framebuffer or DRM. So, for embedded some machines does not support X11 anymore, only Wayland and Weston. "XWayland can still be used" may some argue. Yeah, but in some scenarios Xwayland is not supported and also is hard to set openGL ES for Xwayland, so, no HW acceleration for this users...

[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.

[iMonZ]

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.

Hey
any news on that?

[ratin3]

Gentlemen, I am working with Zynq / embedded os like Petalinux, was wondering what components I will need to support Avalonia UI and .Net framework that Avalonia is based on. I would like to avoid Xorg if possible. Thanks

[LoongArum]

Gentlemen, I am working with Zynq / embedded os like Petalinux, was wondering what components I will need to support Avalonia UI and .Net framework that Avalonia is based on. I would like to avoid Xorg if possible. Thanks先生们，我正在使用 Zynq / 嵌入式操作系统，例如 Petalinux，我想知道我需要哪些组件来支持 Avalonia 所基于的 Avalonia UI 和 .Net 框架。如果可能的话，我想避免Xorg。谢谢

Just use LinuxFrameBuffer, ther are tutorial in avalonia document.