deanishe

I'd love to see the ability for workflows to programatically re-run themselves as and when necessary (e.g. via tell application "Alfred 3" to rerun). This is another reason that workflows call themselves via AppleScript (and what prompted me to ask for the keyword in envvars above, as they're related in my mind). It's very common for Script Filters to show a locally-cached copy of the data from an application/webservice and update the cache in a separate process. It'd be great if that separate process could tell Alfred to re-run the Script Filter if the cached data have changed. "Re-run every X seconds" would broadly suck for this, as few Script Filters that aren't written in compiled languages run fast enough for it not to be very obvious to (and annoying for) the user when they reload. Reloading once if and when there are fresh data is good. Reloading every few seconds just in case there are, not so much.

In exactly the same way you'd put a newline in any text. If you post your code, we can tell you how to fix it.

Don't think it's relevant here, but FWIW, as far as clicking items in the menubar goes, the application itself doesn't need to support AppleScript, as this is one of those things, like activate or open, that's handled by the system (System Events does the menu clicking thing). It even works on non-native apps, like Sublime or Atom, as these still use the native menu system under the hood. For example, here's how to show Sublime's console: tell application "Sublime Text" activate end tell tell application "System Events" tell process "Sublime Text" tell menu bar 1 tell menu bar item "View" tell menu "View" click menu item "Show Console" end tell end tell end tell end tell end tell The major issue with this technique, imo, is that it's tied to a specific language, by which I mean English, not AppleScript.

Is anyone still using Alfred 2?

FWIW, if you put "markdown" in the application's Comments field (by doing Get Info on the app), instead of setting a tag, this works. Support for tags would make a lot of sense, though. In the meantime, this workflow searches applications by tags.

Selecting the option to include AppleScripts in Alfred's Default Results does not work as you would expect it to because scripts saved in the standard locations (~/Library/Scripts and ~/Library/Application Scripts) are marked as system files and thus won't be shown in Alfred's default results under any circumstances. That is to say, if you do the most reasonable/logical thing and save your scripts in the standard folders (where other applications, like Mail.app or FastScripts, expect to find them), add the folders to Alfred's Search Scope, and then check the AppleScripts option, nothing happens… I believe the current situation (with AppleScripts being one of the default options under Extras) strongly implies that the above would work. Certainly, this has come up repeatedly on the forum, @rounak being the latest to run into it. My suggestion would be to remove AppleScripts from the Extras section or replace it with a separate, "smart" Application Scripts option that includes the default script directories, finds scripts marked as system files, and also finds .applescript and .scptd (i.e. text and bundle format) scripts in addition to .scpt ones.

Isn't this the same error you had one year ago, which I posted the fix for?

