Is there a working workspace list for any of the suggested bars?

[agoodfellow123]

Hello, I haven't been using labwc in a while. The reason I stopped using was silly but it mattered to me a lot. At the time I used it, there wasn't support for any of the bars to show the workspace list. Since then, I noticed xfce4panel got wayland support. So I thought that might be it but I actually have little hope of that working.

Ever since that, I also have seen people who forked waybar and make it work for their own environments. For example this one uses wlr/workspaces module instead of sway/workspaces module however I haven't tried it on labwc yet.

Would any of these work? I really want to return back to labwc but my perfectionism keeps me away.

[johanmalm]

I'm sure we'll do this one day, but I prefer not to make promises about when.

Ref:

• https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/40
• https://github.com/labwc/labwc-scope#25-configuration---desktop

[Tamaranch]

Since then, I noticed xfce4panel got wayland support. So I thought that might be it but I actually have little hope of that working.

We have implemented a pre-support for ext-workspace-unstable in libxfce4windowing and the workspace switcher of xfce4-panel uses it, but of course for the moment it is only virtual, since no compositor supports this protocol to my knowledge. (And there's probably still some work to do on our side anyway.)

[agoodfellow123]

Roger that. Thank you. Do you know an easy way to follow when ext-workspace-unstable will get implemented in libxfce4windowing? If not I'll just check every six months.

[Tamaranch]

It is already (pre)implemented in libxfce4windowing. The question is when this protocol will be accepted upstream (for that you can follow the merge request above), so that compositors, including Labwc, start using it.

[agoodfellow123]

Got it!

[raitonoberu]

Here is my solution. It's pretty basic, but it fits my needs and can be used with any bar.

The idea is to make a script that listens to a named pipe and prints a list of workspaces on every update. labwc writes to this pipe when switching workspaces.

The script itself:

#!/bin/bash

# <config>
NUMBER=5
SYMBOL_CURRENT=""
SYMBOL_OTHER=""
PIPE=/tmp/workspace
WRAP=true
# </config>

# format_line takes the current workspace number [1..N] and prints a string
# representing the list of workspaces (e.g. 4 -> "0 0 0 1 0")
format_line() {
    before=`yes $SYMBOL_OTHER 2>/dev/null | head -n $(($1 - 1))`
    after=`yes $SYMBOL_OTHER 2>/dev/null | head -n $(($NUMBER - $1))`
    echo $before $SYMBOL_CURRENT $after
}

# remove an existing pipe and make a new one
rm -f $PIPE
mkfifo $PIPE

# print initial state
current=1
format_line $current

while true
do
    if read input <$PIPE; then
        if [ $input == "right" ]; then input=$((current + 1)); fi
        if [ $input == "left" ]; then input=$((current - 1)); fi

        if (( $input < 1 )); then
            if [ "$WRAP" == false ]; then continue; fi
            input=$NUMBER
        fi
        if (( $input > $NUMBER )); then
            if [ "$WRAP" == false ]; then continue; fi
            input=1
        fi
        if (( $input == $current )); then continue; fi

        format_line $input
        current=$input
    fi
done

Add actions to rc.xml:

<keyboard>
  <keybind key="W-1">
    <action name="GoToDesktop" to="1" />
    <action name="Execute"
      command="bash -c 'echo 1 > /tmp/workspace'" />
  </keybind>
  <keybind key="W-2">
    <action name="GoToDesktop" to="2" />
    <action name="Execute"
      command="bash -c 'echo 2 > /tmp/workspace'" />
  </keybind>
  <!-- and so on -->

  <keybind key="W-C-Left">
    <action name="GoToDesktop" to="left" />
    <action name="Execute"
      command="bash -c 'echo left > /tmp/workspace'" />
  </keybind>
  <keybind key="W-C-Right">
    <action name="GoToDesktop" to="right" />
    <action name="Execute"
      command="bash -c 'echo right > /tmp/workspace'" />
  </keybind>
</keyboard>

Use it like this (Waybar):

"custom/workspaces": {
  "exec": "~/.config/waybar/scripts/workspaces"
}

You can also set up scrollable workspace switching using wtype:

"custom/workspaces": {
  "exec": "~/.config/waybar/scripts/workspaces",
  "on-scroll-up": "wtype -M win -M ctrl -k right",
  "on-scroll-down": "wtype -M win -M ctrl -k left"
}

[stefonarch]

Nice, but it looks like it will work only if you switch workspaces by shortcut, I've apps tied to some workspace which are activated by click on the taskbar or by a link (browser and mail) and I use also mostly 3-finger swiping to switch. It would be nice if the OSD could "export" the target workspace but it would still not be enough.

[BGazotti]

It's been a while, but are there any plans to implement this in a consistent manner? Last I checked there were at least two unstable protocols that could be used (wlr-foreign-toplevel-management-unstable and ext-workspace-unstable) but the state of adoption seems to be rather lacking to put it lightly.

How are other compositor/bar combinations handling this (instead of falling back to sway-specific features)? I feel like we're missing an important feature here but it doesn't help that there doesn't seem to be a standard way of getting it to work.

[Consolatis]

wlr-foreign-toplevel-management is supported by labwc but doesn't support anything workspace related.

How are other compositor/bar combinations handling this (instead of falling back to sway-specific features)? I feel like we're missing an important feature here but it doesn't help that there doesn't seem to be a standard way of getting it to work.

Some are likely rendering a bar within their own compositor thus they do already have the state and don't need a protocol for that. Others are likely using their own private wayland protocol or some other form of custom IPC.

Labwc generally will not support custom IPC nor private wayland protocols. However, in this case we may end up actually ignoring our own stance at some point and implement one of the unofficial variants (without the ext- prefix) because this is really getting ridiculous! (almost 3 1/2 years since the PR was opened). Similar thing for things like marking a window Always-On-Top / Visible-on-all-workspaces via a taskbar.

Maybe we actually need a new wayland-protocols structure at some point that caters for these kind of (IMHO essential) protocols.

[droc12345]

There are some proposed changes in window switching behavior,
with the changes, it would be possible to switch to any window on any workspace,
and I have some changes on top of that, that would show workspace of each window as well as
state (full, max, min), but I think it will be after 7.1 before it's implemented.

see #1479 (comment)

[stefonarch]

I have some changes on top of that, that would show workspace of each window as well as state (full, max, min)

Can this be exported (including xwayland/xdg-shell information) to be used by some command or other tools like panels? Atm the only way to see if an app is running in xwayland mode is the switcher, a kind of list like lswt would be nice.

[droc12345]

No easy way export the data, as some of the data is internal with no easy way of sharing.
The foreign toplevel doesn't address things like workspace name/num.
That's why the window switcher has all the data itself, so that it can be easily seen,
with the new behavior, you can check for running or just swap over to the running app, no matter the ws.

[Consolatis]

Atm the only way to see if an app is running in xwayland mode is the switcher, a kind of list like lswt would be nice.

Hacky workaround:

#!/bin/bash

x11=( $(wmctrl -l -x | awk '{print $3}' | sed 's/^[^.]*[.]//') )

wlrctl window list | while IFS=':' read -r app_id title; do
	backend="[xdg]"
	for WM_CLASS in "${x11[@]}"; do
		if test "$WM_CLASS" == "$app_id"; then
			backend="[x11]"
			break;
		fi
	done
	printf "%-15s\t%5s\t%s\n" "$app_id" "$backend" "$title"
done

[droc12345]

A socket that would only output certain data from certain commands would be ideal.
Though I do understand not wanting to mess with it both from a purist viewpoint as well as implementation,
because I'm not sure how straight forward it would be.

Another thought is something like window switcher, but the window wouldn't allow change, just display the data, though alt tab and then escape does almost that. A separate window could be made mostly transparent in perhaps an overlay fashion.

Just a couple of thoughts.