Could Louvre be used to possibly port something like FluxBox to Wayland, or is it just a little too high-level?

[8bitprodigy]

Porting FluxBox to Wayland was part of why I started learning this project after all. My thought is to wrap Louvre API calls to something FluxBox can use to make it a bit more X11/WL-agnostic.

[ehopperdietzel]

I haven't had experience with FluxBox, so I'm not entirely sure about its features. Could you please inquire about the specific functionalities you're looking to implement? I'll then let you know if those are achievable with Louvre.

[8bitprodigy]

Louvre only provides functions for drawing textures and solid colors. So, for drawing more complex stuff, you would have to use your own shaders or toolkits.

So if I'm understanding correctly, there's a little bit of a gap in functionality between what Louvre provides and FluxBox needs, so I'd need to extend LScene and LViews in order to do this? Maybe I'll use Agar.

For now, if you want to identify an app without using any additional protocol, you can assign the app ID of a window (toplevel) from the client. Then, you can retrieve that string from the compositor using LToplevelRole::appId() and listen for when the client changes the string by overriding the LToplevelRole::appIdChanged() method.

Thanks! So Louvre can be used for non-compositor programs to communicate with the compositor? I'm assuming this could be used to create a dock/taskbar/window menu.

Thanks again for all your help!

[ehopperdietzel]

So if I'm understanding correctly, there's a little bit of a gap in functionality between what Louvre provides and FluxBox needs, so I'd need to extend LScene and LViews in order to do this? Maybe I'll use Agar.

Well, Louvre is designed for building compositors, and as its name implies, its purpose is to composite application windows (buffers) on screen which are accessible to you as OpenGL textures. Since it uses GLES 2.0, you could integrate Agar or any GLES 2.0 tools for more sophisticated rendering. However, if you aim for optimal compositor performance, alternative approaches could include creating an atlas of UI textures you want to use and displaying them as needed (rather than generating them or performing complex rendering in each frame with toolkits). Another approach would be to create Wayland clients (apps) to delegate such tasks (for docks, menus, etc.), and then simply display their generated textures.

Thanks! So Louvre can be used for non-compositor programs to communicate with the compositor? I'm assuming this could be used to create a dock/taskbar/window menu.

Essentially, Wayland facilitates communication between clients (apps) and the compositor (display server) through Unix domain sockets. Everything else, such as rendering and accessing system input, must be implemented independently by the compositor itself. You can conceptualize a Wayland compositor as a web server with a REST API, where clients communicate with it, with the distinction that the server can also send messages to clients at any time. Now, there are numerous protocols like the Wayland protocol, XDG Shell, Viewport, etc., and you even have the flexibility to create your own. Each protocol consists of a set of interfaces, and each interface has a set of requests and events. As the name implies, each protocol defines rules on how the compositor and clients should behave. Louvre implements some of these protocols, particularly the crucial ones, and provides a simplified C++ API to the dev.

For example, when a client makes this request from the XDG Shell protocol and xdg_toplevel interface, Louvre first handles it in a low level layer here, and then notifies to the public API invoking LToplevelRole::appIdChanged().

You can also add your own protocols in Louvre (for example, to send custom events to clients or listen to custom requests from clients), you should of course implement such protocols in the client side as well. I recommend reading the Wayland Book to gain a better understanding of how Wayland operates and how to create and implement your own protocols.

I should add a chapter to the tutorial to demonstrate how to create and implement a custom protocol both in Louvre and on the client side.

[8bitprodigy]

Thanks again for your time helping me. I think if I do try to progress with this project, I'll make those parts that are in Fluxbox part of this one, too, at least at first, with the goal being to separate them later. I'll also have to look into what all xlib does that fluxbox uses.

[ehopperdietzel]

Fantastic! Best of luck 😃 Feel free to showcase your project in the Gallery if you choose to proceed, and don't hesitate to initiate new discussions for any specific questions you may encounter along the way.

[8bitprodigy]

Will do. Also, there is currently waybox by wizbright which replicates OpenBox, which is similar, but using wlroots.
That said, it does link to some projects that can replicate some of those features in fluxbox, such as the panel and what-not.