It's nothing to do with the context. I'd like to be able to drill down and navigate back up again in my workflows as easily as you can in navigation mode. The only way to do this is using delimited queries (with e.g. " 〉␣". If the user deletes the trailing space (so the query now ends with the delimiter), the Script Filter detects this, drops the last segment of the query and calls itself again. With my Smart Folders workflow, for example, the keyword is .sf, so you enter .sf and the Script Filter shows a list of your Saved Searches. If you TAB on one (say, "MKV Episodes"), the query expands to .sf MKV Episodes 〉␣ and the Script Filter shows the contents of that Saved Search. You can continue typing to filter the contents of the Saved Search. OTOH, if you press backspace and delete the trailing space (i.e. query is now .sf MKV Episodes 〉), the Script Filter jumps back to the previous "level", showing all your Saved Searches, i.e. query is now .sf That is to say, it works like navigation mode. Deleting the delimiter (or the trailing space in this case) pops the entire last "level" off the query, instead of just deleting the last character. The only way to do that (that I know of, at any rate) is to call Alfred again using the workflow's keyword. Because Alfred doesn't tell you what keyword was used, you have to hardcode it. So if the user has changed the keyword, the workflow is now broken. There's no way to back up to the "workflow root" with External Triggers. You either need to add an extra "Go back" result that points to a corresponding External Trigger or "force" the user into External Trigger mode as soon as they start typing a query. With CMD+Backspace, you either stay in the External Trigger you're in or exit the workflow completely.

When you say "working days", does that also exclude public holidays? In that case, you'd probably want to store the counter in a workflow variable. Perhaps add a second variable that stores the current date. That way you can test if the script has already been run today, and not increment the counter again if it has.

I always say that. And every year in the middle of March, I'm still finding scripts that aren't working properly because I hardcoded the year…

@rounak Alfred's cache only applies to applications and preference panes. Reloading it has no effect on other types of files. The "Include folders in Home" says right underneath it "Excluding ~/Library"… The files in ~/Library/Scripts are marked as system files—as Andrew described above. To search them, you need to use a File Filter with the "Show files marked as System Files" option selected. That option doesn't exist for the default scope, so there's no way to get scripts in ~/Library/Scripts in your default results. If you use a lot of AppleScripts, this workflow might be useful. It also knows about application-specific script directories. @Andrew I double checked ~/Library/Logs. mdfind can't see any of the log files in there, either, so I guess they're not actually indexed. Finder lets you search ~/Library/Logs by filename, but not by content.

Then how about letting a workflow call itself via an External Script in "keyword mode", which behaves precisely as if the user had entered the keyword and chosen that workflow? I'd like to be able to write a workflow that behaves like Alfred's navigation mode without the risk of everything breaking if the user changes the keyword.

There's a very good reason for that. Namely, it breaks your operating system. The people saying that know what they're talking about. If you really want to break your system, by all means go ahead, but please don't go telling other people to do the same silly thing. Homebrew Python does not come with the same libraries installed as the system Python, so there's a very good chance you'll break other software. Your changes will also be overwritten when you update the OS. If you want to use a different Python, edit the workflow instead of — quite literally — breaking your OS X installation. It's absolutely trivial to fix. All you have to do is open the Script Filter in the workflow and change "python bookmarks.py…" to "/usr/local/bin/python bookmarks.py…" If you'd just asked, anyone who knows anything about Python could have told you that. Instead, you go and start overwriting parts of your operating system and then tell other people to do the same thing. Not the smartest move, tbh. If I were you, I'd go an find my Snow Leopard install media and repair the system. There's a fair chance you broke something else "fixing" the workflow.

On a somewhat related note, can you add the current workflow keyword to Alfred's environmental variables? That would be a huge help for workflows that want to call themselves. I know you can call an External Trigger instead, but you know I really don't like that mode, and randomly (from a user's perspective) switching modes because a workflow's implementation requires it to call itself is bad UX.

Or drag as fast as you want sideways.

I know about sips, so there's likely a reason I didn't use it. Perhaps I couldn't get the transparency to work?

I tried that, and it doesn't work. I tried long ago to set up a File Filter for ~/Library/Logs. Can search the files just fine in Finder, but Alfred can't "see" most of them, "show system files" or no. I can't recall right now whether mdfind worked or not.

I'll have a go, but it's more of a complete rewrite than plugging it in. Do you keep your GIFs in ~/Dropbox/Public/gifs too?

It seems Alfred doesn't get along with most folders in ~/Library, neither in File Filters nor in its default results.

FWIW, when it runs your workflow, Alfred sets the alfred_version environment variable to its own version number. You could grab the first character of that and insert it in your paths to support both v2 and v3. Be warned, however, that if you edit a workflow in Alfred 3, it will no longer run in Alfred 2, regardless of whether you use any Alfred 3-specific features or not.

Manipulating windows isn't something that Alfred has explicit support for. It can be done, all the same, but only by implementing what you want in AppleScript and then running it with Alfred. It'd be a lot easier to do with an application whose purpose is arranging windows.

I'm not a designer. You're both evil and should feel evil With that out of the way, here is a module from one of my workflows for generating Alfred-sized thumbnails while preserving aspect ratio. It's not particularly standalone, however. It depends on GraphicsMagick (via Homebrew) and uses Alfred-Workflow to keep the workflow snappy (thumbnails are generated in the background). You might be able to make use of the GraphicsMagick command or the module itself. If you need help integrating it with another workflow, just ask.

Moving to Workflow Help & Questions forum

It also bears mentioning that you only need root privileges (and therefore your password) to start servers like Apache and MySQL because they run on privileged ports (<1024) and/or under special, locked-down accounts. If you're not using your computer as an actual "production" server, you don't need these features. For local development, it's much easier to run them from your normal user account (run Apache on port 8080, for example). That way, you also don't have to mess about with sudo and root permissions to edit configuration files.

Terminal displaying your password isn't the only downside: it's also sitting around in plaintext. Not a good idea. The AppleScript method is way better, imo. OS X pops up its standard "Enter your password" dialog, i.e. it uses a GUI, not a shell (that also displays your password). If you don't want to be asked for your password, you should edit the sudoers file. It's not that complicated, and your password isn't sitting around in plaintext. You can also restrict it to specific commands/scripts/programs: username ALL=(ALL:ALL) NOPASSWD: /path/to/command (Obviously, replace username with your username and /path/to/command with, well, the path to the script/program)