vitor

3 hours ago, Alan He said:

If so, I will consider whether there is a way by AppleScript.

There is, just looked into it:

Application("Finder").select( [ Path("/ONE/PATH/HERE"), Path("/ANOTHER_PATH/HERE") ] )

Then that settles it, it’s not due to the hidden directory flag.

That’s the way macOS does it. Try it in a Terminal:

open -R /some/path /another/path

open -R means Reveals the file(s) in the Finder instead of opening them. (see man -P 'less --pattern "^     -R"' open).

As you’ll see, even if you give multiple paths, it will only reveal one.

16 minutes ago, Alan He said:

I think because of ~/Library is hidden folder. 

 

So the question now becomes how to search for files in hidden folders.

You’re jumping to conclusions. Hidden directories simply have a set attribute to make them invisible in the Finder, it affects nothing else.

While it is possible the hidden flag could play a role—e.g. if Alfred deliberately chose to ignore those—you can’t extrapolate from a single data point.

The next step isn’t to figure out how to search in hidden directories, but if hidden directories play a role at all. Try it: chflags hidden PATH_HERE (do the same command with nohidden to revert). If Alfred finds files inside that directory (which it should, I just tried it), then that’s not the problem.

This looks the same as 

Could you provide the information and follow the steps requested by @Vero?

Making Keywords context sensitive is trickier than for Hotkeys. Invoking Alfred and typing only not to see some results could be confusing and lead to unnecessary bug reports. Prioritising Keywords depending on context might be best, but may not fit with Alfred’s learning.

Right now, there’s two ways to achieve what you want:

The first is to have multiple Keywords with the same text. At the time, you chose the relevant one (a good icon will help there).

The other requires a couple of objects:

1. Make a Keyword Input.
2. Connect it to a Run Script Action with Language set to /bin/bash and Script set to osascript -e 'tell application "System Events" to return name of first process whose frontmost is true' | tr -d '\n'. This will return the name of the frontmost app.
3. Connect that to a Conditional Utility and set is equal to to the names of the apps you want to affect.
4. Then connect those to the appropriate actions.
   

If your Keyword takes input, you may have to add an Argument and Variables Utility in there to save it.

4 hours ago, Zenn said:

I don't think line-height should be considered an intrinsic property of the font, as it is part of CSS as well as iOS font styling.

I should’ve used the correct terminology before. Line height is formally known as leading. It controls the distance between lines, not the font’s height (which is what influences the caret). That you shouldn’t touch and you can’t mess with it with CSS unless you use scale to distort the characters. Font height is the purview of the typeface designer and has been an intrinsic part of typography from the times we manually arranged metal blocks and rolled them with ink.

But I agree your caret looks abnormally large. You’re using the System font, right? I tested it on my machine and the caret doesn’t look as tall as yours. Could you share your theme?

Welcome @Ahess97,

In bash you access variables with ${var}, not {var}. Also, you’re calling bc but doing nothing with it, as if you were calling it interactively in a Terminal. This being a script, you need to give your data as the input to bc. Use <<< to feed data, or < to feed a file. Meaning what you want is:

bc -l <<< "(((${nps11}+${nps10})-(${nps7}+${nps6}+${nps5}+${nps4}+${nps3}+${nps2}+${nps1}))/(${nps11}+${nps10}+${nps9}+${nps8}+${nps7}+${nps6}+${nps5}+${nps4}+${nps3}+${nps2}+${nps1}))*100"

2 hours ago, Chris Messina said:

Try using the Alfred Keywords Workflow. Just enter ? And the name of the action and you will see a list of available actions.

Alfred does that by default, no need for a Workflow. Plus you can go more generic with ?keywords or ?hotkeys to show all available corresponding triggers. That’s a tip at the top of the Alfred Cheatsheet.

1 hour ago, deanishe said:

If macOS can't contact the server to check the hash, it just lets the app run.

I’m thinking something like (from the linked article):

Quote

When an Apple device can't connect to the network but you want to launch an app anyway, the notarization validation is supposed to "soft fail"—that is, your Apple device is supposed to recognize you're not online and allow the app to launch anyway. However, due to the nature of whatever happened today, calls to the server appeared to simply hang instead of soft-failing. This is possibly because everyone's device could still do a DNS lookup on ocsp.apple.com without any problems, leading the devices to believe that if they could do a DNS lookup, they should be able to connect to the OCSP service. So they tried—and timed out.

