ctwise

Are we talking about the same app? https://heyfocus.com

Create a new workflow. Add a keyword input. Use whatever keyword you like, e.g., 'focus'. Give it a title, e.g., 'Toggle Focus'. Add an Open URL action. Use the URL 'focus://toggle'. Connect the input to the action. You're done. Now when you invoke Alfred, entering the keyword will toggle Focus.

Luckily, it's trivial, just attach a keyword to the Open URL action with the URL 'focus://toggle'.

As far as I am aware, it's not a bug. The only way for Alfred to get the current selection in another app is to trigger a pasteboard copy. I believe what you're really after is script access to the Alfred clipboard history.

Most of the workflows that deal with large amounts of text use the pasteboard to pass the text around. Stdin would be awesome, but the pasteboard is a workaround.

There's a big problem with that - large amounts of text.

See this conversation - http://www.alfredforum.com/topic/5137-services-and-workflows/ It would be extremely useful if Alfred automatically copied any selected text to the pasteboard when it was invoked, and, when Alfred closes, clean up the pasteboard if it hasn't otherwise changed. For example, if the pasteboard looked like this: "Some old text on the pasteboard" But the user selected the text: "I want this text auto-copied" Then the "I want this text auto-copied" would be sitting on the pasteboard when Alfred was invoked, before workflows executed. When Alfred closes, if the auto-copied text was still sitting on the pasteboard, Alfred should restore the original text to the pasteboard, adjusting pasteboard history as appropriate. The intent being that workflows can get access to selected text when Alfred is invoked or ignore it if they're not interested and not be surprised by the pasteboard containing something when they didn't explicitly invoked copy. At the moment this behavior requires creating a hot-key and requesting that the selection in OS/X should be passed through. See http://www.packal.org/workflow/funnel for an example of a workflow that uses this feature to implement text filters on selected text. But, if the requested feature were implemented then funnel/filter-like workflows could be broken up into individual workflows that acted on text selections instead of requiring a different hot-key for each separate workflow.

You can get half-way there. The problem is that Alfred doesn't automatically trigger a copy when it is invoked and then restore the old pasteboard when it closes. Because of that, you don't have access to the app that had focus when Alfred was triggered and you can't copy text. Now that I've written that, I realize it should be a feature request. There's a way around this but it requires using a hot-key. If you create a hot-key in a workflow, you can choose to pass-through 'Selection in OS/X'. Then the text you selected is copied to the pasteboard for use by the next step in a workflow. This is only half of what you're asking for, because the selection is only usable in that specific workflow. Take a look at the Funnel workflow (http://www.packal.org/workflow/funnel) to see a workflow that uses that feature to pump selected text through a user-configurable set of filters, e.g., lowercase, uppercase, remove blank lines, base64 encode/decode, etc.

Sorry, I'm as baffled as you. I've only ever seen the accessibility error when the system wide accessibility wasn't checked.

Ok. :-) Do you have Accessibility turned on for Alfred? The scripts run as Alfred.

I'm guessing it's the difference between OS/X menu handling and Unity (or whatever Ubuntu is using in that video). Many apps in OS/X do funky things with the menus and entries don't get updated or registered with OS/X. For example, an undo command may say 'Undo <action>', but OS/X has it listed as just plain 'Undo'. That said, Chrome menu entries show up just fine on my system.

A few things: 1. Alfred isn't running scripts from the command-line. There is no shell environment present, only the GUI environment. So your executable paths aren't present. Even when you run a bash script, bash is being started and stopped with the GUI environment as a non-login shell. 2. Any scripts you run using a relative path, e.g., 'start.rb', must be in the workflow directory. Otherwise you need to give the absolute path to the script. 3. You can run Ruby (and Python and Perl and Applescript) directly by putting in the code window and choosing the appropriate language from the dropdown. 4. The Ruby you're running is the system Ruby, not one you may have installed using RVM (or other tool). 5. In general when you're passing the {query} to a script or command you want to double quote it. And then check the Escape Double Quotes script option. Basically, whatever you're wrapping the {query} in needs to be escaped, e.g., backticks, etc.

Take a look at the 'curl' command. It has a lot of options for GETing URLs.

The color definitions in the theme files appear to be serialized objects. They aren't editable in the files. I would like to be able to view and tweak them to fine-tune appearance definitions. Please store and read color definitions in user-editable text.

I think you're right. I let my enthusiasm take me away. :-) I'm not sure if it's possible for Alfred to serve as the progress display "handler". I notice that the script editor displays the progress with a pie chart and logging messages in the bottom of the script window, so at some level it should be possible.

You're using an old version of the script. Please install the one on packal.org.

Either wait for a new release that supports it or run it using the shell 'osascript' command.

You can do it yourself right now. Preferences -> Features -> Contacts -- click on Phone and pick 'Pass to URL Scheme'. In the URL field, enter 'tel://{query}'. Now when you press enter on a contact phone number it'll open the call dialog. You _do_ have to press the Call button to initiate the call though.

Just noticed this after installing Yosemite: Progress Reporting AppleScript now has built-in support for reporting progress in a script. The global AppleScript object has four new properties: progress total steps (an integer) progress completed steps (an integer) progress description (text) progress additional description (text) A script may set any of these properties at any time during the script to update the progress display. progress completed steps divided by progress total steps provides the fraction completed; if completed or total is -1, progress is considered indeterminate. progress description and progress additional description provide a message about what the script is doing. Exactly how the progress is displayed depends on how the script is run: in Script Editor, it appears in the script window’s status bar; in script applications (applets), it appears as a progress dialog; and for scripts run from Script Menu, it appears in the Script Monitor menu. (Script Monitor appeared in previous system releases, but was only used for Automator workflows; it now displays any script run using NSUserScriptTask, which includes anything run from Script Menu.)

Only the very first version of the workflow used a cache. If you're still using the initial version you should get the later one off of Packal. If you're already using the latest version then you can go into the workflow directory and run './menudump --yaml -- pid <n>' from the command-line to see what the script thinks the menu structure is for a given app. You get the pid number from the ps command, e.g., 'ps -ef'.

I really like the idea. Can you put it on Packal?

Very, very, very few workflows will benefit from compilation. Most workflows actually _do_ very little work. If a script takes 100 milliseconds and a compiled version takes 10 milliseconds, you won't be able to tell the difference. The exception is when your workflow takes seconds to run _and_ the reason for the delay is computation, not network lag. A much more likely reason for compiling code for a workflow is that it's the only (or easiest) way to interact with something in OS/X.

I'm on Fusion 7 and it's still working for me. Can you turn on debug in Alfred and let me know what error messages you're seeing?

You got it right, the script isn't working due to a problem with Focus, not with your script. You'll have to take it up with the Focus developer.

Create a text file and save the contents in it. Make it executable from the command line with 'chmod +x <scriptname>'. Run it from the command line './<scriptname>'