Go To Here

[sepulchra]

@paulw I hope you don't mind continued engagement and feedback. This is an incredibly useful workflow. When I run the updated worklfow the applescript always returns "false" when a save dialog is present. I'm sure Vitor will have other feedback as well.

[paulw]

12 hours ago, TomBenz said:

Go to here shortcut working for MS excel, word etc in open dialog but not in save. Is opt + command + G valid shortcut in save dialog as it does work for me? I checked for conflicting keyboard shortcut shortcut on my machine using Aalpha workflow. Request you to please check this 

 

3 hours ago, sepulchra said:

@paulw I hope you don't mind continued engagement and feedback. This is an incredibly useful workflow. When I run the updated worklfow the applescript always returns "false" when a save dialog is present. I'm sure Vitor will have other feedback as well.

 

Not at all, it's been fun to tinker with this and I'm open to the feedback.

 

I updated the applescript to hopefully handle the Save dialogs not working. I also noticed that the previous applescript didn't always detect Open dialogs either. Now it attempts to cycle through windows of the application. “Save” dialogs are detected with an accessibility description property of "save". “Open” dialogs don’t have this property, so detecting them depends on a window name proprety of “Open”. I’m not sure whether either the accessibility description or the window name property changes when a user’s MacOS language settings are non-English.

 

If anyone is using MacOS with non-English language settings, perhaps you could let me know if the latest workflow fails to detect Open/Save dialogs.

 

Here's a new version: https://github.com/paulrudy/alfred-go-to-here/releases/tag/v2.0.2

 

 

[sepulchra]

@paulw unfortunately, it is still coming up false every time. Sadly, i don't know enough about applescript to help out more. This is where Vitor will be a bigger help than me but here to help regardless.

 

 

[paulw]

10 minutes ago, sepulchra said:

 unfortunately, it is still coming up false every time. Sadly, i don't know enough about applescript to help out more. This is where Vitor will be a bigger help than me but here to help regardless.

 

I only tested it in a couple of apps (TextEdit, Orion). It looks like it doesn't work in save dialogs in Safari, or anything in Brave. What apps were you trying it with?

 

Clearly there are lots of inconsistent behaviors about what properties the Open/Save dialog windows have between different apps. I'll see if I can create a little more of a comprehensive test. If it becomes too annoying, I'll just go back to what the original was, which just basically fell back to looking for any old window in the frontmost app.

Edited June 9 by paulw

[sepulchra]

Safari was my test but just tested TextEdit and that failed as well. I'm on 14.5.

 

 

 

 

[paulw]

That's strange. Does it fail on both open and save in TextEdit? And Safari?

[sepulchra]

you know what, chalk it up to "operator error." TextEdit just work fine on Open and Save.

[paulw]

1 hour ago, sepulchra said:

you know what, chalk it up to "operator error." TextEdit just work fine on Open and Save.

 

I've updated the workflow with a less strict script that seems to work in Safari and Brave, among others.

 

https://github.com/paulrudy/alfred-go-to-here/releases/tag/v2.0.4

 

The dirty details:

 

It looks like the Open and Save dialogs have different identifying properties depending on the app. Sometimes the dialog is a window with a name (like “Open”). Sometimes the dialog is a sheet attached to a window, and usually the sheet has an accessibility description property like “save” or “open”. With all that, I was able to get Brave’s Open and Save dialogs detected.

But Safari’s Save dialog sheet doesn’t have any identifying properties that i can find. So I simplified the applescript to look only for a window with sheet property or with Open name. Now I see why the original script borrowed from a Quicksilver plugin was so broad. There are a lot of inconsistencies.

 

