vitor

On 3/1/2022 at 4:59 PM, Jasondm007 said:

It's easy to feed files to Alfred's "open with" file action, when done one at a time. I just can't figure out how to send more than one via script. Obviously, Alfred's able to do it, given that it's already accomplished when files are directly selected and triggered via hotkey.

Alfred is passing through the arguments, not path. The latter is like if you had set the value manually in the Action in Alfred, which is not what you’re looking for. Speaking of which, why not configure the object directly via the GUI instead of overwriting it via JSON? Action in Alfred is simple enough that if you’re feeling the need to override its configuration, you’re probably hiding extra complexity somewhere else. If you truly need different Action in Alfred configurations in the same Workflow, consider if multiple objects won’t be a simpler solution.

Anyway, to pass multiple arguments send them via an array in arg:

config = {
  "alfredworkflow" : {
    "arg": sys.argv[1:]
  }
}

The above assumes with input as argv, which you should use instead of with input as {query}. It uses from argument 1 to the end because in python argv[0] is the script itself.

Updates.

Removed support for the alternative app. It offered a slightly nicer-looking interface for adding bookmarks but in return it was bigger, slower, and used Electron which is constantly changing and part of an system rife with (security) issues. While it’s unlikely that would ever become a problem (due to the limited scope of the app), removing it entirely is a better bet. It didn’t have a tremendous amount of downloads either way, so I doubt it will be missed much.

In its stead, the default option to open the window directly in the browser is now marginally faster.

Also, the External Trigger for the launchd job has been replaced by an Inbound Configuration. If you used it, you don’t have to change anything.

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.

13 hours ago, giovanni said:

will be implemented at some point, please see here

Different thing. If I’m understanding correctly, you want to go directly to the Workflow’s preferences but @luckman212 wants to go directly to an object. Basically what ? already does but programmatically.

Sounds like the perfect use case for Universal Actions. Instead of futzing with a Keyword, you can act on the number directly from your clipboard history.

14 minutes ago, Matthias said:

If it would be possible, could you adapt this dict.cc workflow as well, please?

https://github.com/dennis-tra/alfred-dict.cc-workflow

Added.

Welcome to the forum.

Decided to deprecate the Workflow. It will keep working for the foreseeable future but I encourage a look at @Torrey’s Workflow which uses native macOS features and works nicely.

On 2/24/2022 at 6:54 PM, Earp said:

What does "add a 'file filter' object mean?  How do I go about doing that?

Right click anywhere on the Workflow canvas and do Inputs → File Filter.

16 minutes ago, Elalemanyo said:

Would it be possible to add alfred-repos? https://github.com/deanishe/alfred-repos

Added.

Welcome to the forums.

Update.

Added option to create and edit new empty note (or populated with Universal Action text) in one step. When using nadd, that’s now the default and ⌘↵ is the previous behaviour of using the clipboard.

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.

Whatever it is, if it’s causing a kernel panic it has to be a bug in Google Drive since it uses a kernel extension. I find several reports online of it causing kernel panics for others reasons.

The Workflow essentially lists files in directories and saves them to a cache for faster retrieval, it’s not doing anything which should be able to cause a crash on its own.

But if it has stumbled on the condition to trigger the bug, finding what that is would be useful to go around it and/or report it to Google.

The Workflow has thousands of downloads and I know multiple people use it for shared drives (common question) and this is only the second report. Both happening with shared drives may narrow it down. We need to figure out what specifically about your shared drives is atypical.

I don’t use Google Drive, so I’ll need clues. Why does your shared drive have that specific path? Usually people seem to have them all under /Volumes/GoogleDrive.

Do you have a GitHub account? I may need to ask for output of specific commands and IPBoard isn’t great for sharing large blocks of code. A GitHub issue would work better.

Thank you for the kind works.

For reference, this probably would have solved it:

brew uninstall php
brew install php@7.4
brew link php@7.4

40 minutes ago, dustingm said:

But whenever I include or attempt to index the Workplace drive

To be clear, are you scanning both drives or just the workplace drive? I’d be interested to know if the behaviour differs.

But before anything else, see if this version fixes it.

Yes, it is possible in several ways. For example with a Script Filter or leveraging Fallback Searches.

I’ve found several Alfred Workflows for Obsidian (shimmering-obsidian, obsidian-alfred). Have you given those a try?

1 hour ago, tachoknight said:

