deanishe

Your best bet for grabbing the images is to take them from the Dropbox/Google Drive folder on your hard disk, not via API. The APIs are fairly complicated to use. You have to mess about registering applications and retrieving API keys. How you upload the images depends on how you access the server. If you have a self-hosted website, then presumably you also have ssh access to the server. If you've set up key-based authentication, you can upload files to the server trivially with scp dir/of/images/* www.example.com:/path/to/my/wp/images/folder Or push the images with git. Or sync the directories with rsync. There are many possibilities. I would probably set up Hazel to automatically upload any images I put in the Upload folder. Or you could attach a Folder Action. Or indeed use Alfred to start the script. Generating the URLs for the images is also trivial. You know the filenames, and you know the URL of the directory you've uploaded them to. I can't say anything more concrete without a more concrete description of the task.

That's unrelated to Spotlight and indexing. mdimport is your friend. Here's (some of) what my machine shows for a Markdown file: mdimport -d2 rTorrent.md 2016-07-08 17:57:45.456 mdimport[86103:3591746] Imported '~/Dropbox/Documents/Text Files/rTorrent.md' of type 'net.daringfireball.markdown' with no plugIn. 2016-07-08 17:57:45.458 mdimport[86103:3591746] Attributes: { ... ... kMDItemContentType = "net.daringfireball.markdown"; kMDItemContentTypeTree = ( "net.daringfireball.markdown", "public.text", "public.data", "public.item", "public.content" ); ... ... kMDItemKind = { "" = "Plain Text"; }; } As you can see, there is no Markdown importer. The system treats it like a plain text file. It may or may not be set up the same way on your system. The bottom line is you're probably never going to get the same results from Spotlight/Alfred as from nvAlt because they're using different search engines.

You can get the current time with the shell command date "+%H:%M:%S" and you can tell Alfred to display some text in its results list by passing it JSON from a Script Filter. So, create a Script Filter with the keyword "time" and No Argument. Then put this in the Script box (leave Language set to /bin/bash): t=$(date "+%H:%M:%S") cat <<EOS { "items": [ {"title": "$t"} ] } EOS That will return one result to Alfred, containing the current time. You're always likely to have an issue with other results using a common word like "time" as the keyword. I generally prefix my keywords with ".", which will exclude all of Alfred's default results. For this Script Filter, I might use ".t" instead of "time".

Invalid XML is invalid XML. It won't work with any software that requires valid input. If you want to massage it by hand, replace & with & (the XML escape for &), but the file will probably get overwritten by the software fairly soon.

nikivi's pretty hardcore. He posted his usage graph somewhere. It's insane.

Yup! I've been digging into this for a Safari workflow I'm working on. It stores a whole bunch (many thousands) of .webhistory files in ~/Library/Caches/Metadata/Safari/History Drag one of those to a File Filter to search your Safari history. I wouldn't recommend adding your history to your default scope, as the entries might overwhelm your other results. The UTI is com.apple.safari.history Safari also exports its bookmarks (to ~/Library/Caches/Metadata/Safari/Bookmarks with the extension .webbookmark and UTI com.apple.safari.bookmark). OmniFocus also exports its metadata to files under ~/Library/Caches/Metadata. I hope this is something a lot of apps start doing. It's very handy.

Some also have data/cache directory paths hard-coded for Alfred 2.

With the exception of entering numbers, anything your calculator can do, your Mac can do better. If you can be more specific about how you want it to work, it'd take a few minutes to write.

Some workflows aren't compatible with Alfred 3. Look for the workflows' threads in the Share Your Workflows forum.

Sorry, I misread your post. If you want to include a program with your workflow, put it in the workflow's directory. That's the working directory when your workflow is run. There's no guarantee any given program will work that way, nor that it will work on any system but yours. Depends on the program.

I don't know. What do you think is a reasonable size for a workflow?

That's a question for the Ghostscript forum, tbh.

You can save the query for later use using workflow variables. Be sure to read the official Alfred docs linked in that post.

/usr/libexec/PlistBuddy -c "Add :variables:awt_language string \"en\"" info.plist

Ghostscript is 100+MB. You can't bundle that with a workflow.

If you installed them with Homebrew, then presumably the programs are in /usr/local/bin. That isn't on Alfred's PATH. Use /usr/local/bin/ps2pdf instead of just ps2pdf.

http://www.deanishe.net/alfred-workflow/user-manual/update.html

Sorry. That's a bug. I left a print statement in there while I was trying to debug a problem, and the unit tests didn't pick it up I've just released a new version (1.18.1) that should fix the problem. Again, very sorry about that and thanks for spotting the bug!

Unfortunately, generating valid XML isn't as simple as it looks. If you don't use a library, it's very likely that you/your users are going to keep running into issues with invalid XML, like the one above. Doesn't Ruby have an XML library built in? What about JSON? Alfred 3 understands JSON, too.

If you want Alfred to do the filtering for you, you need to give it a list of all the data. Otherwise you need to handle filtering the results based on the query yourself. You'd likely want to do that anyway in this case, as Alfred only performs a "word starts with" comparison on the item title, and you'd presumably want to search other fields, too. My MailTo workflow uses the contacts database, and I found the best way was to cache all the contact data in a background process and only use the cached data in the workflow. The AddressBook API was too slow for my liking (I was probably using it wrong).

Notify.app is written in AppleScript.

If you're going to use sys.stderr.write() in Python, don't forget to add the trailing newline: sys.stderr.write('Message\n') For simple scripts, I normally use this log() function: # Needed to use print this way from __future__ import print_function def log(s, *args): if args: s = s % args print(s, file=sys.stderr) # Usage log('var1=%r, var2=%r', var1, var2)

Natural language queries are almost certainly pie-in-the-sky for a workflow. It's probably possible to search the titles of your events, depending on which calendar application you use. Can I assume you're using Apple's Calendar.app?

Alfred is working precisely as designed, to be honest. It tries to give you results as fast as possible, so it isn't waiting for all its various sources to return their results before it starts showing them. It's what makes Alfred so fast. The flipside is that you have to keep half an eye on what you're actioning. There's really not a lot you can do about it. To get the predictable behaviour you want, Alfred would have to wait till all active sources return their results, and that would basically break Alfred. You can't have Alfred's internal application cache, which returns in at most a few milliseconds, waiting for some webservice-based workflow that takes multiple seconds to return.

It works for me. What is your input, expected output and actual output?