Labwc support
Hijacked by bbedward
LabWC support is done, more or less.
What remains:
- ~~Identifying the equivalent of
dpms offin hyprland,power-off-monitorsin niri. Is disabling all outputs via wlr-output-management an option?~~ Done 984cfe7f98a4c6db2d8e0a83e171683053280d0d + d76930013763fa59852a1515653ad7156fabbb87 - ~~Adjustment for workspaces with extremely long names (albet, this also applies to niri and others)~~ Done, but TODO - probably add named workspace -> icon mapping support like niri has
- Support for keyboard switcher widget
Original Request
I could use help with implementing workspace supporting Labwc
I'm working on getting the matugen integration working right which is getting there. But i'm not good enough with quickshell to work out the Workspace widget. I'm also working on a Material you inspired theme for Labwc to better fit in with the dms aesthetic.
Waybar supports the ext-workspaces protocol which works for Labwc. Maybe a more generalized implementation supporting that would help Labwc and other compositors that want to use the protocol.
I will get ext-workspace implemented and provide a universal variant of workspace switcher.
https://github.com/AvengeMedia/danklinux/commit/06bad482e493755eb56020158251add4a41050d3
80e690f9fc03c66b72c6c7e8403b324d3cb46d84
ext-workspace-v1 is done
it just is automatically used by the widget, if not niri, not hyprland, not dwl, and not sway. Albeit it technically works for all of those.
I added a var to DMSService to override it (that I used for testing on niri). It seems to work fine, but keeping the niri-specific version for now.
readonly property bool forceExtWorkspace: false
I basically just have full labwc support now... feel free to contribute to docs https://github.com/AvengeMedia/DankLinux-Docs
I didn't test it, but ext-workspace-v1 works, and wlr-output-management-unstable-v1 is now implemented, and works for scaling.
Future compositors should have a much easier time, given those too. For labwc specifically I added the launcehr logos and IRC link and stuff.
Sadly this isn't quite done. First off: Thanks for the super quick response and changes. Launcher Icon is working fine, but i'm getting no workspaces displayed in the bar. The widget reserves minimal space, but nothing else. Here it is with waybar below it, to show desktops to in fact exist:
One additional issue i noticed is the wallpaper "blocking" the desktop. On Labwc clicking on the "root" or "Desktop" reveals a Menu. This doesn't work as the wallpapers is overlayed over the Desktop.
Another thing missing where i'm not sure if this is implemented for other compositors is reloading the compositor on theme/wallpaper changes. I currently use DankHooks to run "labwc -r" after changes. This could probably be included out of the box.
I just reverted labwc references from the docs + code, I can't test it because labwc doesn't work for me - on either of my DRI devices. So any work has to be done by someone else to complete it.
I can give some hints, though.
- You have to update both components...always (https://github.com/AvengeMedia/danklinux) , if you do not use
dms runwith a new enough version of the dms API, you will not haveext-workspace - WallpaperBackground.qml - i have no idea why it wouldnt block the desktop, it uses wlr-layer-shell and is on the
backgroundlayer which should be correct.
I did confirm the ext-workspace implementation works functionally equivalent to the niri IPC implementation, on niri.
Ok, so that's on me. I didn't update the backend component. It's working now. Though formating With Workspace Names shown isn't great. The Indicators don't grow in size with their Names.
I'm not sure what those names are or that it'd even be desirable to have them there. I'd like to support labwc but it is just giving me segmentation faults (but other wlroots compositors work fine like mango)
The only major thing that might be missing is wlr-output-power-management - I'm willing to implement this though, just for the dpms on/off events for the idle manager.
Either way I need a contributor to finish this up, the hard parts are done:
- ext-workspace-v1 protocol implemented
- wlr-output-manager protocol implemented (for fractional scaling)
In Labwc, Workspace can be individually named. The Configuration support either numbered Workspaces, Numbers with a Prefix, or Named Workspaces. Disabling "Workspace Index Numbers" in the Settings hides the Names. I'll look into whether i can figure out how to properly scale the indicators with Name length.
I don't think anybody wants that in a workspace widget, it takes up too much space. Maybe a niri similar thing that allows you to assign icons to named workspaces
I wonder whats the memory usage of Dank on labwc and how different it is from say niri
Havent compared it jet, but i'm currently setting up niri. On Labwc it's around 800MB
btop shows RSS I'm pretty sure, if you're especially memory conscious you might feel better checking PSS (like gnome system-monitor or dgop) - which more specifically shows non-file backed memory - basically that is the memory the kernel cannot reclaim.
RSS especially looks inflated for quickshell since it loads a lot of shared libraries.
That said, memory usage of DMS will be pretty equal, whether on niri or labwc or any compositor.
One additional issue i noticed is the wallpaper "blocking" the desktop. On Labwc clicking on the "root" or "Desktop" reveals a Menu. This doesn't work as the wallpapers is overlayed over the Desktop.
That means likely that DMS does not set an empty input region and thus receives the mouse events, for an example see https://github.com/swaywm/swaybg/blob/master/main.c#L286.
I'd like to support labwc but it is just giving me segmentation faults (but other wlroots compositors work fine like mango).
I am not aware of any reports regarding segfaults in labwc. Earlier wlroots 0.19 versions had some issues though, so maybe using wlroots 0.19.2 will fix it.
One additional issue i noticed is the wallpaper "blocking" the desktop. On Labwc clicking on the "root" or "Desktop" reveals a Menu. This doesn't work as the wallpapers is overlayed over the Desktop.
That means likely that DMS does not set an empty input region and thus receives the mouse events, for an example see https://github.com/swaywm/swaybg/blob/master/main.c#L286.
I see, from my look quickshell doesn't expose the ability to do this. But it's an easy addition, I'll open a PR over there tomorrow
It has to be done on that side since qs owns the surface
~~PR in quickshell: https://github.com/quickshell-mirror/quickshell/pull/363~~
~~I confirmed that it fixes labwc not receiving mouse events. (when setting it to None, in WallpaperBackground)~~
Apparently already exposed, didnt realize it. 64ec5be91934bd4ce5125f251d167bb15f34d7f1 fixes the clickthrough
So in my testing its pretty good, I restored labwc to the documentation (https://github.com/AvengeMedia/DankLinux-Docs) but its sections are TODOs for now.
ANd I updated the original request, with my perceived remaining TODOs, at least. And pinned the issue.
- Identifying the equivalent of
dpms offin hyprland,power-off-monitorsin niri. Is disabling all outputs via wlr-output-management an option?
I would recommend not using wlr-output-management for this task. It will remove the monitors from the layout and thus move windows around. I'd suggest to instead use wlr-output-power-management either directly or to call out to wlopm.
- Adjustment for workspaces with extremely long names (albet, this also applies to niri and others)
There are two variants on the labwc side to handle this:
<desktops number="3" prefix="" />
or
<desktops>
<names>
<name>💻</name>
<name>📺</name>
<name>📜</name>
</names>
</desktops>
- Support for keyboard switcher widget
That is sadly not possible right now. You can see the currently active keyboard layout by listening to the group modifier (labwc broadcasts it to all clients rather than just the focused one) but there is currently no wlroots or official protocol to set it from an external client. There is some discussion about a potential protocol here.
I added dpms on/off commands to dms: d76930013763fa59852a1515653ad7156fabbb87 - which does power 0/1 via wlr-output-power-management. CLI-only, which I think is fine given you have to destroy the controls anyway to release them.
I didnt wire it up yet though to the idle service (for labwc/wlroots other compositors) since I didnt get to fully test it. I suspect other wlroots-based compositors have a problem... because on DWL/MangoWC I can power off, but compositor rejects power on events for some reason despite the control being successfully created (mango does it via its own IPC not protocol, though it implements it)
Once I verify its good on labwc tomorrow I'll wire it up to the idle service, then that part of the puzzle would be done.
It works for me, so I wired it up 984cfe7f98a4c6db2d8e0a83e171683053280d0d
I would fall back to the wlr protocol for all other compositors, but because some apparently have bugs/implementation issues with wlr-output-power-management I made it explicitly use dms dpms off/on only if it is explicitly LABWC.
Just since at least dwl seems to be unable to power the monitors back on again.
i also fixed sorting, if coordinates are not present - and made it not display the full names in the widget (index numbers work). Though maybe just a size limit on names would work fine.
Closing as completed. Labwc is nearly 100% supported beside some things which could be argued as optional.
- Keyboard layout widget
- Matugen templat
- We have native screenshot and color picker tools, that should work - but screenshot will be lacking the ability to grab specific windows (due to lack of protocols that I could find to provide window geometry)
- We have native screenshot and color picker tools, that should work - but screenshot will be lacking the ability to grab specific windows (due to lack of protocols that I could find to provide window geometry)
"Toplevel capture" will come when wlroots releases 0.20.0. There is a proof-of-concept PR here if somebody wants to test screen recorder implementations. Depending on the way the screenrecorder operates (wayland native protocols vs xdg-desktop-portal) a newer version of xdg-desktop-portal-wlr might be required as well.