Is it possible to somehow get Alfred to just close when the esc key is pressed?

That’s how it works for me, I use it every day. It’s not a specific setting, that I recall, so something else running on your machine may be preventing the Esc from going through.
 

Alfred also closes with ⌘W or if you use its hotkey again. Do those work for you?

Also, what versions of Alfred and macOS are you on?

The Alfred 4.6 Released: Ready for macOS Monterey blog post has the answer:

Quote

One key difference with macOS Monterey is that PHP is no longer bundled by default.
If you install PHP (e.g. via homebrew), most PHP-based workflows will continue to work without an issue, as the workflow script objects in Alfred 4.6 have been updated to be aware of alternative bin paths. If the workflow developer has hard coded paths within their workflow, you'll need to seek out an updated version on our forum or the creator's site.

Essentially:

1. Open a terminal.
2. Install Homebrew.
3. Run brew install php.

4 hours ago, RobertF said:

Does anyone else sees this error a lot when they activate Alfred using its keyboard shortcut?  I see it a lot when I activate Alfred and type "open <filename>" in order to open a file.

First time that has ever come up, as far as I recall. Do you have a screenshot? What are your versions of Alfred and macOS?

4 hours ago, RobertF said:

I have a one year old M1 mac Mini running macOS Big Sur that has 16 GB of RAM.

Sounds like my setup. I’ve never seen Alfred take up a lot of RAM or CPU.

@alvint Getting somewhere. See if this version works for you.

38 minutes ago, NorahMaria said:

sorry, I did not realise this was the same issue!

No need to apologise, but perhaps help me understand what your steps were when you bumped into the new problem. What do you think stopped you from realising it was the same problem? Was the first explanation not clear enough for your mental model?

7 minutes ago, NorahMaria said:

I want some feedback in Alfred

You mean feedback in the debugger? That’s also easier in Zsh, append >&2 to your command to redirect STDOUT to STDERR: your_command >&2.

11 minutes ago, NorahMaria said:

and I know how to do that in NodeJS, if that makes sense!

It does, I understand you’re using what you know. But in this case the alternative is really simple (literally three characters) and superior in every regard. You had already done most of the work!

2 hours ago, NorahMaria said:

The error inside the Alfred debugger: stderr: zsh:1: command not found: npx

New to child_process in NodeJS, so I'm sure it's something obvious I'm missing!

That’s the same error, with the same cause and same solution. Use the full path to the tool.

And be sure to check what I linked you to if you still don’t understand the cause.

Your previous code was better. Zsh is ideal for this sequence of steps; switching to node needlessly complicates it and makes it less portable. You’re invoking a shell from your node code anyway, so the switch is all disadvantages.

What about this Workflow, does it work for you?

@Afoan

On 4/17/2013 at 12:26 AM, vitor said:

If you have an issue, follow the guide for an effective bug report.

Make a Run Script Action with default options and write killall 'APP_NAME' 'APP_NAME'. Example: killall 'Brave Browser' 'Safari'.

I’ll rephrase my request: please avoid posting serially. That muddles the discussion for everyone coming after and is annoying for the people who follow the thread, because they are constantly pinged. Today they will have received six emails from your replies, but no more than two were necessary. Remember this is a public forum, not a chat app. The goal is for everyone to be able to benefit from the questions and answers.

Impatience makes us miss important information. I don’t have access to you or your machine so I can only take guesses at what you’re doing wrong or what is odd about your setup. To get help, you need to be collected and think with me what about your setup is different from (literally) a few thousand people using this without your problem.

Have you checked the debugger? Have you tried :gdrebuildcache?

Again, have you followed the instructions in the previous post? Please try and reply to everything at once so we avoid unnecessary back and forth with the same questions. That muddles the discussion for everyone coming after and is annoying for the people who follow the thread.

After you run the command from the previous post, in the same Terminal run ls -lA and post the results.

5 hours ago, virpio said:

I first have to hit return for it to start showing the result

You don’t hit return to show the result, you do it to complete the keyword. Showing the result happens after that. It’s an important distinction.

5 hours ago, virpio said:

What I'd want is the original entry just showing "Open foobar from <path>" right away

You can’t, and that’s by design. Imagine if every Script Filter auto-ran with partial keywords: you’d have tons of Workflows running all the time by mistake, cluttering and slowing down your results.

You’re asking for things to run before they are called, which is impossible. If you need the Script Filter to trigger sooner, consider shortening its keyword.