ehopperdietzel

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

Thanks, maybe you could follow the tutorial if you are interested. And I wouldn't mind answering doubts; that actually would help me improve the docs ;)

I'm not sure if I explicitly mentioned that it's easier than wlroots, but I believe its design can considerably ease the learning curve for newcomers. While I've read about those projects, I haven't had the chance to try them myself. Although I'd be interested in contributing to their development, I don't intend to abandon Louvre. I find it beneficial that there are different alternatives, as each can bring unique and clever ideas to enhance various aspects, ultimately improving the overall design across the board.

That would be great! 😀

I actually already created a library for that called Heaven (https://github.com/CuarzoSoftware/Heaven), but I want to rewrite it to make it simpler and add backends for different IPC mechanisms (Unix domain sockets and D-Bus).

It allows apps to create as many menu bars as they want. The idea is that when one of its toplevel windows is activated, it can notify the “topbar app” to display a specific menu bar. The compositor also informs the “topbar app” about the currently active client. So, it has three APIs: one for apps, another for the “topbar app,” and another for the compositor. Apps are identified by their PID.

Now, with respect to the second question, a long time ago, I tried to create a compositor using QtWayland, which had the most documentation at that time. However, it had some problems with certain interfaces that made the compositor crash. So, I then looked for wlroots but could find no documentation whatsoever, so I decided to start from scratch. As time passed, I began to learn and understand how protocols work, realizing that one of the most challenging things was implementing protocols correctly, as there are too many interfaces that depend on each other, and you need to implement them all before you can see results and validate that it works. That’s why I decided to create this lib, even as my university thesis, with the focus of offering a default and basic implementation of each protocol so that developers can see a functional compositor from the start and then gradually and specifically override whatever they need, being able to validate each feature they add immediately. Of course, there are many other complicated things I had to learn, such as the DRM/KMS API, buffer sharing through DMA, among other stuff. I really appreciate wlroots, though. I learned a lot by analyzing its source code, and surely today I would be able to create a compositor with it, hahaha.

Interesting, I don't recall where I read about Vulkan support still being experimental in many Mesa drivers; it might have been an outdated post. I'll look into it, and perhaps I'll decide to dive into learning Vulkan. Additionally, there are buffer-sharing mechanisms that already work smoothly with GLES, so I need to explore if the situation is similar for Vulkan. Thanks for your response, and if you have the time and inclination to help include it, feel free to do so! 😄

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.

Honestly, I haven't explored Vulkan yet. I initially chose GLES 2.0 as the primary renderer to ensure compatibility with a wide range of hardware. Introducing Vulkan myself would be a time-consuming task unless I receive assistance.

Regarding XWayland, Louvre doesn't currently support it, so it's naturally excluded. Well, it technically can run in rootful mode, but that is somewhat pointless. To enable independent window management, I believe I would need to create a mini X server, a task I haven't tackled as of now.

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.