Window Switcher — Switch to a specific window of an app in the current Desktop Space

[vitor]

Usage

Search app windows in the current Desktop Space via the win keyword. ↩ to switch to the selection.

Configure the Hotkey for faster triggering.

⤓ Install on the Alfred Gallery | Source

 

Edited March 21 by vitor

[vitor]

Because it’s a frequently asked question, I’ll cover at the top that the workflow will not show windows which are hidden, minimised, or in another Desktop space. Those cannot be retrieved with current macOS APIs without a significant hit in performance, losing useful stacking order information, or showing a ton of irrelevant non-app windows. The workflow specifically moved away from those tradeoffs.

 

The workflow continues to be maintained and will get relevant tweaks, but it should be considered feature complete.

 

[privateName]

Hi Vitor.

 

It seems like not working on latest Monterey 12.3.1. Getting the following error:

 

[11:40:34.724] ERROR: Window Switcher[Script Filter] Code 1: /Users/privateName/Library/Caches/com.runningwithcrayons.Alfred/Workflow Scripts/8D2673B3-AA22-4E41-A8BE-863A4D2FE4B8: execution error: Error: Error: osascript is not allowed assistive access. (-25211)

 

Alfred and osascript have the accessibility permissions. Have any ideas on how to fix?

 

Thanks.

[vitor]

2 hours ago, privateName said:

Alfred and osascript have the accessibility permissions.

It can look like it but not be the case. macOS updates sometimes break those. Remove the permissions and grant them again.

[xilopaint]

It’s not working for me. I can only see the frontmost window/tab listed and sometimes an "Unnamed" window. Btw, how this workflow differs from the faster Swift Windows Switcher?

Edited April 9, 2022 by xilopaint

[vitor]

14 hours ago, xilopaint said:

It’s not working for me. I can only see the frontmost window/tab listed and sometimes an "Unnamed" window.

 

That’s insufficient information to debug. You haven’t shared what you’re getting (no idea which apps are open) or what you expected to get, or what exactly is open. From your description alone, it seems to be working as intended.

 

14 hours ago, xilopaint said:

Btw, how this workflow differs from the faster Swift Windows Switcher?

 

A cursory glance reveals that Workflow is unmaintained, has open issues, requests more permissions, and requires users to bypass the unsigned binary. But I had no idea it existed, so can’t comment on functionality. Naturally you should use whichever you prefer, it’s a good thing that people share their different approaches. It is a fair point that the Workflow is slower than could be. I’m aware of that and do have plans (and code) to address it, but no ETA yet.

[xilopaint]

Now I can see that I get different results depending on whether or not I invoke the workflow with a maximized window as the frontmost. Is that intended behavior?

[vitor]

9 hours ago, xilopaint said:

Is that intended behavior?

Yes:

 

On 12/8/2021 at 4:33 PM, vitor said:

show app windows in the current Desktop Space.

When changing APIs to speed it up, that may change.

[privateName]

On 4/8/2022 at 2:35 PM, vitor said:

It can look like it but not be the case. macOS updates sometimes break those. Remove the permissions and grant them again.

It helped, thanks.

[vitor]

Updated to 2022.3.

Add configurable keyword.

[TomBenz]

This is good.

 

Is it possible to add a universal text search in the script editor so that one can do context based help? For example in AppleScript for MS word, right click "header" and get to word dictionary with items related to it? will this need GUI scripting to achieve? 

Edited October 9, 2022 by TomBenz

[vitor]

1 hour ago, TomBenz said:

so that one can content related help?

I don’t understand your question.

 

1 hour ago, TomBenz said:

For example in AppleScript for MS word

I think I’ve mentioned this before, but I don’t use Word. Examples based on it don’t clarify.

 

1 hour ago, TomBenz said:

right click header and get to word dictionary with items related to it? will this need GUI scripting to achieve? 

If you need right-clicking and interacting with it, you need GUI scripting.

[TomBenz]

1 hour ago, vitor said:

I don’t understand your question.

 

I think I’ve mentioned this before, but I don’t use Word. Examples based on it don’t clarify.

 

If you need right-clicking and interacting with it, you need GUI scripting.

 

Sorry. I meant Context based help -- something similar to F1 help in vba. MS word is just used as example. It is same request for textedit, contact AppleScript dictionary etc.

[vitor]

I still don’t get what you’re asking. This workflow is for switching windows, it has nothing do with help. Maybe you’re looking for menu bar search? If you you’re looking to switch to windows based on their content, not only is that unfeasible in most cases and require apps to be added individually, it would be unbearably slow.

[SuupaPro]

Hello,

 

loving this workflow so far!

I would like to ask if there is any chance to make it kind of default option without typing keyword? I know that I can change the keyword but when I try to put it as an empty field it is being changed to win automatically. I would to get open windows simply when i press cmd+space to bring up Alfred.

 

[vitor]

@SuupaPro See:

 

[vitor]

Updated to 2023.1.

• Rewritten in Swift for a massive speed boost.
• Show windows in stacking order.
• Improved messaging when no windows found.
• Improved handling of Unnamed windows.
  

You can download the update on GitHub. It’s not yet live on the Gallery as I’d like some feedback. If you’re on Big Sur or Monterey, please give it a spin and let me know if raising the window works.

Also pinging @xilopaint, as we’ve discussed the speed before.

[xilopaint]

7 hours ago, vitor said:

Also pinging @xilopaint, as we’ve discussed the speed before.

 

Much better now. Thanks!

[sepulchra]

Massive speed boost in an understatement! This is great.

[vitor]

I’ve also gotten reports that this works fine on Monterey, so it’s now live in the Gallery and can be updated from inside Alfred.

[xilopaint]

@vitor, would it be possible to also make this work with tabs through a different keyword?

[vitor]

Not really. Tabs are a whole different thing and they depend on the target application (as opposed to windows, which can be generically queried by the OS).

[xilopaint]

2 minutes ago, vitor said:

Not really. Tabs are a whole different thing and they depend on the target application (as opposed to windows, which can be generically queried by the OS).

 

hmmm, I assumed it was possible because it's the approach of the nice Swift Windows Switcher workflow. Looking at it more closely, I now realize that it seems to use AppleScript for the tabs.

[sepulchra]

Not critical at all but one behavior i'm seeing with Safari, the alfredforum, and this workflow. When a forum tab is front most or is the only tab the Alfred shows two windows "Unamed" and the window with the description. I'm currently only seeing this with the forum but haven't tried this extensively. Also when Safari is not the frontmost app Unnamed does not appear in the list.

Edited May 21 by sepulchra

[vitor]

It’s not related to the forum but (likely) to the status bar that shows up on the bottom left corner when hovering over a link. Annoyingly that’s also treated as a window like the others. I can’t just exclude all unnamed windows because some apps have legitimate windows with no title. One option would be to exclude all windows below a certain height (are there legitimate windows one would want to switch to that are under 20px in size?). I may end up doing that in the next update, I’ll have a quick think about it.