So for particular feature (detecting whether there's an Open/Save dialog), please let me know if:

• the updated workflow doesn't work for certain apps
• there are issues with "Open" dialogs not working for users whose MacOS isn't in English

 

If so, it's probably better just to drop the applescript check. Worst case scenario would be that the workflow tries to paste a path and do its keyboard shortcuts where it's not supposed to.

Edited June 9 by paulw
updated link

[paulw]

minor update: https://github.com/paulrudy/alfred-go-to-here/releases/tag/v2.0.5

[sepulchra]

43 minutes ago, paulw said:

 

 

So for particular feature (detecting whether there's an Open/Save dialog), please let me know if:

• the updated workflow doesn't work for certain apps
• there are issues with "Open" dialogs not working for users whose MacOS isn't in English

 

If so, it's probably better just to drop the applescript check. Worst case scenario would be that the workflow tries to paste a path and do its keyboard shortcuts where it's not supposed to.

 

Will report back. If you plan on sharing it widely, it might make sense to drop it if it can't be consistent. Also, I can't imagine ever invoking it unless I had a dialog open but I'm just one user!

 

Edited June 10 by sepulchra
typos

[jwrc]

Using this script filter:

tell application "Finder"
    set windowList to windows
    set resultList to {}
    repeat with i from 1 to count of windowList
        set windowItem to item i of windowList
        set windowName to name of target of windowItem
        set windowPath to POSIX path of (target of windowItem as alias)
        set end of resultList to {windowName, windowPath}
    end repeat
end tell

set output to ""
repeat with i from 1 to count of resultList
    set windowItem to item i of resultList
    set windowName to item 1 of windowItem
    set windowPath to item 2 of windowItem
    set output to output & "{ \"uid\": \"" & i & "\", \"title\": \"" & windowName & "\", \"arg\": \"" & windowPath & "\" },"
end repeat

if output is not "" then
    set output to text 1 thru -2 of output
end if

set alfredJSON to "{ \"items\": [" & output & "] }"
return alfredJSON

 

Running to bash script

echo "$1"

 

Connected to "save current clipboard" in paul's script to select from open finder windows. Really liking the functionality of this, thanks for bringing it back Paul.

[paulw]

@jwrc Thanks for this example and suggestion. I'm not familiar with working with script filters, so I have a few questions:

 

How do you use the "running to bash script" portion of what you shared? For me, the script filter code as you shared it works fine by itself, pasted into a Script Filter input as an AppleScript.

 

I think I understand—you're using it as a separate workflow, connecting it as an external trigger to the "Go to Here" workflow. If that's true, there's nothing stopping the Script Filter from being integrated as an input within this workflow, correct?

 

Why do you have it connected to "save current clipboard" rather than the first item, "save basepath"? Is that just because you don't need/want the clipboard restore and is-this-an-open/save-dialog steps?

 

Would you mind if I integrate your code into the workflow?

Edited June 10 by paulw

[TomBenz]

16 hours ago, paulw said:

minor update: https://github.com/paulrudy/alfred-go-to-here/releases/tag/v2.0.5

  I am testing it with Microsoft Office - Excel, word and seems to be working better now. It is good to learn cmd + shift + g shortcut also

[paulw]

Also curious if anyone has suggestions for reducing the number of keywords needed to access the various input options. List Filter, File Filter, and (experimenting with) Script Filter all have unique keywords. I could set all of their keywords to be identical, but then depending on the number of items in the List Filter and/or Script Filter, the list of items to select from in Alfred might become annoyingly long—plus an extra step to choose one method over another.

[jwrc]

@paulw you can go ahead and integrate the script filter into the workflow, no credit needed.
 

I had an issue with my first script using basepath for frontmost finder window so just skipped it when I cobbled this together. Didn’t test it too much further to be honest.

[paulw]

I've spun off a new topic, so when I update the workflow, I can just edit the first post.

 

New workflow version 2.1.0 is there. As of now, integrates the Script Filter shared by @jwrc, adds configurable keywords, and a couple of other small changes.

[Paliz]

Can some explain this workflow? I thought this was built in to Alfred: I can search a file, then press right arrow and select Reveal in Finder.

[sepulchra]

@Paliz this is for selecting a location for a file while a save dialog is on the screen. if you open a text edit file and initiate a "save as" and then run the workflow that should show you how it works.

[Paliz]

1 hour ago, sepulchra said:

@Paliz this is for selecting a location for a file while a save dialog is on the screen. if you open a text edit file and initiate a "save as" and then run the workflow that should show you how it works.

Thank you! Your comment should be the main app description  

[paulw]

3 hours ago, Paliz said:

5 hours ago, sepulchra said:

 

Thank you! Your comment should be the main app description  

See the new topic for the updated version (with description)