Feature Request: Make DockApps usable with other Wayland compositors

[st0rm-shad0w]

@phkaeser - First of all, thank you so much for the v0.7.1 release and all the work that's gone into wlmaker. The new clock, system monitors, clipboard support, and everything else have been wonderful to see come together. It's easily one of the most exciting projects in the Wayland space right now.

I wanted to suggest the idea of making the DockApps (clock, eyes, CPU/memory monitors, etc.) usable outside of wlmaker too, so people running other compositors like Sway, DWL or LabWC could also enjoy them. The original Window Maker dockapps were popular partly because they worked across multiple window managers, and it would be amazing if wlmaker's DockApps could follow that same spirit. This isn't a request to change how they work inside wlmaker at all. Just wondering if there's a path to let them run standalone as well, so more people can benefit from them and maybe even inspire others to build new ones. Happy to help in any way I can thanks again for this fantastic project!

[phkaeser]

Thank you, @st0rm-shad0w . That is a good idea, and I'm hoping to begin working towards a more general dock model vor v0.9.

What made Window Maker's DockApps very powerful is that the applications were able to draw entirely custom content into a window (in Wayland terms: a surface). I know that the Cosmic compositor has support for such "mini-applications".

For Sway, I am not aware of such support for arbitrary surface content. How do you envision that DockApps would be shown in Sway (or, DWL or LabWC for that matter) ?

[st0rm-shad0w]

Thanks @phkaeser, for being open to the idea! :)

Since I'm definitely not an expert in this area, I checked with @Consolatis (who manages LabWC development) to get a better sense of how this could work in compositors like LabWC or Sway. He helped break down two potential approaches:

1. The Layer-Shell Daemon: This would be a standalone wlr-layer-shell app acting as a host. It would use a custom IPC (like a Unix socket or D-Bus) to grab pixel buffers from the DockApps and show them as subsurfaces.

2. The Sub-Compositor Route: Here, the dock actually implements a minimal Wayland compositor of its own. DockApps would connect to it as regular Wayland clients, and the dock would render those surfaces into its own window.

The first way is probably simpler to implement but needs a custom IPC protocol, while the second is more robust but a bit heavier on the technical side. @Consolatis mentioned he’d be happy to help brainstorm the technical direction if you’d like an extra perspective.

Also, regarding COSMIC, do you happen to have a link or any docs for that mini-application protocol? We took a look through their unstable protocols but couldn't quite pin down which one handles that specific behavior.

Really looking forward to seeing how v0.9 evolves!

[phkaeser]

Thank you for following up and engaging with LabWC, too!

From what I understand, LabWC currently does not have direct support for DockApps. The approaches align well with what I heard and would like to pursue. Some background:

For COSMIC: The cosmic-panel application is a sub-compositor; and the panel apps are themselves regular Wayland applications (XDG shell applications, IIRC) that are launched to connect to cosmic-panel as their compositor. Essentially, approach (2) you mentioned. This works well for DockApps; and is the route I'd like to take. https://pop-os.github.io/libcosmic-book/panel-applets.html has some documentation, or https://github.com/pop-os/cosmic-applets for browsing the source.

The dock in Window Maker is not only for hosting dock-apps, though -- it also serves as launcher for any application. For that, it shows that application's icon. On Window Maker, X11 applications can publish an icon as surface. On Wayland, there is https://wayland.app/protocols/xdg-toplevel-icon-v1. Alternatively, icons are looked up using the XDG .desktop configuration files.

The current implementation of Wayland Maker's DockApps are using a custom Wayland Protocol; the dock itself is a component running within the wlmaker binary. This was good and quick to start, but I'd like to move beyond that.

Here's the rough plan:

• Wayland Maker's Dock (and Clip) should be moved into running as separate processes. Both will be applications using the wlr-layer-shell protocol; and thus would work also with other compositors (LabWC, Sway, ...)
• DockApps should be using the sub-compositor approach, similar to what cosmic-panel is using. That would make the apps compatible with that panel (and vice-versa), and not needing any custom protocol by default.
• For Wayland Maker, the compositor will need a way to forward application icons (using the XDG toplevel Icon protocol; or X11 icons) to the Dock. For that, an extension to Wayland Protocol will still be required. The dock will be functional without that extension; just without showing these icons.

The COSMIC developers had already identified the problem of forwarding application icons to the dock as a problem; and we briefly discussed the need of a Wayland protocol extension. If LabWC is interested, we'd have a better chance of proposing and submitting that as part of the Wayland protocols.

[Consolatis]

The COSMIC developers had already identified the problem of forwarding application icons to the dock as a problem; and we briefly discussed the need of a Wayland protocol extension. If LabWC is interested, we'd have a better chance of proposing and submitting that as part of the Wayland protocols.

Yes, absolutely. An ext-toplevel-list extension protocol for the icon buffer / icon name would be very useful for panels to prevent de-synchronizing the icons shown in panels vs compositor side window decorations and remove the need for panels to look up .desktop files based on the app_id. At the current state it would also require an extension of wlr-foreign-toplevel-management to match the ext-toplevel-list handle with the wlr-foreign-toplevel one.

[furbot-gubbe]

Thank you both. I'll first want to get some basics hacked (a subcompositor, ...), and then look into the specifics of the wayland protocol extensions.

Managing expectations: Will try getting to it in the next 1-2 months, but with only a few hours per week available, there's no guarantee :)

[phkaeser]

(well, that comment was from me, but confused with github's multiple users...)

[st0rm-shad0w]

@phkaeser - Thanks for sharing the plan, also no rush, take your time. Do let me know if you need help with any testing!