Script Filter with preview pane like Clipboard

[nkgm]

I'm developing a workflow that produces a dynamic list of snippets for pasting into the frontmost app. Some results may be too long, or even multiline. It would be great if we had a way to configure the "Script Filter" to display a Preview Pane on the right side, just like the Clipboard Panel does. The actual content displayed could then be sourced from the "arg" json field, or even a special "preview" one. And since the Clipboard Panel can also preview images, how about throwing that into the mix as well?

[deanishe]

For the time being, there is the Large Type (⌘L) or Quicklook (⌘Y or long-press ⇧).

[nkgm]

24 minutes ago, deanishe said:

For the time being, there is the Large Type (⌘L) or Quicklook (⌘Y or long-press ⇧).

 

Sadly neither of these will work: Large Type can barely fit 50 characters in one line and there's no way to use a smaller font size, and Quicklook would require a "quicklookurl", so unless there's a QL plugin that allows embedding text in the actual URL, that's not practical, not even as a workaround. 

[deanishe]

17 minutes ago, nkgm said:

unless there's a QL plugin that allows embedding text in the actual URL

 

Your workflow would need to have its own webserver. Or you can create temp files containing the text, which is probably a lot easier (quicklookurl can also be a filepath).

 

I like the idea of having a preview-like UI, but I think anything like that is an "Alfred 4" feature.

Edited October 7, 2018 by deanishe

[nkgm]

34 minutes ago, deanishe said:

 

Your workflow would need to have its own webserver. Or you can create temp files containing the text, which is probably a lot easier (quicklookurl can also be a filepath).

 

I like the idea of having a preview-like UI, but I think anything like that is an "Alfred 4" feature.

 

I'd me more than happy knowing it's on the roadmap.

 

I guess a system-wide nodejs server with a "http://localhost/<bundle_id>/*" URL structure could be a stopgap for a few sorely missed Alfred features - you could have full-blown templates! The problem however is there's no way to keep Quicklook open while navigating results and you'd have to keep tapping away at the Shift key.

 

On a separate note, I just noticed that for a "quicklookurl": "https://www.alfredapp.com/" Quicklook displays the Chrome app icon and "Open with Google Chrome" button on the right, but I can't see any page content (also tried .webloc approach). Maybe it's not possible after all? (El Capitan)

[deanishe]

1 hour ago, nkgm said:

I'd me more than happy knowing it's on the roadmap

 

No idea, tbh. I'm just a beta tester and moderator. But I can say that the ability to use some of Alfred's other UI elements from workflows is a frequently-requested feature.

 

1 hour ago, nkgm said:

I guess a system-wide nodejs server

 

I think I can say with 100% confidence that integrating Node is absolutely out of the question.

I can't really imagine Andrew integrating any language into Alfred, given that it uses a UNIX-style, language-agnostic model for running workflows. But if he did, it would be a native API (i.e. AppleScript/JXA) or something small and elegant, like Lua.

In terms of philosophy, Andrew is old school. Alfred is a tiny application with zero non-native dependencies, and Node (and the JS community as a whole) is the absolute antithesis of that philosophy.

It probably doesn't help that the Node-based workflows that already exist tend to be either ridiculously bloated compared to native¹ workflows or crap all over best practices for developing workflows².

 

---

1. Using languages that ship with macOS
2. Many Node workflows are built as Node programs, not workflows. They expect to be installed via npm, but that is fundamentally incompatible with Alfred's cross-machine syncing mechanism.
 

Edited October 7, 2018 by deanishe

[deanishe]

1 hour ago, nkgm said:

I just noticed that for a "quicklookurl": "https://www.alfredapp.com/" Quicklook displays the Chrome app icon and "Open with Google Chrome" button on the right

 

Quicklook for URLs is buggy in some version of macOS. It's not an issue with Alfred.

[nkgm]

15 minutes ago, deanishe said:

I think I can say with 100% confidence that integrating Node is absolutely out of the question.

 

Who said anything about integrating Node? That would be absurd! I meant running an http service on my local machine (which I would conveniently do in Node, but could be any other technology) to act as glue for the aforementioned workflow.

 

14 minutes ago, deanishe said:

 

Quicklook for URLs is buggy in some version of macOS. It's not an issue with Alfred.

 

There's no doubt in my mind - only asking if you (or anyone else for that matter) happen to know this to work under some certain configuration.

Edited October 7, 2018 by nkgm

[deanishe]

52 minutes ago, nkgm said:

Who said anything about integrating Node?

 

You talked about using Node to provide a server with bundle IDs in the URL. If you're not talking about "global" integration, why would you need the bundle ID in the URL?

 

Also, why use Node? Python has a built-in webserver, as does PHP. And both are included with macOS, so no need to require users to mess about installing additional software.

 

52 minutes ago, nkgm said:

I meant running an http service on my local machine

 

That is, of course, perfectly possible. I do that with my Google Calendar workflow to show event details. Which then broke on Sierra because its version of Quicklook doesn't like URLs  

 

