[Feature Requests] Behaviors related to focusing windows underneath other windows

[SturgeonInc]

I have a script meant for using a trackpad gesture to cycle windows that are stacked on top of each other (using the window cursor location rather than the active window as the target), kind of like a regional alt-tab.

This is kind of how I expected the "Activate Window Above" / "Activate Window Below" / "Activate window under" options to work like, but it is different, although I can't really explain the difference because I'm not very sure what the intended behavior for those actions actually is, so below is the script (it requires xdotool and wmctrl).

So my first request is clearer documentation on what those three actions do, especially "window below" vs "window under."

My second request is if the feature seen in the script could be ported, if you find it intuitive and useful.

My third request, related to that second request: in exploring the EndeavourOS iso installer preview (I say this as I'm unsure if it's a KDE feature or a sway feature), Super+left/right arrow changes the focus, just like the extension currently does. But, when there are no windows to the left/right of the focused window to give focus to, it will attempt to give focus to the window under the focused window, kind of like my script does. I find this to be very intuitive and useful behavior, and was hoping that maybe this also could be added, although maybe with a checkbox to enable it.

#!/usr/bin/env sh
# focus window under cursor and behind visible window.
# if there are multiple, then the order is determined by
# window IDs

# Usage: cyclewin-gesture.sh [-r]
#   -r  Reverse order of cycling

# gives X, Y, and WINDOW
eval "$(xdotool getmouselocation --shell)"
cursorY=$Y
cursorX=$X
visibleWin="$WINDOW"
DESKTOP="$(xdotool get_desktop)"

# get all windows in current desktop, and sort by ID
if [ "$1" = -r ]; then
    windows="$(xdotool search --all --desktop "$DESKTOP" --name '.*' | sort -r)"
else
    windows="$(xdotool search --all --desktop "$DESKTOP" --name '.*' | sort)"
fi

# cut and pastes the part of the list *after* the top (visible) window to the front,
# ensuring that cycling actually happens
# (instead of the lowest/highest ID windows always winning)
# also removes the already visible window from the listing, 
# so it isn't "switched" to it
windows="${windows#*"$visibleWin"} ${windows%%"$visibleWin"*}"

for win in $windows; do
    # gives WINDOW, WIDTH, and HEIGHT
    eval "$(xdotool getwindowgeometry --shell "$win")"

    # window in question is not under cursor, then ignore
    if [ "$cursorY" -lt "$Y" ] || [ "$cursorY" -gt $((Y + HEIGHT)) ] ||
        [ "$cursorX" -lt "$X" ] || [ "$cursorX" -gt $((X + WIDTH)) ]; then
        continue
    fi

    # if window in question is minimized, then ignore
    if xprop -id "$WINDOW" _NET_WM_STATE | grep -q _NET_WM_STATE_HIDDEN; then
        continue
    fi

    xdotool windowactivate "$win"
    return

done

[klangman]

So my first request is clearer documentation on what those three actions do, especially "window below" vs "window under."

The left/right/above/below hotkeys do the exact same action only in different directions. They use the algorithm that is selected in the "Active the window that is..." drop down menu. By default the selected window will be a window that is visible in the desired direction and is "closer" to the current window than any other window ("closer" being a bit fuzzy here since some windows are excluded because of an offset difference). Basically the default attempts to act like what most people would just intuitively expect.

The "Activate window under" hotkey is a bit different, and I added a tool-tip to that option in the config window to help describe the difference. This option will create a list of all windows in z-order, then it will activate the 1st window in that list where any part of it's window overlaps with the current window.

This works great for a case where the users presses the hotkey and gets the window he/she want's. If they don't get the window they wanted and hit the hotkey a 2nd time they would just be returned to the window they started with since it would now be the highest window in the z-order behind the window that just received the focus.

To fix this, I added a 3 sec timer where a 2nd hotkey press in that time period will activate the next hit in the window list that is lower in the z-order then the original window. In this way repeated hotkey hits will work it's way down the z-ordered list of windows that are under (overlap with) the original window. I think this behaves in a way that users would intuitively expect.

The code is found here

It looks like you script is similar, but without the timer window part, and it uses the mouse pointer as the selection criteria rather than the bounds of the current window.

My algorithm does not consider the mouse pointer, only the bounds of the current window (or the window that was current at the start of a hotkey cycle within the 3 sec timer). I could add an option to use the mouse pointer as the basis for calculating which windows are considered a "hit", but this extension is mostly used by keyboard-warriors so I don't think the option would be used by many people. Still, it would not be too much work so I could add it if that fits your needs?

when there are no windows to the left/right of the focused window to give focus to, it will attempt to give focus to the window under the focused window

I will think about switching to the "under" logic when there is no window matching to logic for the left/right/above/below hotkeys. Sounds like a reasonable idea at first glance. If it doesn't present any issues under further consideration I will add an option to have it work that way.

Thanks for the suggestion, and let me know if I misunderstood any of your points.

[qadzek]

when there are no windows to the left/right of the focused window to give focus to, it will attempt to give focus to the window under the focused window

In my opinion, the current default — doing nothing when you hit "Activate window to the right" and there isn't any window to the right — is the most intuitive behavior.

Some window managers and Tmux provide an option to "wrap around" in that case. For example, hitting "Activate window to the right" when C is in focus would focus A.

A | B | C

[klangman]

Some window managers and Tmux provide an option to "wrap around" in that case. For example, hitting "Activate window to the right" when C is in focus would focus A.

Ya, that also seems like a reasonable thing for people to expect. So what ever I end up doing it will need to be optional. Then it's just a matter of what the default should be, what behaviour would be what most people would expect/prefer. I am thinking that might be the current behaviour of doing nothing.

[SturgeonInc]

For 1. I see, sorry in retrospect the difference between under and below seems obvious.

For 2. I was trying to test out the Focus Window Under action just now, but I can't get the action to do anything. I think it did work before, back when I initially made the issue, but now it doesn't seem to do anything, I'm not really sure why.

Interestingly windows seem to capture the key-press sequence instead of the shortcut, when it is bound (changing the action of the keybind to anything else, including other actions in the extension, works as expected).

For 3. maybe you'd be interested in adding one or both features, with a selector in the settings to choose between "do nothing, wrap around, window beneath" when there is no further window to select in the desired direction

[klangman]

For 2. I was trying to test out the Focus Window Under action just now, but I can't get the action to do anything. I think it did work before, back when I initially made the issue, but now it doesn't seem to do anything, I'm not really sure why.

Interestingly windows seem to capture the key-press sequence instead of the shortcut, when it is bound (changing the action of the keybind to anything else, including other actions in the extension, works as expected).

That's odd.. What key-combo are you using? Maybe I can try it out here?