Tyler Eich

I apologize for any misunderstandings, but Alfred Version 3 has not yet been released to the public. "On the way" indicates that it is not yet finished — though you can bet Andrew and Vero are working like mad to get it out the door!

To clear a few things up:

• The email you received was not malicious. In fact, giving you the opportunity to purchase the Powerpack at a 10% discount has saved you money
• Since you just purchased a Powerpack license, you will receive a free upgrade to v3 when it's ready. You have immediate access to Alfred 2 (which is already awesome) and a free license to use the next major version. You have access to two versions of Alfred for the price of one license
• Vero is a single person who handles license inquiries and support, and Vero needs to sleep. Please be patient, as I'm sure she'll be waking up to many, many emails 

Finally, welcome to the forums! If you have any further questions, please ask! There are plenty of very smart people here who gladly share their knowledge with new users 

Screenshots would be very useful here. If you use Dropbox, you can share a link to the screenshots. Otherwise, Imgur is a decent service.

Just paste the links if you don't feel like embedding them in your post.

This is mostly in regard to results from Alfred's file search (the full path as shown in the subtext).

1. Replace the path to the home folder with '~'
2. Replace e.g. 'Library/Mobile Documents/com~apple~Pages/Documents' with 'iCloud Drive/Pages'

This would at least be a nice option to have. Paths for items on iCloud Drive paths are excessively long and not very readable.

In reply to Dean:

Your last explanation clicked for me

Let me try to explain what I see between our two approaches:

Tyler's:

• UI sugar on top of the already-available workflow capabilities (delimiters, submenus)
• Developer is in the same position as previously
• Script filters act statefully, using tab-delimited inputs to rebuild state for each execution

Pros:

• Prettier UI
• Simpler to back out of an action (just remove the last entry from the stack)

Cons:

• Stateful programming sucks
• Developers receive no real help with control flow

Dean's:

• Send output directly to an (a.) action that does a thing (b.) script filter that return more options
• Each item is responsible for declaring where it should be sent if actioned
• No action or script filter needs to know how the last step got its result, it only needs the result
• Actions and Script Filters are labelled, basically eliminating the need for external triggers to pass data within a workflow

Pros:

• Stateless components
• Much simpler control flow

Cons:

• Could require significant rethinking of the Trigger/Input/Action/Output paradigm (may also be a Pro)
• To allow undo/back out, Alfred needs to maintain a stack of previous actions and the outputs sent to them

I have an intuitive sense that each solution has a different optimal use case, but I haven't thought too hard about it. Maybe my idea would be better suited to simple drill-down navigation, while yours is better suited to control flow between functional components.

Either way, I like what I'm understanding about your solution. It's as big of a leap in capability as Alfred 2 was to Alfred 1.

To me, it sounds like script filters have outgrown their implementation. From what I'm seeing, a script filter does not always need to have a keyword, nor does it always make sense to do so.

It sounds like people want a first-class way of telling Alfred which UI to display next. The current solution (using Applescript to call an External Trigger or to populate Alfred with a keyword) is sub-optimal. I don't know about you, but I feel dirty every time I type osascript -e 'tell application "Alfred 2" to search "keyword"'.

I can see benefit to having the keyword in the environment if you want a quick fix that's as dirty as Applescript, but not if the system itself were built to handle this interaction better. If workflow objects had developer-specified labels, the keyword chosen by the user would be irrelevant.

In your proposed model, Alfred is keeping track of where the workflow is in its hierarchy, but the workflow still has to figure that out for itself by parsing the query into its component levels and acting accordingly. This rapidly gets very complicated as the depth of the hierarchy increases. (I've been toying with the idea of a Flask-like URL {query} routing utility class to make this easier, but that's a fairly complex undertaking in itself.)

Yes, the method I proposed would require Alfred to remember and send the stack to the script filter. Currently, this task is handled manually via query chaining by workflow authors.