Maybe Little Snitch isn’t outright blocking it, but leaving it “on hold” (like when asking you to approve or deny).

2 hours ago, deanishe said:

Then again, my info is Catalina vintage. It's possible they've made it even more stupid since then. 

I think they have changed it, but I haven’t checked what’s the new behaviour.

10 hours ago, maxp said:

I've tried eliminating the ones that are easy to quit (ie, not Little Snitch)

Last year there was a global macOS app launch slowness caused by trouble accessing the notarization servers, so any app that can mess with network requests is what I’d check first.

It being intermittent could be explained by the times it does the network check or not. It would also explain why a reboot doesn’t fix it but a new user account does.

32 minutes ago, maxp said:

both in Alfred and generally.

Then it is not caused by Alfred. What Alfred does in the situations you described is essentially tell macOS “hey, open this” and then it’s out of its hands. In other words, if launching things is slow in general they will also be slow to launch via Alfred because it’s the same mechanism.

What other tools do you have running in the background (e.g. BetterTouchTool)?

Have you tried creating a new user account and see if the slowness is there? If it is, the issue will be either with your macOS installation or the physical machine. But if the new user account behaves correctly, you’ll know the cause is something specific in your setup. Then you just start disabling things until it no longer happens (meaning you found the cause).

WebScreenshot has a savescreenshotclipboard command which gets you close to what you ask, though it always saves to the Desktop. It’s leveraging pngpaste to do it, in case you want to build your own solution. The image data will need to be at the top of your clipboard history since (as you noticed) those don’t trigger the Universal Actions pane.

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.

Usage

Search app windows in the current Desktop Space via the win keyword.

• ↩ Bring window to the front.
• ⌘↩ Quit app.
  

Configure the Hotkey for faster triggering.

⤓ Install on the Alfred Gallery | Source

13 minutes ago, ileonemil said:

Okay I downloaded yt-dlp by curl

That won’t work. If it were that simple, that’s what I would’ve done in the Workflow. That’s also explained in the quoted text.

Installing via Homebrew is the only method I support.

The debugger message you just posted explains the issue in plain English. The top post expands:
 

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

You will have to install yt-dlp yourself because it has dependencies which are impractical to fulfil on a clean macOS installation. The simplest way is to install Homebrew and brew install yt-dlp.

Those instructions are also in the About section of the Workflow itself. It’s important to read those.

16 hours ago, kaspertik said:

I cannot figure out how to use this Output label in my following Open URL action.

You don’t; it is just what it says, a label. The output of the conditional is the {query} that entered it.

@ileonemil Please follow these instructions, as the first pot asks. 

If you ever find the cause and/or a solution, I’d still encourage you to post in this thread as followup. The thread already exists and is probably indexed by search engines anyway, so it may provide help to someone else in the future, Alfred user or not.

Do you have WatchList installed? It’s probably doing the move to the directory you have set there. The instructions and top post explain that.

What you’re looking for is ?snippets. Type ? followed by a preference tab name, and ↵ will take you there.

10 hours ago, eh5 said:

is this an Apple AppleScript issue moving forward, Alfred interaction with macOS or something I don't understand?

There’s nothing preventing future interaction between Alfred and AppleScript, no.

10 hours ago, eh5 said:

I saw a prompt saying this featured would be disabled and I need to contact the developer. I didn't capture the warning message, sorry.

Screenshot it if it comes up again. Seeing the exact prompt or knowing the exact message it’s important to understand it.

3 hours ago, alnetloc said:

tell application "System Events" delay 0.5 key code 36

When @deanishe mentioned adding the delay before the key code, he didn’t mean literally in the same line but above it:

tell application id "com.runningwithcrayons.Alfred" to search "clear"

delay 0.5

tell application "System Events" to key code 36

In addition to what Dean asked, it isn’t clear if you tried running your code in Script Editor.

As another data point, I’m on ARM and Monterey and your code is fast for me, both in Script Editor and Alfred.