vitor

Seems like it’s been fixed! Great news. Marking as solved.

I was saying that in this particular case the Github route is a better bet. Precisely because there’s no forum thread, there’s no guarantee anyone on these forums uses that Workflow, so you’re banking on the eventuality that: Users of that Workflow frequent the forum. They will see this thread (whose visibility will decrease over time). Will have the skills to help. Will have the availability to help. Will want to help. All of those need to be true. Alternatively, you could still have all those points but replace the first with two others: Someone who doesn’t use the Workflow but wants to take a stab at the problem. They can reproduce your problem. But even that second user (which sometimes is me) would rather have a response (or lack thereof) from the code’s author before committing time to debug foreign code. On the other hand, if you go to the Github page (good job posting it, that was useful for us to know what’s being talked about), you’re right at the source. A Github issue and a comment on the original forum thread have roughly the same chance of success. In this case there’s no original forum thread, but there is a Github repository and the Workflow’s author has been active on Github this month. As I mentioned on the original post, it’s all about increasing your chance of getting it fixed.

Hello @romebot, When making a request or a bug report pertaining to a specific workflow, please do not open a new thread to discuss your issue. Making a new thread, while it seems like it’ll give your problem visibility, will only fragment the discussion and make it less likely the author and users of the workflow (the people that can actually help) will see it. Please read the Reporting Problems with Workflows topic, as it gives a nice overview on how to make a report with a better chance of being addressed. You best bet here would be to contact the developer on Github, as they seem to be responsive.

Welcome @Philip Dhingra, Have you tried the troubleshooting steps?

It happens in the background after you action it. You don’t need to do anything else. Not in Firefox, because it doesn’t support AppleScript. If the bug tracking that omission were a person, it would be old enough to vote. If you want that to be changed, make your voice heard on that page. If you need any kind of outside automation from your browser, you’ll have to ditch Firefox. It should work in almost every other browser, though, because Firefox is the only major browser that doesn’t support AppleScript (many of the small ones support it as well, because they get it for free from Chromium). Most browsers have a variant of the option now. Not Firefox, for the reason mentioned above.

Welcome @tomliv, Tip when debugging: never say you’re on the the “latest”, but always the exact version (like you did with iTerm2). When you say “latest” we don’t know if you mean the latest beta or stable version, nor do we know if you’re actually on the newest version. You may think you’re up to date but be mistaken, or might be a version behind because the auto-update hasn’t kicked yet, or we may not be on what we think is the latest version but isn’t, or a multitude of other reasons. It also does not help someone who comes later with the same issue, as they’ll have no idea if their version matches yours. But as to your question, this should work (it’s the code I use). Stick it in Alfred Preferences → Features → Terminal, with Application set to Custom: on alfred_script(q) if application "iTerm2" is running or application "iTerm" is running then run script " on run {q} tell application \"iTerm\" activate try select first window set nowindows to false on error create window with default profile select first window set nowindows to true end try tell the first window if nowindows is false then create tab with default profile end if tell current session to write text q end tell end tell end run " with parameters {q} else run script " on run {q} tell application \"iTerm\" activate try select first window on error create window with default profile select first window end try tell the first window tell current session to write text q end tell end tell end run " with parameters {q} end if end alfred_script

Update. Update video download to new DownMedia. 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. Update video download to new DownMedia. 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. Update video download to new DownMedia. 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.

Major Update. Changed name to DownMedia. Instead of a single dv option for video and audio, now there are separate dv and da. In addition to downloading the clipboard URL, added an option to download the URL from the frontmost browser tab. Enhanced checks: if no URL is available, even in the clipboard, download can’t be actioned. dvp to see the progress has been changed to dp. Interface has received modifications in general, regarding how information is presented. There’s no longer a separate DownVid + WatchList option. There is instead a add_to_watchlist Workflow Environment Variable that controls the default behaviour (toggle on a case-by-case basis with ⌥). External Triggers have been modified to only take a URL as argument. External Triggers have more descriptive names. Added a Hotkey to auto-download the URL from the frontmost tab. Services have been updated to reflect the new options. Removed watchlist_download_dir Workflow Environment Variable, since that can be handled by the latter’s move_on_add. Check the top post for a streamlined view (with screenshots) of the new behaviour. To update, download the latest version (new URL) or wait a few days and it’ll prompt you to on next usage, since it uses OneUpdater. If after a week an update hasn’t triggered, please let me know.

