xilopaint

You're right. @nikivi avoided that issue by making an extremely generous donation. Whole crates of beer! That and some good suggestions and a PR for improving the workflow.
 
If I'm honest, the main reason I haven't released a proper v2 is that I hate developing this workflow.
 
Because it rewrites its own info.plist, I have to delete and re-create a bunch of my own searches for each release, but most of all Alfred (or more precisely the FSEvents API) doesn't notice changes to symlinked files, so I have to re-link the workflow constantly and/or restart Alfred to get the changes to appear.
 
More importantly, I'm wondering if the whole thing needs rewriting again.
 
@nikivi wants to be able to have alternate search engines for modifier keys, so for example, ↩ does the search with Google, but ⌘↩ does the search with Google's I'm Feeling Lucky.
 
I'm not a huge fan of that, but what I would like to do is separate suggestion sources from search URLs somewhat. That way you could use Google or DDG to provide suggestions for sites that have a search URL, but not an autosuggestion one. That would make the OpenSearch import a lot more useful (so far, I've found that only MediaWiki sites also provide the auto-suggestion API).
 
I could automatically fall back to Google suggestions if the site doesn't have its own API (rather than failing), but I'm not sure how effective that would be.
 
In either case, that's already possible by adding your own custom engine definitions in the data directory, but that's a sucky UX.
 

New build! ✨?

You are in fact setting a UID of '' in your XML... For Alfred to generate a random UID, you need to miss the UID field altogether...
<item valid="no" autocomplete="Playlist▹spotify:user:trickyofficial:playlist:1u5vQfIxo8X1zoOInXxSGn▹"> This should fix the sorting issue you're seeing. The code / behaviour around this hasn't changed for quite some time, so it may have just been lucky that having all UIDs set to the same empty string would have sorted them arbitrarily correctly for you.
 
Moving to [closed], but do let me know if this fixes your issue or not.
 
Cheers,
Andrew

I had to create a new Urban Dictionary workflow as my previous one was broken.
 

 
It's available on GitHub.

hahahaha thank you for bringing those issues to my attention. deanishe vs. nikvi discussions are on top of my geek humor ranking.
 

Umm, it looks like something I've fixed but haven't released:
 

 
If you can build the workflow from the develop branch, it should work as expected.
 
Beyond that, I'll try to release a new RC at the weekend. There are a few fixes/enhancements in develop and Niki has started posting duplicates of his own issues on the Searchio! repo.

I had to create a new Urban Dictionary workflow as my previous one was broken.
 

 
It's available on GitHub.

Good stuff. An Urban Dictionary workflow is a must-have.
 
I've submitted a PR to fix URL encoding (so multi-word queries work) and text encoding (so non-ASCII queries work).
 
Something I suspect you've missed is that json returns and expects unicode objects, not str, and Alfred Workflow always gives you unicode strings unless you've specifically requested bytes from web.py.
 
This line is key.

You've encoded the up/down signs in order to add them to that str, but result['word'] is unicode because it comes from the json API, so the workflow won't work if that's non-ASCII. title must be a unicode string.

I had to create a new Urban Dictionary workflow as my previous one was broken.
 

 
It's available on GitHub.

I had to create a new Urban Dictionary workflow as my previous one was broken.
 

 
It's available on GitHub.

@xilopaint I love this workflow! Thanks a ton for sharing it.
 
Quick Question: Is there any way to quickly view a selected PDF's info (e.g., total page numbers - or other info)? 
 
For example, I love using your workflow to quickly move the first page of a PDF to the end of the document. While the Slice file action (single file) is great for this, its syntax requires knowing the total number of pages in the PDF (e.g., for a 15 page PDF, it would be 2-15, 1). Is there any way to get the page count through the workflow (kMDItemNumberOfPages - I think ...)?
 
I understand that the "Get Info" default file action in Alfred can do this, but it's a little clunky to manually open/close, etc. I was just wondering if the workflow displayed this info internally.
 
If not - and, of course, assuming that you're looking for suggestions for future updates - I was thinking that it might be cool to display the relevant file information in the file action's title. So, for example, in the slice file action for a single file, it might do something like this:
Current Title: Enter page numbers and/or page ranges (e.g. 2, 5-8). New Title: Enter page numbers and/or page ranges (e.g. 2, 5-8) of X pages. And, for the resolution or size file actions of a single file, it might also provide their respective details. 
 
Alternatively, adding generic reference points to the end of a document might also do the trick (e.g., last, blank for remaining pages, etc.). So, users could do the same thing without knowing the actual page count (e.g., last, 2-).
 
Thanks again for posting the workflow! It's awesome!!

Update (v1.5):
Added ability to show to-dos in projects using the ⇧ modifier key. Fixed multiple issues for non-English locale.

Update (v1.5.1):
 
Fixed typo in Mark as Completed action.

@deanishe @xilopaint Updated workflow with the new icon.

This is actually added by osascript. The best option is to pop a Trim utility after the script before the copy to clipboard
 
Cheers,
Andrew

Try ProcessControl. It does that and much more.

Nothing relevant there.
 
The code was catching the true error, so I made some changes to find the issue:
 
 
This led me to search for the API information on 17Track website:
 
 
Nothing we can do. The workflow is dead.

This workflow lets you control your Home Assistant from Alfred.
You will be able to control you lights, get sensor information, trigger automations and look for your devices in device tracker.
And more to come..
 
Setup
_haurl - Set the URL to the home assistant. 
_hapassword - set the API password for Home Assistant
 
Commands to interact with home assistant
To triggar an automation:
haa
 
To control lights:
hal 
 
To control your alarm:
haal
 
To look at a Sensor:
has
 
To look at device tracker
had
 
 
You will find the workflow here : https://github.com/Skakiz/Alfred-Home-assistant-workflow
 
Lights:

 
Automations:

 
This is my first python coding, so no glitter code.
 
Thanks!
//Andreas

Does it have a CLI? I'm searching for an OCR app with a CLI.
 
 
May I reply here saying thank you and f*** you? 

Don't think so, no. Sorry.
 
 
My apologies

http://ocrkit.com/help/
 
I don’t know about how it’s performance compares but I’ve had very few issues with quality.
 

Personally, I'd say "no". An OCR engine invariably needs large language library files.
 
Far better to define some kind of "API" for integrating the user's preferred OCR engine. Something like an OCR_COMMAND in the workflow's settings where a user can specify the command-line invocation for their preferred OCR engine with placeholders for the input and output files, e.g. OCR_COMMAND = /usr/local/bin/ocr-x --input $1 --output $2 --lang en.
 

If you have upgraded to Alfred 3 recently, it should be the problem. Here's a link with the fixed workflow.

Fantastic workflow, thank you so much!

That's exactly what I mean!
 
Anyone with any sense would have used Python