LaunchBar 6 improvements I'd like to see in Alfred

[ctwise]

I just looked through the programming guide for LaunchBar 6 "actions" which are their equivalent of workflows. Alfred, in general, has more comprehensive workflow support (not even counting the GUI layout tool), but LaunchBar 6 has some features it would be nice to see in Alfred:

 

- Scripts can be marked to be killed if they don't return before the next keypress, e.g., user types 'A', script searches the internet, user types 'B', script is killed and re-run with 'AB'

 

  This is an overall feature that's been requested many times but I don't think anyone actually mentioned killing the currently running script.

 

- Scripts support either 'strings' or 'paths'

 

  I believe a script that takes a path gets path completion support in the LaunchBar entry box.

 

- Scripts can return a 'string', a 'path' or a complex result

 

  LaunchBar assumes defaults for everything if your script just returns a string or a path instead of XML, JSON, etc.

 

- Environment variables are passed to the script w/various paths and information about the state of the option key, command key, etc.

 

- LaunchBar can accept script output in JSON, XML or a property list XML

 

  I don't care about property list XML, but I would love if JSON was an option.

 

- Items returned by a script can include a quicklook URL

 

- Items can indicate another script to run to get the next 'level' of items, e.g., a multi-level menu

- Items can directly list out the next 'level' of items

 

  Various Alfred scripts now have hacks that "re-call" the script and mimic multiple levels of results. LaunchBar bakes it into the workflow model.

 

- LaunchBar actions are code signed

 

- LaunchBar supports using JavaScriptCore as a scripting language

 