52 minutes ago, nkgm said:

only asking if you (or anyone else for that matter) happen to know this to work under some certain configuration

 

Yes, it does. Just not on Sierra.

 

But as noted earlier, creating files and passing the filepath to Quicklook via quicklookurl is generally simpler (and also works on Sierra).

 

I say "simpler" because it's important to shut down the server when it isn't being used. Not being diligent about cleaning up small cache files isn't such a big deal as not being diligent about shutting down a server process that isn't being used.

 

Edited October 7, 2018 by deanishe

[vitor]

3 hours ago, nkgm said:

Large Type can barely fit 50 characters in one line and there's no way to use a smaller font size

 

Large Type can fit way more than 50 characters in one line, and it uses a font size as big as it can fit. If your text is too long, the text size gets smaller until everything fits. I can fit considerably more text on screen with Large Type than with the Clipboard panel.

 

That said, it really wouldn’t be a good experience for your use case. @deanishe’s solution of making temporary text files is really your best bet for now.

 

Edited October 8, 2018 by vitor

[nkgm]

Quote

You talked about using Node to provide a server with bundle IDs in the URL. If you're not talking about "global" integration, why would you need the bundle ID in the URL?

 

Also, why use Node? Python has a built-in webserver, as does PHP. And both are included with macOS, so no need to require users to mess about installing additional software.

 

I was referring to having a single instance - ie not having to launch a new webserver instance for every workflow that might need this mechanism, and the Bundle ID was meant to scope the requests (it could be anything instead of Bundle ID as long as the Filter Script knows to include the proper URL in the JSON). And I did say "stopgap" ?. Also, I should have made it clear that this workflow is highly specific to my setup and not meant for publishing (except as a gist maybe).

 

Quote

But as noted earlier, creating files and passing the filepath to Quicklook via quicklookurl is generally simpler (and also works on Sierra).

 

I say "simpler" because it's important to shut down the server when it isn't being used.

 

I was trying to avoid FS thrashing, but now am thinking RAM disk maybe. BTW I don't really mind not shutting down the server as there will only ever be a single instance of it (probably started in advance).

 

1 hour ago, deanishe said:

Yes, it does. Just not on Sierra.

 

Then I assume same problem holds for El Capitan. Thanks for confirming this.

 

1 hour ago, vitor said:

 

Large Type can fit way more than 50 characters in one line, and it uses a font size as big as it can fit. If your text is too long, the text size gets smaller until everything fits. I can fit considerably more text on screen with Large Type than with the Clipboard panel.

 

That said, it really wouldn’t be a good experience for your use case. @deanishe’s solution of making temporary text files is really your best bet for now.

 

 

Just tried this and indeed it will shrink the font as needed. On the negative side, there is no control over wrapping and line breaks, but that's something I can live with. Still can't get over the fact you have to mash ⌘L (or Shift for QL) for every single result you want to preview (I understand this is not Alfred's fault as these weren't meant to be used this way), but at least now I'm aware of the alternatives, thanks to you and @deanishe. I do hope @Andrew will consider some of the things discussed here for Alfred 4 ?.

Edited October 8, 2018 by nkgm

[deanishe]

9 hours ago, nkgm said:

BTW I don't really mind not shutting down the server as there will only ever be a single instance of it

 

As long as you're not distributing the workflow, go wild. It would just be bad practice if you were.

 

9 hours ago, nkgm said:

Then I assume same problem holds for El Capitan

 

Quicklook works fine with URLs in El Cap and again in High Sierra. It's just Sierra that's broken.

 

9 hours ago, nkgm said:

I was trying to avoid FS thrashing, but now am thinking RAM disk maybe

 

If you don't care about Sierra, just use an HTTP server.

 

9 hours ago, nkgm said:

I was referring to having a single instance - ie not having to launch a new webserver instance for every workflow that might need this mechanism, and the Bundle ID was meant to scope the requests

 

Sure. Using the bundle ID makes it kinda obvious you're thinking of a one-server-for-all-workflows model.

 

For my part, I think starting a new webserver for each workflow is precisely the right way to go, assuming you're doing the proper thing and shutting it down again quickly when it's not in use. Alfred is very careful about consuming CPU cycles when it's not actively being used, and running a webserver constantly just to support a little-used feature runs entirely counter to that philosophy.

 

Also, Node would be an objectively bad choice for something like that. It's a very large, non-standard runtime, and async IO is a poor model vs real concurrency unless you're actually doing C10K stuff.

[vitor]

11 hours ago, nkgm said:

I was trying to avoid FS thrashing, but now am thinking RAM disk maybe.

 

As someone who considered RAM disks for Workflows, I’ll advise against. They’ll weirdly show up in the Finder as if they were an external drive, which can be confusing, and from what I’ve read they’re not even needed if the files are short-lived. I’m no file system expert, but the consensus seems to be that on macOS and other modern file systems, when you write the file it isn’t immediately written to the disk.