Tips: LaunchBar

Yes, over here my MBA, mid-2012 with 10.12.3, has no LB delay on wake-from-sleep. Just have LB delays after reboot from Apple menu (same user), logout / login (different user), or launch after shutdown-then-boot.

The LB delays happen the first time I use LB after one of those events. LB is one of my login items, but even if I reboot and wait an hour, the first time I invoke LB I get a delay.

FWIW, my index is 21.5 MB. Maybe @Tom's theory that the delay has something to do with a recent LB version -- or even the recent versions' interaction with Apple security patches that were applied to both 10.11.x and 10.12.x.

So many theories, so few answers LOL :smile:

You are right, the delay also happens after logout/login, not only after system boot.

I noticed that 2.5MB of my 4.4MB index folder (=58%) belong to a “frameworkCache” file, which is built when indexing Development Resources:

However, disabling the indexing of Development Resources (and thus reducing the size of the index folder to 1.9MB) did not improve the delay.

Further I have 39.6MB in ~/Library/Caches/at.obdev.LaunchBar/Temporary Items/com.apple.Safari/History.db. Disabling the indexing of the Safari history didn’t change the delay either.

FWIW: Out of curiosity I added the entire ~/Library folder to the index (“Any Item”). This blew up the index folder from 4.4MB to 93.3MB and increased the unresponsive delay from 5 seconds to 2 minutes.

Note: This was for testing only. For normal usage this is complete madness, and not necessary. If you want to add the Library folder, it is normally sufficient to limit the index to “Folders” (not “Any Item”) and you should exclude large parts of the Library (e.g. Caches, Containers, and many more) via “Skip Subfolders”.

@Tom, I'm responding to a post you made in the Script Debugger forum because we have a better LB thread here.

@Tom, thanks for sharing. As always, your insights into LB are amazing and very helpful.

So, I was trying to follow your approach for executing a script via LB.
In the case of processing a Finder selection, I wonder if we really need to send the selection to LB first?

For example, if I select one or more files/folders in the Finder, then activate LB, all I need todo is find the script (by typing the assigned keys, or just key characters in the name), and the press RETURN.

In my case I wanted to execute the script
@Finder Create @Symlink or @Alias of Selected Items in Choose Folder @Tool @AS.scpt

So I selected the Finder items, activated LB, typed "@sym" which immediately found the script, then RETURN.

But I'm probably missing something critical in your workflow.
Your thoughts?

It depends on the script:

If you have a script that already gets the Finder selection by itself, then you don’t need to “send” it.

A typical example for that would be an AS with…

tell application "Finder" to set theItems to selection as alias list


But otherwise the “Sending” is very handy because it provides the argument(s) for any script:

For example in a Perl script you can grab the arguments (= the items sent to LB) from @ARGV:

for (@ARGV){
  say "$_";
}

or in Bash from $@:

for ARG in "$@"; do
  echo "$ARG"
done


Also very useful for running scripts on text selections in any editor, since you can “send” the text to the script without having to bother with the clipboard.

For example in AS by using the handle_string handler:

on handle_string(_string)
  return [{title:"1 string passed"}, {title:_string}]
end handle_string


See here for more details.

And of course you can send not only Finder items or selected text, but also something from LaunchBar itself. For example a file/folder you have selected in LB’s file browser, or the result from another action, etc.

PS:

To make it more clear, this is what you send with the “Instant Send” key:

Can anyone here help me with this, posted in the LB Forum:
###Need Help Creating Action to Find/Execute JXA Scripts

(EDIT: 2017-04-29 2:30 PM CT – link fixed)

TIA.

The requested topic does not exist.

??

https://forums.obdev.at/viewtopic.php?f=24&t=10812&p=32198#p32198

Sorry, link is now fixed. Same as @Tom posted.
https://forums.obdev.at/viewtopic.php?f=24&p=32198#p32198

If you come up with a shell script that does your search (via mdfind) I can help you to get the LB input and to put the results out to LB. But not these days, too much work.

Hint: The input is explained in the post above. The output should contain the paths and be JSON-compatible. (I would use the jq JSON processor. You can get it via Homebrew.)

Have you already read thru the Action documentation?

OK, here is a very simple action, but I think it does what you asked for. No bells and whistles, no pretty output!

Search JXA Scripts.lbaction.zip (10.0 KB)

It shows only scripts with "JXA" in the name (case sensitive). You can enter a search string, if you don’t enter nothing it shows you all "JXA" scripts. The search is live-updated.

The search is limited to the $HOME folder. Change this in the script if you want to search everywhere.

