Guidance on tweaking Cagebreak

[kinleyd]

Now that I have Cagebreak set up very close to my needs, there are a few areas where I would appreciate some help in tweaking it further.

1. Where can I configure my keyboard repeat and delay rates? The current default that I'm getting isn't ideal:
   interface: 'wl_seat', version: 7, name: 10
   name: seat0
   capabilities: pointer keyboard
   keyboard repeat rate: 25
   keyboard repeat delay: 600

2. Is there an idle screen/output handling tool that you could recommend as suitable for Cagebreak? It would be nice to have the monitors blank out when idle for a specified duration.

3. Also, if I turn off an output, or if it isn't on at load time, Cagebreak is unable to access it unless we restart Cagebreak. I've looked at dynamic output managers like Kanshi which seem like the solution. However, it isn't supported by Cagebreak: we get this message 'compositor doesn't support wlr-output-management-unstable-v1'. Regarding this my questions are: what would you recommend for dynamic output management, and, is there any chance you might add support for a tool like kanshi?

TIA

[project-repo]

 1. Where can I configure my keyboard repeat and delay rates?

Indeed there is no interface for this atm. This is another one of these
things that was never implemented because no one had a use for it until
now. We will add this as an option to the input command.

 2. Is there an idle screen/output handling tool that you could recommend
    as suitable for Cagebreak? It would be nice to have the monitors blank
    out when idle for a specified duration.

No, we have never looked into this so far... Have you found anything
that works well? If not, we may take a look at this sometime.

 3. Also, if I turn off an output, or if it isn't on at load time,
    Cagebreak is unable to access it unless we restart it. I"ve looked at
    dynamic output managers like Kanshi which seem like the solution.
    However, it isn't supported by Cagebreak: we get this message
    'compositor doesn't support wlr-output-management-unstable-v1".

Yes, this is not supported by cagebreak atm. We
will look into what is involved in implementing
wlr-output-management-unstable-v1 and get back to you on that.

Thanks for the suggestions!
cheers
project-repo

[kinleyd]

Thanks for getting back and the willingness to take a look at these issues.

If it is possible to implement wlr-output-management-unstable-v1, one benefit would be that it would also make wlr-randr and some other Wayland tools compatible with Cagebreak.

For idle management, currently it looks like there is only swayidle. However this requires support for KDE's idle protocol.

There is one other nice to have tool for screen shots, slurp. However this requires support for zwlr_layer_shell_v1.

So I'm throwing up a number things, hoping it's possible. :)

[project-repo]

Oh ok, we'll take a look at the idle protocol, though I can't guarantee
that we will add it: I guess it depends on whether the amount of new
code needed is proportionate to the benefits.

As for the layer_shell protocol, we already considered this sometime
back and decided against adding this: It's actually quite an involved
protocol (probably something like +500 to +1000 loc) and at the time it
did not seem worth it. However, if this keeps coming up or if many
people would support this, we may reconsider. Though probably not in the
near future.

cheers
project-repo

[kinleyd]

Thanks, greatly appreciate your openness. Just want to add that my current wm of choice on the Xorg platform is EXWM - which is Emacs all the way. Short of that, on Wayland, I like Cagebreak's mimimalism and Emacs-friendly configuration, and it is getting extremely close to being a daily driver for me.

[project-repo]

Hi kinleyd,

we have implemented some input keyboard configuration. The rest remains pending.

I am leaving this issue open

cheers
project-repo

[TCCQ]

Hello,

I understand the decision to not include layer_shell, it does look pretty involved. Would you consider adding something like a native window switcher? I'd like to be able to switch to a application by name, or at least emulate that. My use case would be many fullscreen applications that I'd like to swap between. I'd use the rofi wayland fork, but that requires the layer_shell protocol. However the only part of that I can't emulate in one way or another is the window switching, so that seems like a small reward for a lot of work. Am I missing any part of the existing system that I could use to achieve this, or would this have to be an addition?

[project-repo]

Hi TCCQ