I've seen quite a few workflows (like Carlos Recent Items workflow) using the ➣ character to separate the components of the hierarchy. The method I proposed eliminates the need for a special delimiter, as Alfred would handle the stack automatically. Based on how popular character-delimited hierarchy navigation is, I'd call this a net win for developers.

Even if parsing is just as tedious (what with splitting the query and parsing components as is already required), at least Alfred could allow developers to keep odd Unicode characters out of the query string. I'd argue that a native UI is more intuitive to the user than a Unicode delimiter, and no more difficult for the workflow developer.

I would prefer a model where the workflow can tell Alfred to call a specific Script Filter via its results. Being able to arbitrarily pass control to other Script Filters within a workflow would simplify development considerably. In any case, if there's a call stack, I'd like Alfred to take care of that for you in some fashion (e.g. mapping each level to a different Script Filter), so it doesn't have to be replicated in every single workflow. Not only is it tricky (two levels is okay, but three gets complicated), but there'd also be the possibility of the two stacks (Alfred's and the workflow's) getting out of sync due to bugs.

I value Alfred's support of different programming styles. Allowing multiple script filters to handle a task is therefore a necessary consideration.

You made a note about "passing control to other script filters within a workflow". That could mean two things in my mind:

1. A script filter object (represented by a white block in Alfred's UI) calls another script filter object (another white block)
2. The underlying script used by a script filter passes control to another script/function in the same directory

Both options are currently possible in Alfred. For option 1, use an External Trigger. For option 2, use a switch construct with cases for passing data to each function. If I've misunderstood you, please do let me know.

As for "mapping each level to a different script filter", how would Alfred accomplish this? I don't know of any simple way to show Alfred that when option A happens, use this filter, but if B or C happens, use this filter, etc. A programming language is far better suited to handle this logic. Simply point a single script filter to a script that acts as a control dispatcher. Neither the script filter nor Alfred has to know where you're heading; it is left totally to the underlying script to select the correct function and send the results, which Alfred is only too happy to display.

Not sure how "getting out of sync" would be an issue…would love more info

I very much like the idea of Alfred maintaining a navigable call stack, but I think text would be a better fit than icons: if a workflow is showing dynamic data, it's not always possible to provide a suitable icon, and if you're 3 levels down in, say, a filesystem, 3 folder icons aren't particularly expressive. A specific keyboard shortcut (perhaps ⌘+↑ or ⌘+⌫) to back out would be more convenient than having to delete any query and then hit delete.

I agree. Icons are not always the most expressive, nor are they readily available.

Would a token system be better? Similar UI to how Mail displays tokens around email addresses and only allows them to be deleted (not edited) once they're generated.

Keyboard shortcut all the things

Before putting your -1 on the table, could you show an example of how the issue of multi-level workflow or settings toggles has been (or could be) solved in a better way that doesn't make development more complicated (for Andrew and for workflow authors)?

What about a new value for the type attribute? Something like type="category". When actioned, the icon of the category is placed into Alfred's UI similarly to the way External Triggers do.

Example of how it would work:

User is activating a workflow that uses a script filter to drill into a folder structure to find a specific file

User activates script filter with "drill alpha-folder"

User selects item with:

type: "category"

arg: "/alpha-folder"

icon: "alpha-icon.png"

Alfred places "drill-icon.png" and "alpha-icon.png" into the left part of the UI (as occurs for External Triggers)

Alfred sends "/alpha-folder" as query to script filter

​Script filter responds with results from /alpha-folder

User selects item with:

type: "category"

arg: "/bravo-folder"

icon: "bravo-icon.png"

Alfred places "bravo-icon.png" above/next to "alpha-icon.png" to indicate hierarchy (at some reasonable point, icons collapse instead of stacking at full width)

Alfred sends "/alpha-folder [tab] /bravo-folder" as query to script filter (tab separated, similar File Actions)

Script filter responds with results from /foo-folder/bar-folder

User presses delete key

Alfred removes "bravo-icon.png" from UI stack

Alfred sends "/alpha-folder" as query to script filter

​Script filter response with items from /alpha-folder

User selects item with:

type: "file"

arg: "/alpha-folder/charlie-name.txt"

icon: "charlie-icon.png"

Alfred sends "/alpha-folder/charlie-name.txt" to the next action

Action does whatever it does, just like always…

Let me know what's good, bad, and/or ugly about this solution. I'm very interested to hear how other people would approach this issue, especially those with more experience developing hierarchical workflows.

I know External Triggers are intended for that kind of thing, but I avoid them whenever possible because they put Alfred in a special mode with no way back to Alfred's standard mode. Instead of hitting ⌥+⌫ to clear the query and start using Alfred, I have to close and reopen it. It's by no means a huge chore, but it is clunky.

Wouldn't it be better if delete were simply able to clear the External Trigger? Then you have the benefit of External Triggers (special UI, specifically designed for this use case, scoped specifically to workflow, prevents keyword collision with other workflows, etc.) and the ability to easily clear/cancel.

I'm giving a -1 to keyword in the environment variable, unless there's a better example of how this could be generally useful

Otherwise, good stuff. Would love to see more batteries-included workflow features

Alfred's support page mentions it:

https://www.alfredapp.com/help/features/contacts/#viewer

Trash Workflow

This should do what you want, except I chose 'trash' as my keyword instead of 'delete'. Hope this helps

Chrome comes bundled with Flash built in.

Glad to hear you resolved your issue!

[moving to closed]

Just to cover all the bases: have you already tried the suggestions in Troubleshooting Indexing Issues? If you haven't tried them all, which ones have you already attempted?

I think you'll find this thread useful: http://www.alfredforum.com/topic/3942-script-filter-show-multiple-lines-for-each-item/?p=23485

Alfred does not support this. In order to paste the snippet into another application, Alfred needs to copy the snippet to the clipboard, which overwrites whatever was there before.

If you're using clipboard history, you should be able to find the text you originally copied listed near the top. Then you can re-copy the text to your clipboard and paste it wherever you need it.

Hope this helps!

Did you already follow the support steps listed in Alfred's support documentation?

No, this functionality does not exist in Alfred.

As I understand, placing the cursor in a text snippet is much less reliable than pasting (which Alfred does now). It would require using OS X's Accessibility API to actually simulate moving the cursor, which feels like a hack.

Good news:

The long input no longer crashes Alfred. So that much is fixed.

Bad news:

Build 375 isn't letting me search for files (tested using the ' and "open" keywords). 2.6 stable still works.