Many thanks, Tom.

OK. I'll take a look at the script, and see if I can figure out how to:

  • Set the default folder to my "DEV" folder in my DropBox.
  • Support a Send Folder to allow search of specific folder.

@Tom, I think setting the default folder is easy enough.
But allowing for a Send Folder to use instead is not obvious to me. I looked at your script and the Spotlight Search script, but didn't see any good examples that I could use as a model. If you know of one, please let me know.

OK, here you go:

Search JXA Scripts-ver2.lbaction.zip (6.1 KB)

>>> Please read through the whole post to understand how it works.

The JXA-Search action now has two “personas”:

####A. Search for a JXA script

This is exactly as with the old version: bring up the JXA-Search action, hit the Spacebar and enter your query.

B. Set search path

This is the new part.

  1. Select any folder where you want to limit your search to, e.g. “Scripts”

  2. Send the “Scripts” folder to the Action, as you know it from other Send actions:

  3. While the “Scripts” folder is selected hit the Send key (Tab)

  4. Type your abbreviation to bring up the JXA-Search action

  5. Once the JXA-Search action is selected hit the Return key (not the Spacebar!)

Now the “Scripts” folder is the new search path.


Now, to actually perform a search in the “Scripts” folder, bring up the JXA-Search action again and hit the Spacebar to enter your query. (Like in step A.)

You may have noticed that, to fully enjoy the action, you must make use of the Spacebar and of the Return key. If your problem with the Return key still persists, then this might be an issue!

To understand what the Return key does and what the Spacebar does, please open the script (default.scpt). You find two explanatory comments there.


Unfortunately I haven’t found a way to do the two things in one step.

But you know the ⌘B hotkey, don’t you? ⌘B brings up the recently performed actions and items (a very useful hotkey!).

That means in our case: after you have set a new search folder, just hit ⌘B and the JXA-Search action will instantly be selected again and you can enter your query by hitting the Spacebar.


Default search path:

The default search path is set to $HOME. You can change the path in the script: just replace all instances of ${HOME} with the POSIX path of your preferred default search path.

Quickly reset a custom search path to the default path:

To restore your default search path it is not necessary to send the default folder to the action.

Just type /d into the query field.

You don’t even have to close/re-open the action, just wait a second for the live search to kick in, and the path will be reset to the default! (You’ll see a message when it happened.)

As soon as you see the message you can type a new search string to search in your default path.

Have fun!

… and remember, ⌘B is your friend!

1 Like

Many thanks, Tom. It was very kind of you to make these requested changes.
I'll check it out, and will definitely read/study your entire post.

If you cannot parse my sometimes very clumsy wording, just ask :wink:

To better understand the used AppleScript handlers, and to get an overview of all available handlers, don’t miss to read the AppleScript section of LB’s Developer Reference.

LB has an extended support for JavaScript. I think this is good news for you, since you are working much with JavaScript for Automation.

From the docs:

Scripts for LaunchBar Actions written in JavaScript are interpreted differently from scripts written in other scripting languages. […] LaunchBar 6 can run JavaScript code directly by leveraging Apple’s JavaScriptCore framework. This allows for even deeper integration with LaunchBar and additional possibilities to interact with LaunchBar […]. For more information on these additions, read the JavaScript Reference.

So, maybe, writing the Action with JS could open more options… I don’t know. Have a look at it, you are the JS expert.

1 Like

Have you tried the Action? (The 2nd version.)

Is it useful for your purposes or – more important – was it helpful to better understand how scripts can interact with LB’s input and output?

Yep, thanks. Sorry for the late feedback.

I'm running into a usability issue, not related specifically to your custom Action.
If I have an JXA displayDialog in the script, I can't get it work like the AppleScript equivalent. It either:

  1. Doesn't show immediately, but shakes the Dock icon for LB.
  2. If it does show, it doesn't have keyboard focus.

So, until I can resolve that issue, I prefer to use other tools to launch JXA scripts (KM mostly).

OK, that’s another scope.

But, nonetheless, I hope it was (somewhat) useful for learning about the various handlers you can use to interact with LB. In fact, once you’ve understood how to do it, writing an action for LB is often (not always) easier than writing a macro for KM.

As a side note: The very convenient thing with LB is that you can real-time--edit your scripts, since they are not residing inside a XML doc. And you can use your LB Bash and Perl etc. scripts also as standalone scripts, since they just respond to the usual argv argument.

Tom, it was very useful. Thanks again.
I just got sidetracked by a practical issue.