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). Replace the path to the home folder with '~' 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.

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 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: A script filter object (represented by a white block in Alfred's UI) calls another script filter object (another white block) 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 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

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.

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

+1 Adding an 'update' keyword seems like an obvious and quick addition. I do love Chrome's auto-updating technique, just waiting until the next reboot to install updates. I don't know if that makes sense for Alfred, but it sure is convenient…

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!