windowfilter returns windows ordered by spaces

[strindberg]

If I have a windows filter which matches windows on several spaces, and then calls it as follows:

  windows = self.wf:getWindows(windowfilter.sortByFocusedLast)

the result is that the windows from the current space are returned (in reverse focus order) first, and then windows from other spaces.

This is quite unexpected and I have not found a way to work around it.

[cmsj]

I wonder if @lowne might come out of retirement to assist here :D

[lowne]

Sounds like (unfortunate but) expected behaviour at script (re)load, due to the usual Spaces limitations. However as you jump through spaces and focus different windows the correct order should be maintained; this may or may not be complicated by the "raise all windows" behaviour when switching to certain applications (not sure if/when that would trigger a "transient" focus event on all current-space windows).

[strindberg]

I cannot see that script reload would trigger this. If I keep the script stable and don't trigger a reload, then move between all spaces to make sure that all windows are picked up, I still see the behavior where window are consistently ordered in space order.

[lowne]

Just switching to all spaces (so that windowfilter "picks up" all the windows) isn't enough: windowfilter initially populates the per-window "timeFocused" field with os-provided (and spaces-unreliable) data; the field then gets updated (with correct data) as each window gets focused.

[lowne]

To be clear: to get the correct state you have to 1) switch to all spaces to pick up all the windows and then 2) focus each window once.

[strindberg]

Here's a way to reproduce what I see. I have this in my init.lua:

switcher = hs.window.switcher.new(hs.window.filter.new({'Firefox', 'Google Chrome', 'Safari'}))
hs.hotkey.bind('ctrl', '.', nil, function() switcher:next() end)

I put Safari on Space 2, and the other browsers on Space 1. I visit each application with regular command-tab.

Then I visit Safari (in Space 2), and then select Firefox (in Space 1). Then I hit ctrl-., and see the browsers in this order: Firefox, Chrome, Safari. Chrome is the selected one, since Firefox is current application. I would have expected Safari to be number 2 in this list, but instead it is placed last, which I assume is because it is on another space.

[lowne]

I tested the exact same windowfilter in same scenario (Safari and Chrome on space 1, Firefox on space 2), and :getWindows() shows them in the right order... 😕
However, I'm using a super old Hammerspoon (0.9.49) with a possibly even older windowfilter module (i.e. my local "original" that ended up in HS). So I tried with the latest HS release (.54) and indeed I can see the issue. Diffing window.filter doesn't show changes other than docstring reformatting... normally I'd guess some change in the dependencies is causing a regression, but I cannot imagine anything that would result in such an oddly specific behaviour. @cmsj does anything come to mind?

[lowne]

I should also note that I'm not in the best position to test, as running my local build (which is my "production" environment and cannot be touched as it's a mess of long forgotten symlinks) and release builds together makes Accessibility go insane. @strindberg can you check if .49 and/or earlier/later releases work for you?

[strindberg]

I see the same problem in 0.9.49, and in 0.9.46 as well, which seemed to be the first release with window.switcher included. In other words, the older releases also present the windows in the wrong order.

[lowne]

Hmm... try with wf:keepActive() (right after creating the windowfilter)

[strindberg]

Yes, that solved the problem for me. Setting 'keepActive()' on the windowfilter now makes the windows show up in the right order. Thank you!

Do you want me to close the issue? In other words: is this how it is supposed to work, or should something change in the way Hammerspoon sets up filter by default? I can't find the documentation for 'keepActive()' method anywhere, and I noticed that #1260 seems to be about the same problem.

[lowne]

Yeah, this is the "documentation" for keepActive():

keeps the wf in active mode even without subscriptions; 
used internally by other modules that rely on :getWindows
but do not necessarily :subscribe
(not documented as the passive vs active distinction should be abstracted away in the user api)

So 1. I didn't think of this particular use (maintaining inter-Spaces ordering) as it seems an edge case (but apparently not entirely uncommon since #1260 is an exact dupe) and 2. window.switcher should call it anyway.
OTOH, switcher apparently does not take care of it (didn't check the code tbh), plus I must have something in my symlink jungle that calls it - although that's most likely a side effect of something else rather than a statement of intent "make all windowfilters active no matter what".
Still I'm not sure the right solution is to somehow publicly document keepActive()...

[strindberg]

I would argue that this is not really an edge case: if I create a window switcher for switching between applications in recently-used order, is it not reasonable to expect that spaces have nothing to do with the order?

[lowne]

Yes, but that's a (separate) problem with switcher (which should be fixed); what I meant as an edge case is using a "bare" windowfilter's getWindows() in that way. Ideally there should be some heuristics in place where e.g. all windowfilters interested in Spaces (which is not necessarily all "spaces-aware" windowfilters) should be active; but that's not straightforward to implement.

[strindberg]

I see. I misunderstood your meaning. Out of curiosity: what is the disadvantage of keeping all window filters active? Is it expensive resource-wise?

[saagarjha]

@strindberg It looks like setting this causes Hammerspoon to freeze for 5-10 seconds after switching spaces once in a while–I guess it's trying to get a list of all the windows.