get rid of everything Xorg

I agree, all the apps I use run natively on Wayland, but I think there will always be some legacy X11 apps that won't get ported. So, I think I'll implement it, but it is definitely not a priority.

replace OpenGL with Vulkan

I think I can just add support for Vulkan. There is no need to get rid of GLES as it increases the range of supported devices.

not sure what is the state in smaller distros. Maybe it would be good to reach out to LinuxMint, lxqt and others to see what would it take for them to switch. If you could implement needed features easily…maybe they would switch.

I know that Linux Mint already has support for Wayland. I am not sure which library or base compositor they are using, but I am always willing to support anyone using Louvre. Right now, I want to focus on developing my own compositor, which I'll name Crystals.

RDP?

That's an important feature, which I'll add at some point.

Html? E.g. https://greenfield.app/

Looks very interesting! I wonder how it works, so I definitely will check it out.

consider moving to codeberg?

Why?

Another question came to my mind: how is video processing handled? There were some changes in Mutter and/or gtk4 so it would be efficient, any chance for louvre to have it?. E.g. https://www.phoronix.com/news/GNOME-46-Beta-Released

Currently, the only type of buffers that are directly scanned out are cursors. I want to add an API to allow the use of other types of buffers soon. It is a bit complicated because overlay planes are very hardware-dependent and limited, and they support a few specific formats/modifiers. So, you also need to negotiate that with the client and so on.

Louvre is less modular but handles a lot of tedious tasks behind the scenes, providing a simple API (the enjoyable/creative part I'd say) without sacrificing much flexibility. On the other hand, Wlroots is excellent and highly modular, which is good, but it also means it places all the responsibility on you. You must invest time to fully understand each protocol and implement many tedious tasks yourself, which naturally takes quite some time. Additionally, Louvre is multi-threaded, as seen in the benchmark results in the repository, resulting in higher and more stable FPS compared to single-threaded designs when rendering complex scenes.

Thank you :)

what about Vulkan instead GL? Should be more performant and use less battery. Especially if it is meant to also work on mobile.

Yes, I believe I could create a renderer using Vulkan without much difficulty. Initially, I chose GLES2 for compatibility reasons.

is Louvre drawing those window decorations?

Yes, only the decorations with macOS style.

there is some overlap with https://github.com/winft/theseus-ship - any idea for a collaboration there?

Well, that's a compositor (which uses COMO) and Louvre is a library, so sure, I could collaborate with COMO.

there seems to be a company behind, while I didn’t investigate, are there plans for further development that you would publish, is there a way to influence those plans (suggestions, donations, some other way)

Cuarzo Software is just a name I use to release my open source projects, it’s not a real company. Everyone is welcome to suggest ideas or contribute to the development of these projects, and I genuinely appreciate that.

any plans to make a shell around it?

If time allows me, of course.

it is mentioned that this is a library, but obviously there is a working compositor. Regardless if this is a technology demonstrator, would it be possible to publish a compositor with decent theming and a few distinct layer modes (classic windows with taskbar, windows 8 like, Mac, gnome, ubuntu). I guess many smaller Linux DEs would consider it then…

Absolutely, you're free to build a compositor however you like, whether it's in 2D, 3D, or any other style. Essentially, it's akin to creating a game, with window applications acting as textures.

how does it compare to kwin/mutter?

Those are compositors and Louvre is just a library, so I don't know how to compare them. As you noticed, the compositor in the video is just one of the examples I made with Louvre.

Not yet, I mean, XWayland rootful mode has always been supported. But in this mode, all X application windows are rendered within a single Wayland window, enabling functionalities such as running an entire X Desktop Environment within the compositor. However, what hasn't been implemented yet is the rootless mode. In rootless mode, each X window is treated as a separate Wayland window, enabling better integration with the compositor.

Do you mean Desktop Environment? If so, the screenshot is from one of the library's example compositors named louvre-views. You can find more details about it here.

Thank you for the advice :)

My apologies for any confusion. I have now updated the post. Thank you!

The idea of single, double, and triple buffering revolves around how many framebuffers we use for display rendering. Typically, we go with double buffering, displaying one framebuffer while rendering happens on the other. Swap them, and the cycle continues. The goal is to prevent screen tearing and glitches from popping up on the screen.

Thanks! While I may have nailed server-side decorations in that example, as you know, there is too much other stuff to take into account to make a DE actually functional. So, I respect a lot what KDE and GNOME do and the innovations they make. I actually want to create a macOS clone, hahaha. That is one of the reasons I started this project. I will soon continue working on a library for exposing global menus in Wayland/X11. Qt allows defining a custom platform plugin, enabling us to plug external systems for managing global menus. Sadly, I think GTK4 no longer supports that, so I believe an approach would be to display a standard menu with basic functions for apps that don't support it.

I completely agree. I invest time in implementing protocols within the library, allowing it to handle many tasks autonomously, thus relieving developers from manually wiring everything themselves—without compromising flexibility oc. Regarding "later shell," did you mean "layer shell"? Developers can certainly still implement protocols not included with Louvre on their own, but that's not quite the intended approach.

The dock is rendered directly by the compositor in one of the examples; it's not an external application as it ideally should be. It doesn't rely on any intricate protocols or systemd services to monitor the states of apps. I added it solely for demonstration purposes.

Yes (kinda), that is a screenshot of one of the example compositors I included called "louvre-views" which implements server side decorations for apps that support the XDG Decoration protocol.