Built-in Louvre Applets

[Fox2Code]

Example of useful applets:

• Keyboard layout switcher
• Volume manager
• Notification tray

The idea is to have thoses on the base library and used by louvre-views, or at least the logic part, so compositor can customize UI/UX of thoses applets.

For status icons in the notification tray, XApps support can be considered, I'll say to use xapp code to understand how it work and make an implementation of it in Louvre that doesn't depends on GTK.

Relevant code: https://github.com/linuxmint/xapp/blob/master/libxapp/xapp-status-icon-monitor.c

I cannot use Compositors without a "Keyboard layout switcher" as I have a French "AZERTY" keyboard, which means if a compositor is stuck on "QWERTY" layout, I cannot use it.

This is to hopefully help compositors using Louvre implement features that are a "must have" for a lot of users.

I think the "Keyboard layout switcher" could be done in 2.2.0, but everything else should definitely wait for 3.0.0

[ehopperdietzel]

Hi, some of the points mentioned seem beyond the scope of Louvre, as they are not directly related to a compositor. Typically, panels that use the layer shell provide applets for managing these functions through D-Bus services. Additionally, with the introduction of the foreign toplevel management protocol, panels can now display running apps in a taskbar and request actions such as minimize, maximize, activate windows, and so on.

As you know, Louvre offers an API for dynamically switching keyboard configurations. There might be a protocol that allows clients to request these changes (such as configuration panels) which I could add. For example, there is a protocol for controlling output parameters like scale factor and mode, which I plan to add soon.

I am not familiar with XApps, but I'll take a look, they seem to be using D-Bus.

I think the examples should remain "basic". I want to continue developing a compositor called Crystals, which will be similar to louvre-views but I'll turn the status bar, dock, and desktop icons into external apps. I also plan to add a workspace switcher, implement global menus, and more. I think that will likely help me identify additional features to add to Louvre.

[ehopperdietzel]

I think it's better if Crystal becomes a reference implementation instead of Louvre after some point.

Yeah, I want to start from scratch and make it cleaner. Louvre-views has gotten quite messy with all the API changes.

Yeah, a portal would be nice to have for that, but I wasn't able to find any existing protocol to do that.

Most compositors handle that through their own configuration files or IPC systems. I'll check how GNOME and KDE manage this. The last thing I want is to reinvent the wheel.

Yes they use DBus, everything related to DBus should wait for 3.0.0 IMO

For now, I think anything not related to Wayland should stay out of Louvre. I don't want users to be forced to use specific portals or DBus services with Louvre. If they choose to use those services, they can manage them themselves. However, there might be some compositor-specific services where I could add some utilities.

If you want to work on Crystals before Louvre is ready, go for it!

For me, it's already functional. I actually use louvre-views most of the time, and it's just an example compositor. The only major thing missing is Xwayland. I'll probably focus on that next.

[Fox2Code]

Keyboard layout switcher, XWayland, and DRM leasing are the only thing left missing for me to be able to switch to Louvre full time.

I was thinking louvre could have an API to limit which apps can change compositor settings, something similar to what the Session Lock protocol is doing.

Related protocols: (XWayland protocols are optional to have XWayland support)

• https://wayland.app/protocols/ext-session-lock-v1
• https://wayland.app/protocols/xwayland-shell-v1
• https://wayland.app/protocols/xwayland-keyboard-grab-unstable-v1
• https://wayland.app/protocols/drm-lease-v1

[ehopperdietzel]

Keyboard layout switcher

The API to change the keyboard layout exists and is quite simple (LKeyboard::setKeymap()). The method for allowing compositor users to change it should be compositor-specific, such as through a configuration file, IPC, etc. If someone develops a generic protocol to allow applications to change it, then I could implement it.

I was thinking louvre could have an API to limit which apps can change compositor settings, something similar to what the Session Lock protocol is doing.

This is possible. If you launch an app from the compositor, you can get its PID. When an LClient connects to the compositor, you can retrieve its PID with LClient::credentials(). You can then allow a specific LClient to use a protocol with LCompositor::globalsFilter(). For example, in LouvreTemplate, I only allow xdg-desktop-portal-wlr to use the Screen Copy protocol using this approach. Globals in Wayland serve as the entry points for clients to use a protocol. If you filter a global for a client, the client will believe that the compositor does not support that protocol.

Related protocols: (XWayland protocols are optional to have XWayland support)

This will probably take some time.

[Fox2Code]

This is possible. If you launch an app from the compositor, you can get its PID. When an LClient connects to the compositor, you can retrieve its PID with LClient::credentials(). You can then allow a specific LClient to use a protocol with LCompositor::globalsFilter(). For example, in LouvreTemplate, I only allow xdg-desktop-portal-wlr to use the Screen Copy protocol using this approach. Globals in Wayland serve as the entry points for clients to use a protocol. If you filter a global for a client, the client will believe that the compositor does not support that protocol.

I just think for portals, having xdg-desktop-portal-lvr filter portals like how wayland protocols are filtered would be nice.

I think portals are an integral part of a Wayland compositor.

This will probably take some time.

Everything good take some time, Louvre took more than a year to get to where it is today!

First commit, January 21 2023: e4ff732

Don't worry, I can still wait for a lot more, don't worry about the community waiting, I think it's better to avoid rushing things.

[ehopperdietzel]

I just think for portals, having xdg-desktop-portal-lvr filter portals like how wayland protocols are filtered would be nice.

Basically, the only thing xdg-desktop-portal-wlr implements is Screen Capture, and it works with any compositor using the Wlr Screen Copy protocol. It doesn't necessarily mean it is for wlroots compositors, so re-implementing it just for the sake of changing its name is not really needed (that's why I decided to add that protocol). You can combine multiple portals for handling different things, for example, use the GNOME portal for file picker, another one for global shortcuts, and so on. I'm sure that when developing Crystals, I'll need to implement my own for some stuff that will surely work with any Louvre compositor.

Everything good take some time, Louvre took more than a year to get to where it is today!

Yeah, luckily most of the complex stuff is already implemented, so the remaining tasks shouldn't take me so long. I've found this post about creating an X11 window manager, and it doesn't look that complicated. I think the X Composite extension is very similar to how Wayland works.