- Scripts can marked to be initiated by LaunchBar but LaunchBar immediately returns (doesn't wait for output)

 

 

[deanishe]

- Items can indicate another script to run to get the next 'level' of items, e.g., a multi-level menu

- Items can directly list out the next 'level' of items

 

  Various Alfred scripts now have hacks that "re-call" the script and mimic multiple levels of results. LaunchBar bakes it into the workflow model.

This one so much.

Multi-level workflows are so common, and the current "hacks" of using special delimiters or calling back into Alfred via AppleScript look ugly and amateurish and complicate the coding of workflows significantly.

Proper support for multiple levels (so you can drill-down and back out like on iOS apps) would be a massive help.

[MuppetGate]

 

I just looked through the programming guide for LaunchBar 6 "actions" which are their equivalent of workflows. Alfred, in general, has more comprehensive workflow support (not even counting the GUI layout tool), but LaunchBar 6 has some features it would be nice to see in Alfred:

 

- Scripts can be marked to be killed if they don't return before the next keypress, e.g., user types 'A', script searches the internet, user types 'B', script is killed and re-run with 'AB'

 

  This is an overall feature that's been requested many times but I don't think anyone actually mentioned killing the currently running script.

 

- Scripts support either 'strings' or 'paths'

 

  I believe a script that takes a path gets path completion support in the LaunchBar entry box.

 

- Scripts can return a 'string', a 'path' or a complex result

 

  LaunchBar assumes defaults for everything if your script just returns a string or a path instead of XML, JSON, etc.

 

- Environment variables are passed to the script w/various paths and information about the state of the option key, command key, etc.

 

- LaunchBar can accept script output in JSON, XML or a property list XML

 

  I don't care about property list XML, but I would love if JSON was an option.

 

- Items returned by a script can include a quicklook URL

 

- Items can indicate another script to run to get the next 'level' of items, e.g., a multi-level menu

- Items can directly list out the next 'level' of items

 

  Various Alfred scripts now have hacks that "re-call" the script and mimic multiple levels of results. LaunchBar bakes it into the workflow model.

 

- LaunchBar actions are code signed

 

- LaunchBar supports using JavaScriptCore as a scripting language

 

- Scripts can marked to be initiated by LaunchBar but LaunchBar immediately returns (doesn't wait for output)

 

 

 

Agree with just about everything here, especially the ability to get data from other scripts & workflows to get multi-level items. I'm playing with workflows at the moment and the Alfred-way is pretty hard going.

 

Since Apple is including Javascript for Automation in Yosemite then I guess Javascripting will land in the Autumn. This won't help folk who don't upgrade to the new OS though.

 

I notice that Launchbar also has the beginnings of a site for sharing extensions. I think Alfred is also lacking a standardised way to do this. Packal is great, but we still can't download and update workflows from inside Alfred.

 

One other small thing:

 

I'd like access to the side window that Alfred uses to display contact information, song details etc.  The Notification Centre window is sometimes too small, and sending messages through Large Type can look like your shouting at people.

Edited June 17, 2014 by MuppetGate

[deanishe]

You can search Packal from within Alfred, and you will very soon be able to update workflows from within Alfred, too. (The current beta of the workflow is fully functional, but we're still trying to finalise the bundler, which it depends on.)

What do you mean by "standardised"? Packal is a standardised way for sharing your workflows.

If you mean "official", I think that's a red herring. Sublime Text and Vim do wonderfully well with their non-official plugin management systems. This forum seems to be the "official" way to distribute workflows, and Packal is far better suited to the task. "Official" only beats "un-official" if it's also equal in every other respect…

I've been having a dig around the Launchbar extension docs, as the execution model is far more attractive than Alfred's extremely limited one, and the thing that struck me is the requirement for extensions to be signed. That's a fairly large hoop to jump through, imo, unless there's somewhere you can get free certificates suitable for signing code (startssl.com perhaps?). Self-signed certificates are understandably not acceptable, and there's no way I'm paying Apple $100/year to be able to write Launchbar extensions…

Agree 100% with Alfred making its other UIs available to workflows.

Edited June 17, 2014 by deanishe

[raguay.customct]

I believe you can sign it with the free developer account, but that is still too difficult for just anyone to do. 

[vitor]

I believe you can sign it with the free developer account

 

You can’t.

[raguay.customct]

Actually, your actions do not have to be signed. In the indexing rules for actions, you have to turn on the option to only run actions that are signed. So, you can create actions for yourself with no problem. But, to have it on their site they will have to be signed. Makes it unattractive for developers, but okay for personal uses. I'll bet this will push someone to supply unsigned actions on another site.

[smarg19]

- Items can indicate another script to run to get the next 'level' of items, e.g., a multi-level menu

- Items can directly list out the next 'level' of items

All of these sound great, but I have to up-vote these two in particular. These would GREATLY simplify a few of my workflows.

[rice.shawn]

I notice that Launchbar also has the beginnings of a site for sharing extensions. I think Alfred is also lacking a standardised way to do this. Packal is great, but we still can't download and update workflows 

 

Well, if you install the Packal updater workflow, then you get access to updating through Alfred, but not through the Alfred Preferences GUI, but, in a way, you get more direct access to update via the Alfred Bar itself, and, if you need, you have the GUI. And if we consider Packal as a standard way, then, well, I'd love that!

 

While Workflows aren't signed, Packal will codesign each workflow and check those before updating anything through the Packal Updater Workflow. Since the original poster to Packal is the only one who can update it, then there is a level of security there.

 

I like to think that I saved Andrew from having to do that work so that he could focus on more cool things.

 

Packal ain't perfect, but I'm still trying to make it better, albeit slowly.

[rice.shawn]

One other small thing:

 

I'd like access to the side window that Alfred uses to display contact information, song details etc.  The Notification Centre window is sometimes too small, and sending messages through Large Type can look like your shouting at people.

 

Also, myself, Dean, and Ritashugisha have been working on a radical rewrite of the Alfred Bundler framework. The development on it has been very, very active, and we've tried to include some things that would help with this exactly. A few improvements:

• Full support for Python
• Full support for Ruby
• Easy access via bindings for CocoaDialog and Terminal Notifier
• Baked in logging functions
• PyPi support
• Gem support
• Composer Support
• ...many other things

 

We've also worked out many of the annoyances that the first version of the bundler had. The PHP, Python, and Ruby versions will have a nice way to display notification center esque messages, and the box will expand to include as much text as you need. Also, you can send these notifications from anywhere in the workflow, thus allowing you to send multiple notifications throughout the execution of the script.

 

Basically, the syntax is easy. Here a working version of what you need to do for the PHP version.

$b = new AlfredBundler;
$b->binding( 'CocoaDialog' );
$cd->notify([ 'title'=>'My title', 'text'=>'my text', 'icon'=>'icon.png']);

That will send a nice little notification that even includes your workflow icon. The Python and Ruby implementations are just as simple.

 

The bundler isn't official, but the new version is shaping up to be pretty badass.

[deanishe]

The bundler isn't official, but the new version is shaping up to be pretty badass.

 

Until smarg19 breaks it, which he always does, the blighter.

[rice.shawn]

Until smarg19 breaks it, which he always does, the blighter.

 

That means he's an invaluable tester.

[deanishe]

You say, "bug", I say "misunderstood feature".

[MuppetGate]

Well, if you install the Packal updater workflow, then you get access to updating through Alfred, but not through the Alfred Preferences GUI, but, in a way, you get more direct access to update via the Alfred Bar itself, and, if you need, you have the GUI. And if we consider Packal as a standard way, then, well, I'd love that!

 

While Workflows aren't signed, Packal will codesign each workflow and check those before updating anything through the Packal Updater Workflow. Since the original poster to Packal is the only one who can update it, then there is a level of security there.

 

I like to think that I saved Andrew from having to do that work so that he could focus on more cool things.

 

Packal ain't perfect, but I'm still trying to make it better, albeit slowly.

 

Yes, I think I wrote that before the Packal Updater went live.

 

It is, indeed, the dog's danglies.

 

:-)

[smarg19]

Until smarg19 breaks it, which he always does, the blighter.

"break" is such a strong word. I prefer "points out areas for improvement"

That means he's an invaluable tester.

Couldn't agree more

But honestly, I "watch" the development on GitHub, and this will be solid when you all release it and a great boon to Alfred workflows. I honestly feel that we (mostly y'all) are turning Alfred into an amazing mini-platform for software development. I have to find anything with this subtle balance between ease and simplicity of creation as well as complexity and power of performance. With the Bundler, that will go to another level. We will truly be able to build basically our own little apps that run on top of the Alfred platform. That is crazy power, yet so simple as well. This is great stuff. Keep up the good work!