Welcome @FelixLee, For licensing questions—which often deal with private information—the best method is the email address at the bottom of the contact page.

Another way: connect a Hotkey Trigger (with Argument set to Selection in macOS) to a Copy to Clipboard Output (with Automatically paste to front most app ticked and the text box set to: [b]{query}[/b]

I seem to recall this having been discussed/requested previously, but a quick search isn’t turning up the post. I don’t remember if it was a proper feature suggestion or a post in passing.

@nrebrikov Download the latest version (just released) and try again.

The suggestion here seems to be that we’d be able to configure the message for when no results are returned. While I’d welcome that, I’ll also point out I don’t find it a dealbreaker—a generic No results found for “{query}” would suffice. I do think showing the {query} in the message is a must, so the user is certain what they typed has finished running. I’m of the reverse opinion. Showing a message when the Workflow was successful but returned no matches is clear: do something else. Showing nothing can always be interpreted as an error, even if you know there’s error handling. I’m not saying I think the option to show a result on error isn’t useful—it is. My point is that if we could only have one, I wouldn’t pick that. That’s a good point that I hadn’t considered (I don’t use fallback searches). That said, I wouldn’t change my method anyway because like you I consider the clarity of “there were no results” to be worth the tradeoff. Adding the show x result for no results option could fix that, because if Alfred knows there are no results, it can show both “No results found” and the fallback searches. If it does show both cases or only one—at the Workflow developer’s discretion by ticking that box—I have no strong opinion.

Unfortunately, I’m unable to reproduce. It’s working fine for me.

What’s the behaviour now? Presumably that situation is already possible, except that with the current system it would happen more often because having the same shortcut is always a conflict, while with the suggested change it might not be (if they focus on different apps).

@nrebrikov Give me the correct name of the directory, so I can test.

Same here.

If your Keychain is locked, it will prompt you for your account password (to unlock the Keychain). If it is unlocked, it returns the password (or other information you request) without needing anything else. But it does require that you add your passwords beforehand, which is why I asked if it was an option. Examples, from PinPlus: To add the Pinboard token to the Keychain as a password (could also do it via the GUI): security add-generic-password -a <ACCOUNT NAME> -s 'Pinboard API Token' -w <TOKEN> To output the password (e.g. as input to a variable): security find-generic-password -s 'Pinboard API Token' -w To delete the entry: security delete-generic-password -s 'Pinboard API Token' Pinboard API Token in the examples could be anything, it’s a descriptor to interact with the specific entry.

Isn’t using the Keychain an option? You can save password there and read them back with the security CLI tool (bundled with macOS). It’s the method I use to save/read API keys in my Workflows.

I would bet a body part that it does. @deanishe cares about correctness and that’s too important a detail to leave out.

The definitely should. You could also make a case for having them in the Workflow’s Data directory (though I’d consider the Cache more appropriate), but the Workflow’s directory is the wrong place as it will sync with the Workflow, taking up more space in the user’s sync solution and getting overwritten when upgrading the Workflow.

@asphoa There you go. This alternative Workflow works by opening the search in the browser then switching to the app that was frontmost. It has the disadvantage that there’s a short “flash” of the browser’s window being brought to the front and then back, but it has a few advantages as well: it doesn’t depend on a browser’s AppleScript dictionary, so there’s no need to add permissions for it and will keep working even if the dictionary changes; works for any browser (even Firefox); if you change your default browser, no need to modify the Workflow.

On another note, I haven’t looked at the code but I don’t suppose your extension (or an extension) could bridge the gap with the missing AppleScript functionality to at least return the title and URL of the frontmost tab, could it?