Open ilya-fedin opened 10 months ago
Ah, found the mir-shell, it's still not merged: https://github.com/MirServer/mir/pull/3166
Interesting, @ilya-fedin. Indeed we should help to promote already existing sane protocols if they can work across various window managers and desktop environments.
Do you know which Wayland compositors currently implement qt-shell protocol (besides KWin)?
What is a "plasma_surface"? Can we think if it like a "KDE window"?
Do you know which Wayland compositors currently implement qt-shell protocol (besides KWin)?
I don't know of any popular compositor but any compositor using the QtWaylandCompositor library (kwin doesn't use it and doesn't implement qt-shell) can implement it in less than 10 lines: https://doc.qt.io/qt-6/qml-qtwayland-compositor-qtshell-qtshell.html
What is a "plasma_surface"? Can we think if it like a "KDE window"?
plasma_surface is a plasma-shell's primitive, just like xdg_surface in xdg-shell. The only legal user is the plasma-shell binary as I already mentioned but it's not the only user overall since at least I used it in a non-KDE Qt application. I'm not aware of more users.
The only non-embedded compositor (most users of the library are probably Qt's business clients doing proprietary embedded software) using QtWaylandCompositor library I'm aware of is maui-shell but I don't think it implements qt-shell
It's kind of funny that embedded developers have the sane APIs via qt-shell and mir-shell while the xdg-shell that is done exclusively for desktops lacks them.
That's interesting. For helloDesktop we may need a Wayland compositor at some point in time. Hopefully there will be a QtWaylandCompositor (and possibly wlroots, as this is the often-cited solution for cross-desktop compatibility?) based one for generic desktop usage with Qt Widgets based desktop environments (such as LXQt, etc.)
It's kind of funny that embedded developers have the sane APIs via qt-shell and mir-shell while the xdg-shell that is done exclusively for desktops lacks them.
It's because "xdg" has essentially become a moniker to force all desktops to work the same way as Gnome under the hood. The Flatpak people even think they are "xdg". Whenever I read "xdg" these days, I think "Red Hat", forcing the Gnome way of doing things on other unsuspecting desktop environments.
Hopefully there will be a QtWaylandCompositor (and possibly wlroots, as this is the often-cited solution for cross-desktop compatibility?) based one for generic desktop usage with Qt Widgets based desktop environments (such as LXQt, etc.)
From my experience with the QtWaylandCompositor library (in order to do window embedding on Wayland), I can say it's of low quality for desktop use-case. It has a lot of // TODO: Not implemented
in the code and the compositor made with the library kills gtk4 applications with protocol error while they work just fine with all the real compositors. Perhaps that's never encountered by the business clients given they're likely using Qt for both the compositor and the clients.
And, well, I got a lot of crashes with QtWaylandCompositor's EGL support
Uh, that's really bad. If I had to do anything (but make no mistake, I don't have the time for it), then I'd probably fork/write a wlroots based compositor like Wayfire, remove all Gtk/Gdk-like dependencies, and use Qt for all rendering. Or does such a thing already exist?
Well, kwin is a compositor written from scratch and uses Qt for rendering (apparently by first initializing libwayland-server, setting WAYLAND_DISPLAY and then instantiating a QGuiApplication instance). kwinft is a project that rewrites kwin to wlroots and so perhaps is what you want: wlroots + Qt client for rendering
Uh, that's really bad. If I had to do anything (but make no mistake, I don't have the time for it), then I'd probably fork/write a wlroots based compositor like Wayfire, remove all Gtk/Gdk-like dependencies, and use Qt for all rendering. Or does such a thing already exist?
As far as I can tell, Wayfire doesn't have a dependency on GTK/GDK. Even Mutter doesn't use GTK/GDK for rendering.
I wouldn't really suggest anyone to port from cairo/pango to Qt given how bad Qt's QPainter drawing quality is and how Qt's text engine bad at supporting various things like emojis, variable fonts and communicating fontconfig for user font settings/font fallbacks. Qt attempts to do everything but does all that poorly.
skia is a good alternative to cairo/pango, though.
In the “Wayland compositor, but with Qt's rendering” space there's also QtMir, which is a QPA that, to a first approximation, lets you write a compositor in QML (qtmir-demo-shell is the simplest example of that). It's got rough edges, and it's primarily developed for Lomiri, but it might be interesting for others.
Another similar repo: https://github.com/misyltoad/frog-protocols
People think that Wayland is only wayland-protocols and the restricted protocols provided by it but that's not true.
Qt: https://github.com/qt/qtwayland/blob/dev/src/extensions/qt-shell-unstable-v1.xml Plasma: https://invent.kde.org/libraries/plasma-wayland-protocols/-/blob/master/src/protocols/plasma-shell.xml I heard there's also mir-shell protocol invented by the Mir project but can't find it right now.
The qt-shell protocol mirrors the QWindow API and so has all the sane feature like setting window icons, being SSD by default and allows for global positioning. mir-shell should be similar. Both of them are developed for Qt's and Mir's automotive business clients, though. plasma-shell is the protocol used by the plasma-shell application (the desktop) and allows for global positioning as well. Personally I use the skip taskbar feature from it in conjunction with xdg_toplevel (actually it's a window made by Qt and I create a plasma_surface on it) but it's made to be standalone as far as I heard from KDE developers (not meant for 3rd party applications though but works without privileged authentication atm, which exists in KDE world, yes).
This could be helpful for small compositors that don't want to follow the GNOME/KDE course of action.