Avalonia
Avalonia copied to clipboard
Wayland backend
What does the pull request do?
Add a Wayland backend for Linux.
There hasn't been any activity on the previous PR, which is why I'm opening one on my own.
At the moment, you have to manually generate the Wayland bindings because I haven't figured out how to do so on build:
cd ./src/Linux/NWayland/src/NWayland.Scanner && dotnet run
This PR is still WIP, help is greatly appreciated.
What currently works:
- [x] Windowing:
- [x] Window creation
- [x] Window modes: Normal, Maximized, Fullscreen
- [x] Resizing
- [x] Popups
- [x] File Dialogs (native + managed fallback)
- [x] Tray icons
- [x] Client Side Decorations
- [ ] Keyboard:
- [x] Basic input
- [x] Key repetition
- [ ] ITextInputMethodImpl with zwp_text_input_v3
- [x] Mouse:
- [x] Basic handling
- [x] Scrolling
- [x] Theme cursors
- [x] Custom cursors
- [x] Animated cursors
- [ ] Touch:
- [ ] Basic handling (postponed, I do not have a touch device at hand)
- [x] Data sharing:
- [x] Clipboard:
- [x] Reading
- [x] Writing
- [x] DND
- [x] Clipboard:
- [x] Rendering:
- [x] Backends:
- [x] EGL
- [x] FrameBuffer
- [x] Modes:
- [x] Deferred
- [x] Immediate
- [x] Composition
- [x] Backends:
What is the current behavior?
Currently, XWayland is used in order to run Avalonia apps on Wayland systems.
What is the updated/expected behavior with this PR?
Use Wayland instead of X11 on compatible systems.
Checklist
- [ ] Added unit tests (if possible)?
- [ ] Added XML documentation to any related classes?
- [ ] Consider submitting a PR to https://github.com/AvaloniaUI/Documentation with user documentation
Breaking changes
Some projects where moved to the Linux solution.
Obsoletions / Deprecations
None
Fixed issues
Fixes #1243 Fixes #2338 (?)
If Wayland bindings are stable, I'll publish a packaged version on nuget
@affederaffe I believe we already have rudimentary CSD that are used for Win32 backend. Resize-grips are missing but other than that they are more or less usable even with X11.
Ah, you were already trying to enable them, nvm
Neither resize nor move seem to be currently implemented and the X11 backend doesn't support CSD either, so I thought I'd disable them for now.
@kekekeks Any plans on releasing NWayland on NuGet?
@jmacato you need to use a desktop environment that supports server decorations. Basically not GNOME.
@affederaffe im still getting the same error in gnome on the latest commit:
Yes, your desktop environment needs to support Server Side Decorations. Please, check with desktop environment that supports zxdg_decoration_manager_v1
Decorations seem to work on Gnome now, though I noticed that popups and drag&drop are completely broken on it, even though they work perfectly fine on KDE.
This is wild :D but it seems like that we need a way to add CSD on windows that didnt specify it. I know GNOME is a bit thickheaded but it's a major DE that we cannot ignore.
@affederaffe this is so amazing :D i can do DnD on linux now :D thanks so much for this effort!
btw, some more bug reports if you dont mind:
Some windows still doesnt have CSD for some reason, like the DevTools window for example
@affederaffe @kekekeks im curious, is it possible to make a RenderTimer that is synchronized to the Compositor's refresh rate?
You can ask the compositor to send you a callback when it thinks that's a good idea to start rendering a new frame for a particular wl_surface. However for that to work each window would have its own render timer. While being possible to refactor our rendering to use multiple render timers, I'm afraid the UI thread animations like their global variables a bit too much, so we can't do that.
@kekekeks by global variables you mean the inherited Clocks?
Yes, UI thread animations expect to have some global clock to function.
@kekekeks that can be refactored yes, inherently we only need a way to hand over some kind of timer to the clocks. each window/surface can have one timer each and it should work fine
each window/surface can have one timer each and it should work fine
Animations can tick on brushes in resource dictionaries that are shared by multiple windows.
You might want to look into libdecor for handling SSD-less compositors (basically just Mutter from GNOME).
Last time I've checked libdecoration required glib and wasn't really thread safe, which is important because Avalonia does event handling/layout and rendering on different threads.
@kekekeks i like having our own CSD implementation better tbh. That way users can modify it so without much fuss.
@jmacato You need to add
<ItemGroup Label="InternalsVisibleTo"> <InternalsVisibleTo Include="NWayland.Protocols.Plasma, PublicKey=$(AvaloniaPublicKey)" /> <InternalsVisibleTo Include="NWayland.Protocols.Wlr, PublicKey=$(AvaloniaPublicKey)" /> </ItemGroup>
for the time being, that'll be fixed once the bindings are published on NuGet.
@affederaffe im getting this error now as well, fixed the public sigs though with your comment
@jmacato Update the NWayland submodule and regenerate the bindings
I opened a PR with my fixes for NWayland here.
- Should Copy/Paste decode entered unicode codes? As far as I know hard-coded charachters are decoded correctly and only those entered by the user are escaped, just like with X11.
- The framerate can easily be unlocked once there's a solution for brushes ticking in ResourceDictionaries as discussed above.
- This seems to be an issue with shared contexts with the EGL backend and doesn't work on X11 either. I can try to fix this, though I have no knowledge on this so I'd appreciate a little help.
@affederaffe im waiting for @kekekeks to review your PR on NWayland's repo. After he publishes the nuget we can get this PR merged :)
@affederaffe Seems like the FPS overlay is not displaying correctly on Gnome?
I'm also noticing some issues with mouse clicks being lost somehow, happens when i open DevTools as well
I just tried this on Arch Linux KDE, and found issues related to maximising. The window would only maximise to a small portion of the actual screen size, and would become even smaller when any other window was focused
I also needed to remove the InternalsVisibleTo lines in the NWayland project file or no apps would build.
Very nice work though, other than that everything was working well as far as I saw!
Hope there is discussion with the core team on this and a plan for merging. Really should have been merged in before the RC in my opinion (so by preview 5). It needs a chance for good testing before release.
Hey @affederaffe ,
I want to reach out for you as 11.0 is going to be closer and this PR is a really huge PR. We really appreciate your efforts and it is on our todo-list to get it merged. But most likely it will not be included in 11.0, as 11.0 has already a lot of new stuff inside. We plan to add this feature in a 11.x release after the major 11.0 bugs are ironed out.
I hope for your understanding 💐
Happy coding
Tim
I completely understand, also there are still some bugs left I haven't had the time to fix yet and probably won't in the near future, so it's definitely for the better. Still, I plan to work on this PR eventually, it is not abandoned.