_mk_

If it is tied to the connection, I could imagine to define the alternate text at the connection based on the arg of the item or maybe its uid.

I have a script filter that shows detailed information of an OmniFocus task. I would like to add trigger actions based on the information that was selected and the modifier key that was pressed.

So for example selecting the project would result in the following actions:

• NO MODIFIER: list tasks of project
• ALT: change project

Selecting the context would trigger the equivalent actions for the context.

Currently, Alfred only allows to specify an alternate subtitle per modifier key with no regard to the selected result. I would suggest to extend this functionality to override the "global" modifier subtitle on item level:

<items>
    <item uid="myuid" arg="myarg">
        <title>My title</title>
        <subtitle>My default subtitle</subtitle>
        <icon>icon.png</icon>
        <alt>My subtitle when pressing ALT</alt>
        <cmd>My subtitle when pressing COMMAND</cmd>
        <ctrl>My subtitle when pressing CONTROL</ctrl>
        <fn>My subtitle when pressing FN</fn>
    </item>
</items>

This would allow for more flexibility when using modifier keys.

Looks like you have more python experience than me

I have never really warmed up to the snake. That's the reason I modified your workflow to use the bc command line tool instead.

Great workflow. I used the iOS app until now and did not even notice that AppShopper also supports the Mac App Store. I think this will become on of my most used workflows.

Installing lxml was quite a bit effort to get this workflow running. The MacPorts library only supported Python 2.5 so I had to build the lib and the required system libs on my own.

I created a version of the workflow based on the command line tool bc which does not require you to install/compile any additional libs. If someone is interested and obstschale agrees, I could upload it and post a link.

Technically that COULD be done, you would just send both in the arg value and would have to read and/or parse that in the next step. I am able to replicate this though with a new group of keywords that I created and haven't actioned any of them so I know its not from use/knowledge. I'll check in with Andrew and see what he has to say on this one.

Your solution of passing both arguments with the arg will not work ... unfortunately. The seconds argument is a user input. So I cannot code it into the arg of the feedback xml. Something like autocomplete + user input would be great...

This will make my life a Lot easier. Thanks for sharing.

When using a script filter, each item has a UID value associated to it. With Alfred's knowledge database, those items are remembered as having been actioned before and start taking precedence over others depending on the number of times used. You can avoid this behavior by having your output use a unique UID for the items each time it is executed. For instance, you could use time or a uuid generated by uuidgen. That should prevent Alfred from learning those items and keep them in the correct order.

I already use random uids for the results of my task actions to have them in the desired order. This works as expected. The problem I have is related to Alfreds default search when writing a workflow keyword. Lets say I have the following action keywords defined in my worflow:

.oftp

.oftc

.oftv

When I now do a search in Alfred and type ".of" then Alfred shows me a list of all my actions starting with ".of". The problem I have is that the order of Alfred's results does not make any sense to me. They are not ordered by keyword not by name not by the time I created them or anything obvious. So how does Alfred determine the order and can it be influenced?

I also tried removing all actions and using a single script filter to list all my actions. But with this approach I have the problem that I can only pass one argument to the next step in the filter chain but I would need two: the action to be invoked and a filter string.

Try it with:

set myVar to "{query}"
if myVar is "update" then
...
end if

I tried to go the road to add an additional script filter at the front of the chain. But I am stuck half way.

The first script filter has an optional argument. If it is empty, then the list of available actions is shown as seen in the first post. But now I am able to influence their order the way I want it. So far so good. The actions autocomplete to fill the optional argument.

Depending on the optional argument, the script filter should load the tasks of a project, context etc. This only works for the "inbox" and "done today" and "theme" actions as they require no other arguments.

All other actions would require a filter string as second argument. I was not able it working that way. Did I miss something or is my desired workflow not possible to implement with Alfred?

I have to think of a solution. I use my folders as areas of focus. So mixing projects and folder would not suit everyone. Maybe a separate folder search would be the best option.

So, is .oftp working when invoked from a result of .offp?

Could you please try .offp to search for a project and click on this One? Do you still get no results?

I already use this approach for my feedback results. The problem is different in my case. The listing shown above is created by Alfred when it lists all my actions that start with ".of..."

In my OmniFocus I included about 9 input script filters all starting with ".of". When I type this prefix Alfred shows me a list of all my OF workflow actions. But their order is somehow weird. They are neither ordered my their action command nor by their name nor my preferences nor anything else ... at least it seems so.

I'd like to have them in the order:

• Inbox
• Show project
• Show context
• Show perspective
• Search project
• Search perspective
• Task details
• Theme settings

Is there a way to influence the order?

I know I could add another script filter that gives me the list of actions in my desired order but that would another step into the filter chain which I would like to avoid.

The workflow is now available in version 2.0. The new features are:

• show inbox tasks
• show tasks completed today
• new task detail view with all task actions
• unflag and uncheck tasks
• support for a dark and light icon theme
• new icons

Please set your theme after updating to get the right icons:

.oftheme

I hope you like it and get a little bit more productive with the workflow.

Based on the comments by Vítor in another thread I changed the license of the workflow handler to be as permissive as possible. I do not want to throw obstacles in people's ways when using the handler. So feel free to do whatever you want with it.

Got it.

Changed the license accordingly. So feel free to include it in your projects and do whatever you want with it

The 121 lines compared to 8 lines is only valid as long as you only need the code once. But if you have to maintain several script filters using that code then i's worth using the workflowHandler IMHO.

You do not have to worry about the license. It's only a CC attribution license. The only thing required to use the script is to give a link back to the GitHub repo.

#!/bin/bash

bundleID=$(defaults read "$(pwd)/info" bundleid)
prefsDir="${HOME}/Library/Application Support/Alfred 2/Workflow Data/${bundleID}"

if [[ ! -d "${prefsDir}" ]]; then
	mkdir "${prefsDir}"
fi 

You could also use the setPref and getPref functions of the workflowHandler to save key=value pairs in a file called settings inside the workflow's cache or data dir. That will also take care of creating the folder and file for you.

If you still want to maintain the file on you own, there is a new function in workflowHandler to get the data dir:

. workflowHandler.sh
prefsDir=$(getDataDir)

Also wouldn't have to use plist buddy. Could just use defaults read command to read bundleid. That's what I do in my workflows

Using the defaults command to work with plist files is deprecated. See the comment in the default man page:

WARNING: The defaults command will be changed in an upcoming major release to only operate on
preferences domains. General plist manipulation utilities will be folded into a different
command-line program.

I'll try again this evening after work

I updated the handler to include two new convenience functions the get the DATA and CACHE dir of the workflow. I also changed the order of the arguments of the addData function to better handle empty values for valid and autocomplete.

You can grab it from GitHub. Exporting the source stopped after icon.png.

This would simply be:

DATAPATH="${NVPREFS}${getBundleId}"

But I could add a convenience method to make things more comfortable.

Also be sure to always quote your paths as the path includes spaces. That way you don't have to deal with the IFS.

There is something weired. The packaged extension includes all files. But the copied source only included the first 10 files in the main workflow directory. Thje rest was missing.