Jump to content

Why does the ⇧ to QuickLook feature not work in my workflow


Recommended Posts

Posted

QuickLook only works when arg is a URL, not a JSON object. Arguably a bug in Alfred.
 
Note that your workflow is broken in at least two ways. The alfred.py library is very old and out of date. It has Alfred 2's data and cache directories hard-coded. If you don't change them, the workflow will fail for anyone that still doesn't have their old Alfred 2 directories.
 
Also, you should be using json.dumps(...) to create your alfredworkflow JSON object, not trying to build the JSON by hand. Sooner or later, the URL or title will contain a character that can't be written as-is to JSON (a quotation mark, non-ASCII characters), and your workflow will stop working.

Posted

Thanks, deanishe

 

In fact, this is a fork from ethan-funny/Google-Alfred3-Workflow, which have some issues with the proxy module (as I need proxy to access Google in China).

Also, the upstream workflow outputs a string in the form of "query;url" in order to copy url & copy url as markdown later. For me QuickLook is as important as Markdown. If I simply change the arg to URL, QuickLook works but Markdown fails.

So I was trying to find a way in which arg is still a URL and the script sets a variable of the title to form markdown - [$title](URL). That was the only solution I could think up. After some googling, I came up to your post. [[HOW TO] Workflow/environment variables](http://www.alfredforum.com/topic/9070-how-to-workflowenvironment-variables/). I followed your ways to set variables and successfully got variable $title, but QuickLook failed.

 

That's the whole story behind this post.

As to the out of date library, maybe I need to rewrite the workflow with your advanced Alfred-Workflow lib. I'm wondering is there a easy way to achieve my demands based on the existing codes. If not, I shall move on to the rewriting work.

 

Posted (edited)
First of all, I'd report the behaviour as a bug in the appropriate forum. Seems to me that QuickLook should work if arg is a path/URL, even if it's encoded in JSON.
 
What you can do in the meantime is set arg to the URL and save the other data to a temporary file (e.g. JSON), which the next action can load again. Every workflow has its own data directory (its path is in the alfred_workflow_data environment variable) for this purpose.
 
Regarding the SOCKS proxy: Where is that running? Do you have your own VPS somewhere?
 
If so, have you thought about setting up an HTTP proxy server (e.g. squid) on it and creating an SSH tunnel to that, instead of using a SOCKS proxy?
 
The advantage of this method is that HTTP proxies are supported by almost everything that speaks HTTP (unlike SOCKS proxies). You can configure the proxy system-wide in System Preferences > Network, or use it on an app-by-app basis.

 

In particular, you can "convert" most workflows to use the proxy just by setting the Workflow Environment Variables http_proxy and https_proxy in the workflow's configuration sheet. Languages like Python and Ruby, and programs like curl will automatically use the proxy.
 
If you have a system-wide proxy set, Alfred automatically sets http_proxy and https_proxy for you.
 
If you have a lot of workflows you'd like to route via a proxy, you should definitely look into tunnelling to an HTTP proxy. It'll be a lot easier than trying to add SOCKS support to every individual workflow.
 
Edited by deanishe
Posted

Thanks so much for your great advices. JSON makes it work!

 

Yes, I have a VPS with SOCKS5 proxy deployed. In case you didn't know, Internet censorship in China is extreme and a lot of international services(Google, Youtube, Facebook, Twitter, Dropbox, etc) are blocked. The project know as GFW is evil but powerful. We have to use kinds of proxies to cross it. SOCKS5 is the fastest and stablest choice by now.

Posted
Yeah. I know a bit about the GFW. Where I live and work, there's some blocking going on. I have a VPS running Streisand to get around it.

 

That's why I recommend the SSH tunnel + HTTP proxy on the VPS method (if you have a VPS and can install a proxy) for this case. The SSH tunnel should get you past the GFW, and as I said, getting workflows (and many applications) to use an HTTP proxy is way simpler than SOCKS because support for HTTP proxies is transparently built in to Cocoa/Python/Ruby etc.

 

Streisand also has a SOCKS proxy as well, but I usually find SOCKS really hard to work with. It's not SOCKS itself, which is perfectly simple, it's finding software that supports it in the first place.
  • 2 weeks later...
Posted

I didn't notice this parameter before, but my problem has already been solved by following deanishe's advice.

Any way, I think this is quite a useful parameter and will give it a try some day.

  • 3 years later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...