A window switcher should be possible if you enable the socket (-e
option) and script it yourself (example_scripts/ and man/ might be
useful to you if you're planning on doing so).

However, for security reasons the view title is not available over the
socket (as it might contain titles of browser tabs or document names).

Instead, you could match the process pids to the windows and use
that to focus the required window.

Would this satisfy your needs?

If you think this could be helpful, we might just implement this for you
and expand our example_scripts collection.

cheers
project-repo

[TCCQ]

Hi,

I am kind embarrassed that I didn't even consider the socket as a solution for this. That's the kind of thing it is for. I think that could work for sure. I would want to either be able to assign names to windows, or use some other human readable trait, like an appid or something. I suppose I could also maybe use pids out side of cagebreak to get command line names, or something like that. Either way, I think is is a solution to my problem. I certainly wouldn't decline someone who knows how to use the socket writing it for me, but please feel no pressure if it would be a bother. I am sure I can write it myself, it would just be a question of when I get around to it. Thanks for the quick reply!

[TCCQ]

After messing about with it a bit, I found that yofi does what I want and does not require the layer_shell protocol, so I will be using that. Just thought I would put that info here so other people can find it.

[TCCQ]

Hello again.

After a bit of tinkering, I am up against a new wall. By my reading of the socket and config man pages, there is no way to switch directly to a tile or view by id. There is similar functionality for workspaces and screens (I imagine becuase they are numbered to begin with), but there no no equivalent for views/tiles. I can deal with switching focus to the right workspace/screen, but I think the only way I could get it to work currently would be to iterate over the views with focus next, and waiting for the event for a new focus, and stopping when I get to the right one. I think this is asking for bugs and side effects. Am I missing something? Would it be possible to add / hack together a focus [view/tile id] command?

[project-repo]

Hi TCCQ

Yes, that is right, atm there is no way to focus a view by its id.
Actually, we also ran into this when implementing the script that we
promised and solved it exactly the way you suggested.

This is of course not particularly elegant and thus, yesterday,
we decided to include a feature for focussing views by id in
the next release.

Note that due to a bug in cagebreak which was fixed yesterday, this
script will only work when using the latest development version of
cagebreak. You can find it attached.

We will let you know once there is a first version of the new feature
available.

Cheers
project-repo

#!/bin/bash
# Copyright 2023, project-repo and the cagebreak contributors
# SPDX-License-Identifier: MIT

# This script displays the process names of the views on the current workspace.

# Start up the ipc link
source "$(dirname "${BASH_SOURCE[0]}")/cb_script_header.sh"

echo "dump" >&3

exec 5<&0
target_view_pid=-2
while IFS= read -r -d $'\0' event
do
        # Remove the cg-ipc header
        event="${event:6}"
        if [[ "$(echo "${event}" | jq ".event_name")" = "\"dump\"" ]] && [[ ${target_view_pid} -eq -2 ]]
        then
                curr_output="$(echo "${event}"|jq ".curr_output")"
                curr_workspace="$(echo "${event}"|jq -r ".outputs.${curr_output}.curr_workspace")"
                # Print the process names of the view on the current workspace. jq retrieves
                # their PID and ps is then used to retrieve the process names.
                # shellcheck disable=2046
                readarray -t pids < <(echo "${event}"|jq -r ".outputs.${curr_output}.workspaces[$((curr_workspace-1))].views[].pid"|sort -n)
                ps -o pid=PID,comm=Command -p "${pids[@]}"|nl -v 0
                cpid=0
                while ! ([[ ${cpid} -ge 1 ]] && [[ ${cpid} -le ${#pids[@]} ]])
                do
                        echo -n "Type number of view you wish to focus and press enter to continue[1-${#pids[@]}]":
                        IFS=$'\n' read -r cpid <&5
                done
                curr_view_id="$(echo "${event}"|jq -r ".views_curr_id")"
                target_view_pid="${pids[$((cpid-1))]}"
                echo "next" >&3
        elif [[ ${target_view_pid} -ne -2 ]] && [[ "$(echo "${event}" | jq ".event_name")" = "\"cycle_views\"" ]]
        then
                if [[ "$(echo "${event}"|jq ".new_view_pid")" == "${target_view_pid}" ]]
                then
                        exit
                elif [[ "$(echo "${event}"|jq ".new_view_id")" == "${curr_view_id}" ]]
                then
                        echo "Requested view is already visible on other tile"
                        exit
                fi
                echo "next" >&3
        fi
done <&4

[TCCQ]

Thanks a bunch!

[project-repo]

Hi TCCQ

Just to keep you in the loop, we just released a new version of cagebreak. Contrary to our previous statement, this release does not contain the features we mentioned above (sorry about that). We hope to get them in the next minor version.

The script from above should continue to work as a workaround though.

Cheers
project-repo

[g4bwy]

Hi,

For what it's worth, you may have a look at my take on solving the "focus to view id" issue: g4bwy@c2c5e32

It has the limitation of working only in the current workspace (the same way prev/next commands do). This might not be the most elegant or semantically correct way to do this, but it just works for me.
I'd be more than happy to get some feedback about it with the goal of maybe upstreaming this feature.

My goal with this modification was to implement the same functionality as ratpoison's "other" command (or stumpwm's "other-window" function) using an external IPC daemon (written in Go and available here: https://github.com/g4bwy/cbgo)

I also had to make this other modification to simplify state tracking in the external daemon when switching between workspaces: g4bwy@f7ba158

cheers,

[project-repo]

Hi g4bwy

Thanks a lot! We're actually planning on implementing something similar
at some point (there is no timeline currently though), so this will may
be a good reference once we start looking into it.

Cheers
project-repo