chose window that had the focus last

[andreimatei]

Hi there! Thank you very much for this extension. I just started using it to assign keyboard shortcuts to moving the focus to specific windows with Wayland on Ubuntu 23.04. Previously I was using a script based on wmctrl, but it broke because some applications no longer seem to appear in the list of windows displayed by wmctrl -l (perhaps because they transitioned from X to Wayland?).

I've got one feature request if you're so inclined - when an application has multiple windows, would it be possible to focus on the one that previously had the focus last? At the moment, it seems to always focus on the same window - I think the first window to have been created.

Thank you!

[lucaswerkmeister]

At the moment, it seems to always focus on the same window - I think the first window to have been created.

Well, it selects the first window in the list returned by GNOME that matches the condition – I guess GNOME’s list is sorted by when the windows were created or something. But for my use cases so far, the assumption is that the window is uniquely identified anyways (e.g. my main use is to manage terminals, either activating or creating a certain tmux session), so the order doesn’t matter.

I’m still hesitant to just change it, though, because someone else might already rely on the current behavior. I’m not sure what other options we have… it would be ideal if dbus had some notion of optional parameters (so you could call either activateByPrefix('Firefox') or activateByPrefix('Firefox', 'last')), but I’m pretty sure I already looked into that in the past and concluded it didn’t exist. We could introduce a method to change the sort order for all subsequent calls, but that’s a form of global state which can cause other problems…

[Bitals]

@andreimatei a workaround, maybe: use virtual desktops. They are always accessible with shotcuts (not set by default I think, but configurable in settings or dconf editor). In my case I usually have 2 terminals open, one lives on Desktop 2, the other on Desktop 8, so Ctrl+Alt+2 to get to the first one.

You also can switch Virtual Desktops with wmctrl -s <VDnumber> (still works under Wayland), making it possible to bind to any shortcut you want, keeping them all in line.

[lucaswerkmeister]

We could introduce a method to change the sort order for all subsequent calls, but that’s a form of global state which can cause other problems…

Maybe we should just go for this, to be honest. It’s not super nice, but perhaps it still beats not having the ability to choose the sort order at all.

I suppose the sort order setter could even return the previous sort order, so that you can temporarily set the sort order, select a window, and restore the previous sort order, in one batch of commands, if you wish. (There’s a possible race condition in there, but I think at that point we’re fully in “theoretical issues nobody will ever encounter in practice” territory ^^)

What do y’all think?

[andreimatei]

it would be ideal if dbus had some notion of optional parameters (so you could call either activateByPrefix('Firefox') or activateByPrefix('Firefox', 'last'))

Have you considered perhaps having different functions, one of which takes more arguments? I would definitely support any way of getting the window that last had focused; I wouldn't have cared how ugly the script is, as long as there was a script I could copy-paste from the project's readme.

I have switched to using this utility, fwiw, which works how I want it (brings up the last-focused window) - https://github.com/Soft/run-or-raise. Perhaps you can see what it does.

[lucaswerkmeister]

Have you considered perhaps having different functions, one of which takes more arguments?

I have, but I basically dismissed that option immediately (without even mentioning it above) because it would mean doubling the number of methods (going from 6 to 12), and it would scale even worse if I ever wanted to add more options.

I have switched to using this utility, fwiw, which works how I want it (brings up the last-focused window) - https://github.com/Soft/run-or-raise. Perhaps you can see what it does.

It looks like it only works on X? (But I’ve only taken a very cursory look at it.)

[lucaswerkmeister]

At the moment, it seems to always focus on the same window - I think the first window to have been created.

Well, it selects the first window in the list returned by GNOME that matches the condition – I guess GNOME’s list is sorted by when the windows were created or something.

Testing it a bit more thoroughly now (under GNOME 46), I think it’s actually returning the windows ordered by when you interacted with them, with the least-recently-interacted window first? (Which would be the exact opposite of what you want.)

[lucaswerkmeister]

We could introduce a method to change the sort order for all subsequent calls, but that’s a form of global state which can cause other problems…

Maybe we should just go for this, to be honest. It’s not super nice, but perhaps it still beats not having the ability to choose the sort order at all.

I suppose the sort order setter could even return the previous sort order, so that you can temporarily set the sort order, select a window, and restore the previous sort order, in one batch of commands, if you wish. (There’s a possible race condition in there, but I think at that point we’re fully in “theoretical issues nobody will ever encounter in practice” territory ^^)

What do y’all think?

Alright, version 9 of the extension (just pushed to extensions.gnome.org and hopefully approved soon) implements this. You should be able to get the behavior you want by calling:

busctl --user call \
    org.gnome.Shell \
    /de/lucaswerkmeister/ActivateWindowByTitle \
    de.lucaswerkmeister.ActivateWindowByTitle \
    setSortOrder \
    s 'highest_user_time'

See the README for details. (And note that the sort order isn’t persisted across sessions, so you’ll probably want to add that setSortOrder call somewhere in your shell startup sequence, or in whichever command you use to call the other activate methods.)