vitor

When you ask Alfred to open a URL in the default browser, it essentially tells macOS “hey, open this”. It’s then macOS who passes it along to the right app, which handles it however it sees fit.

Try this: open a terminal and run open "https://example.com/". Which behaviour do you get? You’ll likely get the same as opening with Alfred, in which case the behaviour is not something Alfred can avoid.

If the behaviour is different with that command, however, please specify your exact steps in Alfred which are making you see that behaviour, in addition to your Alfred and macOS versions.

Welcome @Henriknet,

If I understood you correctly, you’re looking for https://www.ebay-kleinanzeigen.de/s-berlin/{query}/k0l3331. The way to figure this out is to complete a search with a dummy search term, then replace it with {query}. That can appear anywhere in the URL, it does not have to be at the end.

2 hours ago, lewis42 said:

It would be great to see menu items for the current app indexed/shown in the top level search results without the need for a modifier.

It’s not uncommon for people to want their favourite Workflow to show up in the default results. What the request tends to not take into account is how that would affect everyone else’s usage and Alfred’s performance. The choice of what shows up in the default results is very deliberate. It’s a set of predictable results which can always be retrieved fast.

It doesn’t matter if it’s a Workflow or an integrated feature, this feature depends on the open app and throws a bunch of results. It’s not predictable and would overwhelm the other entries, which most people wouldn’t want. Making it an optional feature wouldn’t work either, because by now Alfred would have dozens of toggles for each of those, all competing with each other.

If you want this Workflow as your default results:

1. Remove your Alfred hotkey.
2. Make a new empty Workflow.
3. Add a Hotkey Trigger. Set it to what was your Alfred hotkey.
4. Connect that to a Run Script Action, with Language /usr/bin/osascript (AppleScript). In the Script box write:
   

tell application id "com.runningwithcrayons.Alfred" to search "KEYWORD_HERE"
tell application "System Events" to keystroke "a" using {command down}

Replace KEYWORD_HERE with whatever keyword you want, and you’re set. Whenever you press your Hotkey, you’ll get this Workflow running and the text will be auto-selected so you can just type to search something else. If you don’t want the text to be selected, remove the second line from the Script.

9 hours ago, Rooter said:

do you think it will work with other virtual or network drives in general?

I know it does and that there are people using it like that. As long as you can see the files in the Finder, they should be accessible via this Workflow, just change the directory.

But like you pointed out, this was made with one specific case in mind. It is optimised for that and is not guaranteed with anything else, because I haven’t tested every other provider.

10 hours ago, lutefish said:

Would it be possible to add zothero? https://github.com/deanishe/zothero

Added.

23 hours ago, vitor said:

In the Run Script, add this line at the top: export PATH="/opt/homebrew/bin:/usr/local/bin:${PATH}"

You didn’t do that part. You’re not supposed to run the command, you add it to the script. Like so:

export PATH="/opt/homebrew/bin:/usr/local/bin:${PATH}"
php -f setup.php -- "{query}"

@Erik E Thank you for all the thanks! It’s rewarding to know it’s been a positive impact.

As to your new question, go into the code and replace instances of +%D with +%m/%d.

Change set command to to do shell script.

Again, please upload your Workflow. It’s not productive to keep shooting in the dark.

4 hours ago, Sententiosus said:

Where I can upload the workflow?

Try https://transfer.sh/

4 hours ago, Sententiosus said:

The selected interpreter is "/usr/local/bin/php"

That’s probably your issue. You’re trying to run the PHP interpreter inside the PHP interpreter. In the Run Script, add this line at the top: export PATH="/opt/homebrew/bin:/usr/local/bin:${PATH}" and make sure the interpreter is /bin/bash. That should fix it.

2 hours ago, Blacksmith said:

I can indeed see keywords listed under kMDItemKeywords.

Great! So Alfred will be able to search for those.

2 hours ago, Blacksmith said:

is this the only way to do this

This was only a quick way check if the data is there and searchable. Now that we know, you won’t have to repeat it.

2 hours ago, Blacksmith said:

can I achieve the same info by using a workflow

Yes, that’s the goal now! Specifically, you’ll use a File Filter.

The dynamic date placeholder doesn’t support that transformation; that would be too complex and it already does a ton as it is. You’ll need a little bit of code.

Make a Workflow and add a Snippet Trigger. Connect it to a Run Script Action with default settings and the following code: 

case "$(date +%A)" in
Thursday | Friday)
  date -v +4d +%D;;
Saturday)
  date -v +3d +%D;;
*)
  date -v +2d +%D;;
esac

Connect that to a Transform Utility set to Trim white space. Finally, connect that to a Copy to Clipboard Output (check Automatically paste to front most app). In it include your snippet text and use {query} where you want the date to show up.

Basically what the code does is check the current day of the week, then add four days to the current date if it’s Thursday or Friday, three days if it’s Saturday; two days any other day.

When asking for help with a Workflow, please upload it somewhere as we can’t properly help you without access to it. Debugging can already be hard with access to the code, even more so when all we have is a description.

8 minutes ago, CatsAndCoffee said:

in line 670, the workflow is trying to fetch currency data with `/usr/bin/python`

Missed that one. Now fixed the repo in the Workflow.

9 minutes ago, CatsAndCoffee said:

i fixed it by simply changing the path to my `/opt/homebrew/bin/python`.

Just python works and will avoid the same issue in the future (or if you install the Workflow on an Intel machine).

