deanishe

You can try re-indexing the app, which should hopefully update the name. In Terminal/iTerm, run mdimport /Applications/Deliveries.app Probably not relevant, but somebody might find this trick useful: I sometimes need to start an application with German locale on my English system (so it uses German number formatting etc.). I added a File Action connected to the following script: new_locale='de_DE@currency=EUR' original_locale=$(defaults read -g AppleLocale) defaults write -g AppleLocale "$new_locale" open {query} defaults write -g AppleLocale "$original_locale" This only affects one application, and the best bit is it doesn't change the application language, so I don't have to deal with Apple's weird German translations.

This is straightforward to do with a workflow, but you need a Powerpack licence to use/create workflows. I dare say it'd be worth the price for this job alone. To do this, first create a workflow. Then add a Hotkey trigger (+ > Triggers > Hotkey). Assign your hotkey, and drag the Lightroom application into the list in the Related Apps tab. Then add a Run Script action (+ > Actions > Run Script). Set language to "/usr/bin/osascript (AS)" and paste the following in the Script box: tell application "System Events" to keystroke "Avalanche" Connect the Hotkey box to the Run Script action and you're good to go. Repeat 29 more times for your other hotkey-text combinations. (You can copy and paste, then edit the existing actions).

You didn't find other documentation: that is the documentation. GitHub is where the source code lives, and you were reading the documentation source. I'm actually surprised it's as readable as it is. For the docs, please always look here. Please ask any questions related to the Alfred-Workflow Python library in this thread.

What you have written makes literally no sense. I understand that English is not your native language, but nobody can help if the question makes no sense. Do you mean: I've searched for a simple package-tracking workflow but none that I found works. Are there any working ones?

That's exactly what appears to be impossible. It might be possible to find the event by searching based on start time or title (if all your events have unique titles).

There doesn't appear to be a way to do this (easily). It seems that it's impossible to search Google Calendars using the event UIDs (unique IDs) stored in the .ics files on disk. I suspect you might have to write a full-blown workflow based on the Google Calendar API.

I've created a corresponding bug report in the Bugs forum. Please keep an eye on that thread and add any further relevant information to there.

Alfred 2.8.3 (433) / OS X 10.11.2 As noted in this thread, Alfred doesn't find contacts from Google accounts in normal (non-Spotlight-metadata) mode. I've confirmed it with my own Google account. It appears to be an issue with Alfred, as my MailTo workflow, which uses the AddressBook API, finds 'em just fine. Spotlight metadata mode works just fine with Google contacts.

Just tried this myself and Alfred isn't finding Google contacts. It appears to be an issue with Alfred: my MailTo workflow uses the Address Book API and finds Google contacts just fine. This may be a bug, however there is a workaround: Open Alfred Preferences. Go to Features > Contacts > Advanced and select Searching: Use Spotlight metadata for searching contacts That way, any contacts you can find in Spotlight will also appear in Alfred.

I've uploaded an updated version (1.2.1) that works with python 2.6 (which I recall has solved issues you've had with other workflows). In future, when you report an error, please post the error log from Alfred's debugger, like katie did above. It's very unusual to be able to diagnose a problem from a screenshot. (I seem to recall asking you to do this the last time, too.) You should be able to update using flix workflow:update. You'll probably see a few errors while typing in the query, but I think it will work nevertheless.

You're on Snow Leopard, right? I made a change that isn't compatible with your ancient Python version. Easily fixed, though. Will have a look when I get home. It'd be a big help if you could post the full error message from Alfred's debugger, so I know which line the mistake was in.

Thanks very much. Very helpful suggestions, and I gave them a quick poke with a stick. Moreflicks.com looks like a decent drop-in replacement. The data are better from the others, but they're also protected with hidden form tokens and sessions cookies, which makes pilfering them harder, and more importantly, slower.

It's a tricky problem with no obvious works-for-everyone solution. I deliberately allowed duplicates, as it's possible that someone might have assigned the same email address to multiple people, e.g. I might have both Andrew and Vero with info@alfredapp com as their email(s). (The workflow organises everything by email address.) Filtering duplicates by name is a non-starter (damn your eyes, John Smiths!), and filtering by email AND name would only work well if you're careful naming your contacts. I can think of a couple of ways it might be fixed in the workflow, but neither is ideal. Basically, the difficulty of spotting duplicates is why syncing accounts is so hard to do in the first place (and "Apple and Google can't do it. We'll have to call Dean." is not something anyone said ever.) Still, I guess a few dupes is okay in the workflow. It's not like it changes your address book. May I ask why you can't disable your Google Contacts on the Mac? I'm trying to figure out if it would be better to be able to ignore certain accounts (though I don't yet know if this is possible with the Contacts API) — which strikes me as a fairly clean solution — or whether I should try to implement some sort of duplicate filter (exclude duplicate emails or exclude duplicate email AND name).

I tried it your way first. I was gutted that it didn't also work that way

To be honest, I re-downloaded the dictionary dump from dict.cc, spent half an hour thinking how to parse it in a sensible way, couldn't think of an obvious solution, then kinda gave up. The main issue is that the data dump is rather freely structured. It's not easy to parse reliably into proper data. If you have any thoughts about how that might be done, I'm all ears… I'll make a note to come back to this next. It's a workflow I use a lot, so any improvement would be a great help to me.

raguay's suggestion does't work because the .alfredworkflow filetype is a zip file, not a package (a folder with a file extension). Renaming the original zip won't work because it contains a folder. Simply right-click on info.plist and choose Compress "info.plist" This should give you a file called info.plist.zip. Rename that to info.alfredworkflow. Double-click the file, and Alfred should offer to install it.

We've been through this in detail before. And by that, I mean you asked exactly the same question and got a detailed answer. Water is wet, the sky is blue. Pointing out the obvious doesn't make it any easier to actually do it. Does that mean you won't post this exact same thing a third time?

If you can make and export a workflow, uploading it to Packal should be well within your capabilities. You only have to fill out a web form.

It shouldn't matter what the path is, as long as it's in Alfred's scope. And not a hidden directory. Can Spotlight find the application in question?

Make sure the Cask directory (/opt/homebrew-cask/Caskroom) is in Alfred's default Search Scope (Alfred Preferences > Features > Default Results > Search Scope).

Updated to work with changes to Flixsearch.io. Enter flix workflow:update in Alfred to install the new version. Not, they keep removing more and more data from the website. Not sure how much longer this workflow can exist. Anyone know any other websites?

Thanks for reporting the issue. Flixsearch.io has again changed the HTML format on their pages, so the workflow is fundamentally broken. I will see what I can do to fix the workflow later today.

That's a lot simpler than my way. Wish I'd known about that earlier. Is Alfred's behaviour documented anywhere?

Fundamentally, Alfred needs the Spotlight index to do its thing. It does keep its own cache of applications, however, so you could try entering "reload" in Alfred to rebuild its list of applications. I'm not sure if that can help a great deal if the underlying Spotlight index is borked.

One way I got around this was to temporarily exclude a lot of the unwanted results via the Spotlight Privacy tab in System Preferences. Hopefully, then the folder you want will appear in Alfred's results. Action it a couple of times to train Alfred to prefer that folder for that query, then remove the temporary entries from the Privacy tab. This is definitely annoying behaviour, especially as Alfred doesn't prioritise exact matches over partial ones (e.g. I search for "2015", but folders named "2015" aren't shown, while ones named, e.g. "2015-06-01" are).