In a workflow where most of the time the user alternates between TERMINAL and BROWSER, as described below, when I press $mod+s to search for something in BROWSER, I often get an unintended switch to LRU, such as TERMINAL, because the current focus window is in BROWSER.
~/.config/sway/config
set $switch-app swayr switch-to-app-or-urgent-or-lru-window -L --skip-urgent
bindsym $mod+d exec $switch-app TERMINAL || foot --app-id=TERMINAL tmux
bindsym $mod+s exec $switch-app BROWSER || qutebrowser --desktop-file-name BROWSER
In such a case, we thought that if we could make a behavior that cancels the switch to LRU even if the current focus is BROWSER, we would not need to check the window where the current focus is, and we could blindly concentrate on entering search terms.
I imagine that if user stay in ORIGIN for a period of time that exceeds an arbitrary number of seconds (such as a parameter specified in config.toml), pressing $mod+s will skip the switch to LRU, and then typing $mod+s again will switch to LRU.
How do you feel about this?
So you trigger your "switch to browser or LRU" command while being in the browser and now want to skip the LRU part depending how long you have already been in the browser? That sounds, um, interesting... :-)
Honestly, measuring focus times reliably would be quite hard. I'd need to track lots of different events and interpret them correctly.
If your actual problem is that sometimes some window which you only focused by mistake or had to have a quick look at stands in your way (because it's now the LRU), probably a (longer)
focus.lockin_delaycould help. Also, amisc.auto_nop_delayseems like a good idea when using theswitch-to-*commands. Otherwise, you perform such a command, then work in the selected window for an hour, and when you trigger it again, it re-starts from the middle of the logic sequence urgent, matching, lru, origin which can come as a surprise.
This was intended for use, for example, to ensure that one could perform a keyword search in a browser without checking what window was currently the focus, even while looking at a handwritten note on a desk.
I realized once again that blind keystroke operation without relying on sight greatly reduces the cognitive load.
I also tried adjusting lockin_delay and auto_nop_delay, but they did not seem to meet this objective.
However, after thinking about it, I realized that even in the form I proposed this time, it is not necessary to consider in advance what the current state of swayr (whether the specified stay time in ORIGIN has been exceeded or not?), which would be a new cognitive burden and confusing without avoiding unintended skips and switches. Therefore, we reconsidered that it would be more reliable to have a dedicated key that only focuses on the subject, as follows.
set $switch-app-one-way swayr switch-to-app-or-urgent-or-lru-window --skip-urgent --skip-origin --skip-lru bindsym $mod+shift+d $switch-app-one-way TERMINAL || foot --app-id=TERMINAL tmux bindsym $mod+shift+s $switch-app-one-way BROWSER || qutebrowser --desktop-file-name BROWSERYou may have it closed. Sorry for the trouble.
Thank you kindly.
No, but maybe it could be useful. I'll make a test version using flock etc. when I have time to try it out and see how it goes.
I made the following. It looks somewhat not so bad from a light use. I will use this for a while and see how it goes.
~/.config/sway/configset $switch-app ~/.config/sway/switch-app-test.sh bindsym $mod+d exec $switch-app TERMINAL || foot --app-id=TERMINAL tmux bindsym $mod+s exec $switch-app BROWSER || qutebrowser --desktop-file-name BROWSER
~/.config/sway/switch-app-test.sh#!/bin/bash TARGET=$1 ORIGIN_TIME=5 switch_app_one_way="swayr switch-to-app-or-urgent-or-lru-window --skip-urgent --skip-origin --skip-lru" switch_app="swayr switch-to-app-or-urgent-or-lru-window -L --skip-urgent" swaymsg [app_id="$TARGET"] nop || swaymsg [class="$TARGET"] nop || exit $? flock --nonblock /var/run/user/$UID/swayr-origin.lock --command "$switch_app_one_way $TARGET ; sleep $ORIGIN_TIME" || $switch_app $TARGET
The above shell scripts seem to work superficially well in my usage so far. Is it possible to consider these as a direction for swayr enhancements?