Adding that to the regular search would probably make it slower.

It’s the kind of thing which should be a Workflow instead, even if that means requiring a keyword. Here’s a Workflow which lists all running applications. Pressing ↵ on any will switch to it.

Welcome @Blacksmith,

8 hours ago, Blacksmith said:

want to know if Alfred can locate specific keywords located in the metadata in those JPG images

Probably yes, but it may depend on how the data is embedded. Here’s something you can try: run the troubleshooting to view file metadata and see if the information you want to search for is there. If it is, great! It means Spotlight indexes the data and Alfred can see it too.

If you don’t see what you’re looking for, it will probably still be doable (can only say for sure after examining a couple). It means understanding how the data is embedded and how it can be read, then making a Workflow for it. We can help with that too.

Update.

It will specifically not close the window on special actions.

To update, download the latest version (same URL) or wait a few days and it’ll prompt you to on next usage, since it uses OneUpdater.

Update.

Made some changes and fixes for it to run smoother. But in particular, what you might notice:

• Turning off will now only terminate itself. This means that if you have other caffeinate processes running from other entities, those will be left alone.
• When running again to turn it off, if you previously picked a time frame it will tell you when it’s predicted to auto-turn off. Keep in mind that due to the nature of how Apple’s own caffeinate measures its timeout, the time might be somewhat off.
• The shortcut for preventing the display from going to sleep changed from ⌥ to ⌘. 

To update, download the latest version (same URL) or wait a few days and it’ll prompt you to on next usage, since it uses OneUpdater.

Welcome @CatsAndCoffee

Can’t reproduce at all. Try downloading it again, it was updated recently.

11 hours ago, CatsAndCoffee said:

on an M1 Pro MacBook running Python 3 and monterey 12.3 (21E5206e)

It’s useful that you give the machine details, but the Python 3 part is irrelevant. For one, the point of these Workflows is that they have to use Python 2. If you haven’t followed the knowledge base article to install it, these won’t work. But no macOS machine comes with Python 3, so saying it’s running but not how it’s installed is insufficient information. Again, it doesn’t matter in this case, only pointing it out for future debugging.

20 minutes ago, DomS said:

think to switch on notification, perhaps it can help others

I cannot force notifications on users, nor would I want to. Permissions for notifications is something you have to control yourself, and that is a good thing.

17 hours ago, bo9 said:

I use both Safari and Chrome.

This makes the code more complex, because in addition to asking the browser to open the window now it also needs to know which browser to do it for. Make a Run Script Action with Language /usr/bin/osascript (JavaScript), and in Script, paste:

const frontmost_app_name = Application('System Events').applicationProcesses.where({ frontmost: true }).name()[0]
const frontmost_app = Application(frontmost_app_name)
frontmost_app.includeStandardAdditions = true

const chromium_variants = ['Google Chrome', 'Chromium', 'Opera', 'Vivaldi', 'Brave Browser', 'Microsoft Edge']
const webkit_variants = ['Safari', 'Webkit']

if (chromium_variants.some(app_name => frontmost_app_name.startsWith(app_name))) {
  frontmost_app.Window().make()
} else if (webkit_variants.some(app_name => frontmost_app_name.startsWith(app_name))) {
  frontmost_app.Document().make()
} else {
  throw new Error('You need a supported browser as your frontmost app')
}

function run(argv) { frontmost_app.openLocation(argv[0]) }

That takes in whatever URL you send from the previous object and opens it in a new tab in the frontmost browser app, whatever that is (again, not Firefox).

If you want it to open in a new tab and in a new window, use this instead:

function run(argv) { 
  const frontmost_app_name = Application('System Events').applicationProcesses.where({ frontmost: true }).name()[0]
  const frontmost_app = Application(frontmost_app_name)
frontmost_app.includeStandardAdditions = true

  const chromium_variants = ['Google Chrome', 'Chromium', 'Opera', 'Vivaldi', 'Brave Browser', 'Microsoft Edge']
  const webkit_variants = ['Safari', 'Webkit']

  if (chromium_variants.some(app_name => frontmost_app_name.startsWith(app_name))) {
    frontmost_app.openLocation(argv[0]) 
    frontmost_app.Window().make()
  } else if (webkit_variants.some(app_name => frontmost_app_name.startsWith(app_name))) {
    frontmost_app.openLocation(argv[0]) 
    frontmost_app.Document().make()
  } else {
    throw new Error('You need a supported browser as your frontmost app')
  }

  frontmost_app.openLocation(argv[0])
}

Here’s a Workflow for it.

The first thing to understand is that you can’t do this with the default custom searches, you must recreate the ones you want in a Workflow because you’ll need to run code to open the new browser window.

14 hours ago, bo9 said:

I’d like for that search result to open up in a new tab but also in a new browser window.

So you want it twice with one run?

12 hours ago, Donald786 said:

one unreadable file

It’s neither; it’s a directory you can freely inspect by right clicking then “Show Package Contents”.

You can just backup the workflows directory from there, but it’s bound to be the biggest one anyway; it makes sense to back up it all.

12 hours ago, Frand said:

Is it possible via a keyboard shortcut to open the most recent folder where a document is placed?

In theory yes, but in practice a blanket search like that delivers a lot of undesirable results, such as things in ~/Library generated by apps. Those searches work better when focused to specific directories, which is why it’s the solution I ended up with for RecentlyAdded.