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 https://github.com/AvaloniaUI/Avalonia/pull/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

[jindongjie]

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.

[amayra]

so Wayland support is officially dead ?

thanks gnome devs

[maxkatz6]

so Wayland support is officially dead ?

It's not.

[jindongjie]

so Wayland support is officially dead ?

It's not. So，in future we can use wayland backend without manually install nuget pkg？

[Haltroy]

Can't we just fallback to X11 (XWayland in this case) in GNOME and use Wayland on others that do support what we need? This way, we can still have a partial support on Wayland until we figure out something for GNOME. — A ~KDE Plasma Wayland Session~ Hyprland (yes I am one of those people now) User

[maxkatz6]

So，in future we can use wayland backend without manually install nuget pkg？

That's the plan. We are not working on wayland support right now, but we didn't give up on the idea to support it for 11.x or 12.0 release.

@Haltroy I would ping @kekekeks or @jmacato to answer that.

[TheArcaneBrony]

Would be nice if Wayland support was prioritised, especially given I no longer have a way to reach out for support when things don't work with xwayland.

[jgcodes2020]

Given that CSD is the primary blocker for Wayland support, is there a tracker issue or potential API design work that has been done for it?

[kekekeks]

The plan is to keep CSD completely hidden from the user code and implement them as a combination of platform backend code and our compositor internals. It would be either a fake TopLevel that renders to the main wl_surface with client area being rendered into wl_subsurface, or some way to overlay multiple TopLevel's into the same composition target instance.

[Haltroy]

Wait I'm confused.

CSD ("client-side decorations ") is what GNOME uses which render the title bar (Avalonia's "ExtendClientAreaChromeHints"). SSD (server-side decorations") is what KDE/Qt uses which lets the compositor to draw the title bar. Source So the CSD stuff should be already implemented (since it's a GNOME thing and usually GNOME's things are applied to everyone but not vice-versa which is the case of my comment). The thing that you should use for drawing "ExtendClientAreaChromeHints" should be CSD (in my opinion), correct me if I'm wrong. If we don't want to extend to titlebar we don't set this value to anything and use the default which is the case where you would use SSD.

How about this: use CSD completely. Make a default titlebar for Avalonia windows for normal title bar and hide it if this setting is set to a different value. This way you don't have to wait GNOME another millennium to implement SSD to Mutter.

I have no idea how this works or might get it wrong so if I do please correct me. Also is there anything that's blocking Wayland support for Avalonia?

[kekekeks]

is what GNOME uses which render the title bar

GNOME does not draw the titlebar, GNOME forces wayland applications to draw their own titlebars. That's not the case for Windows, macOS, X11 and most of Wayland compositors.

Avalonia doesn't currently provide its own titlebar and attempting to put one into Window template will break app expectations of full ClientSize being available to them.

Implementing CSD in a way that's consistent with app expectations on other platforms is doable, but requires work that's currently not planned for the next months.

[Haltroy]

is what GNOME uses which render the title bar

GNOME does not draw the titlebar, GNOME forces wayland applications to draw their own titlebars. That's not the case for Windows, macOS, X11 and most of Wayland compositors.

That's what I meant. Sorry for confusion.

Avalonia doesn't currently provide its own titlebar and attempting to put one into Window template will break app expectations of full ClientSize being available to them.

Implementing CSD in a way that's consistent with app expectations on other platforms is doable, but requires work that's currently not planned for the next months.

No just implement that on Linux Wayland. Or even better, just show it on GNOME Wayland (detect Mutter, detect that it's on Wayland and show a simple title bar). If the window has that ExtendToChromeSomethingSomething then just don't show that title bar. On anything else use SSD and let KWin etc. to draw the tite bar for you.

I mean it's not a clean solution but everyone knows that GNOME won't add SSD support to Mutter in the future and waiting on that promise will halt Avalonia's Wayland support.

You already can make a custom title bar on Avalonia that has the same functions as a normal one. And not just that you also can create window borders that works. I'll make a template for that in the future if anyone wants to use it (and for myself).

[TheArcaneBrony]

Couldn't Avalonia report a smaller ClientSize when drawing a title bar?

[kekekeks]

Couldn't Avalonia report a smaller ClientSize when drawing a title bar?

That would mean implementing titlebar in some horrible way instead of just defining it as a normal templated control. Would also still require wl_subsurface for actual content.

There are no hard blockers, just no resources are currently allocated for wayland support.

[kekekeks]

I could perhaps have worked on it in my spare time, but it would require enthusiasm and it's hard to have enthusiasm for a tech that still cant run my primary desktop session in 2024 because of various questionable design decisions.

[amayra]

I could perhaps have worked on it in my spare time, but it would require enthusiasm and it's hard to have enthusiasm for a tech that still cant run my primary desktop session in 2024 because of various questionable design decisions.

just ignore Gnome

they always sabotage any new wayland protocols. Just keep it as drafts for more than 4 years

just like how game developers ignore mac OS

[amayra]

Would be nice if Wayland support was prioritised, especially given I no longer have a way to reach out for support when things don't work with xwayland.

ryujinx user ?

[TheArcaneBrony]

something ryujinx? i dont, no.