Also, memory usage is still high for me (in both build 375 and 374 stable). When I first launch Alfred, it runs on the expected 14-20MB of RAM, but once I enter a query, it jumps to 40+MB and slowly grows over time.

I can confirm this issue on my machine. Alfred froze and memory usage grew to over 2GB (and growing, with no sign of stopping) before I killed the process.

I pasted the AngularJS source code into Alfred to trigger the freeze.

Alfred 2 v2.6 (374) on Mac OS X 10.10.2 (14C109)

I'm not available to help with this at the moment…

I imagine there's a workflow that already implements this mechanism, but I don't know which off the top of my head. Perhaps another forum member can suggest something?

Sorry I couldn't be more useful here 

When you action a file result, Alfred doesn't send your search query as `q`, it sends the path to the file that it found. One solution is to use a script filter, and then set `arg` for each item to your search text. `arg` is passed as `q` when using a script filter

+1. This would finally put my sleeping Mac to good use.

If this were to be added, I think it should also forward Alfred's results to Remote. That way script filters would work too

In other words, I agree with you

As far as I know, this isn't possible yet.

One workaround is to:

1. Select the item you want to move and press ⌘X (this will cut the item out of the remote page)
2. Move other items around until the empty space is where you want your item to go
3. ⌘V to paste. The item you cut will occupy the empty space.

I believe this is going to be improved soon, but for now the above process is the best way to get around it

+1

I've just confirmed that it works on my end. Have you tried redownloading and installing Alfred? All your data will be saved, and this will fix the issue if there are any corruptions in the current file.