probonopd / wayland-x11-compat-protocols

The missing Wayland protocols for features that are available in X11 (but are denied by the official Wayland protocols)
117 stars 3 forks source link

Popularize already existing sane protocols? #17

Open ilya-fedin opened 10 months ago

ilya-fedin commented 10 months ago

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.

ilya-fedin commented 10 months ago

Ah, found the mir-shell, it's still not merged: https://github.com/MirServer/mir/pull/3166

probonopd commented 10 months ago

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"?

ilya-fedin commented 10 months ago

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.

ilya-fedin commented 10 months ago

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

ilya-fedin commented 10 months ago

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.

probonopd commented 10 months ago

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

probonopd commented 10 months ago

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.

ilya-fedin commented 10 months ago

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.

ilya-fedin commented 10 months ago

And, well, I got a lot of crashes with QtWaylandCompositor's EGL support

probonopd commented 10 months ago

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?

ilya-fedin commented 10 months ago

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

myownfriend commented 10 months ago

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.

probonopd commented 10 months ago

Wayfire, remove all Gtk/Gdk-like dependencies

I was referring to Cairo, Pango and PangoCairo. This is the GTK rendering stack. (Pango depends on GLib which is GTK.)

ilya-fedin commented 10 months ago

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.

RAOF commented 10 months ago

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.

ilya-fedin commented 1 month ago

Another similar repo: https://github.com/misyltoad/frog-protocols