Jump to content

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


Recommended Posts

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.

 

When reporting issues, please include your exact installed versions of:

  • The Workflow.
  • Alfred.
  • macOS.

In addition to:

  • The debugger output. Perform the failing action, click “Copy” on the top right and paste it here.
  • Details on what you did, what happened, and what you expected to happen. A short video of the steps with the debugger open may help to find the problem faster.

Thank you. Accurate and thorough information is crucial for a proper diagnosis which allows me to help you better.

Link to comment
  • 3 months later...

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.

Link to comment
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.

Link to comment
  • 4 weeks later...
  • 2 months later...

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 by TomBenz
Link to comment
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.

Link to comment
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.

Link to comment

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.

Link to comment
  • 1 month later...

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.

 

Link to comment

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.

Link to comment
  • 1 month later...
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.

Link to comment

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.

image.thumb.png.c5eaf8a897021c25c58fe1895b7d3f3b.png

Edited by sepulchra
Link to comment

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.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...