Search the Community
Showing results for tags 'modifiers'.
Hi all, I've got a query to search BibDesk (based on BibQuery by Hackademic). See pic HERE. The topmost trigger "bb", can call some of the other trigger "ba" and "bt" (which I do using applescript). However, "bb", "ba", and "bt" share most of their actions. Right now, this results in a mess. But using a junction doesn't help, since it doesn't allow for modifier. Is there anyway to create some sort of junction that allows for modifiers? Thanks.
Alfred's default handling of workflow variables set by modifiers is … odd. Setting variables via Script Filter feedback at the top level and via items behaves sensibly, and as you might expect. Namely, they are merged with existing variables, overwriting any of the same name. Setting variables via mod does something completely different. If you set any variables via a mod all other variables created during the execution flow (i.e. set anywhere but in the configuration sheet) are dropped on the floor. Not just top-level variables, but also pre-existing ones set upstream via Args & Vars or a Hotkey or passed in via an External Trigger. This is counter intuitive, counter to the way variables set elsewhere work, and I don't see an actual use case for mods to behave that way. It's fine that variables set by item the mod belongs to are not set when a mod is used, but top-level variables should not be ignored, imo, and existing variables from upstream should definitely not be deleted. I would suggest that mod variables should be handled the same way as item variables and be merged with top-level variables and existing variables from upstream.
So, this popped up over in the help forum, but this is a better place for it to solicit feedback, methinks. Currently, Alfred allows you to specify alternate subtitles for the result items returned by Script Filters, so that you can let the user know which action would be run. Looks like this: <item arg="/path/to/Ideas.txt" uid="/path/to/Ideas.txt" valid="yes"> <title>Ideas.txt</title> <subtitle>Open file</subtitle> <subtitle mod="cmd">Reveal file in Finder</subtitle> <subtitle mod="alt">Trash file</subtitle> </item> Whereby the Script Filter is connected to three different Actions. The suggestion is to turn the alternate subtitles "inside out" and add a <mod> (or <alternate>) tag that can override not just the subtitle, but any of the item's parameters (that make sense): <item arg="/path/to/Ideas.txt" uid="/path/to/Ideas.txt" valid="no"> <title>Ideas.txt</title> <subtitle>Search in Ideas.txt</subtitle> <icon type="fileicon">/path/to/Ideas.txt</icon> <mod key="shift" valid="yes" arg="/path/to/Ideas.txt"> <subtitle>Open this file</subtitle> <!-- the super-smart workflow has figured out the default app for this filetype --> <icon type="fileicon">/Applications/Sublime Text.app</icon> </mod> <mod key="cmd" valid="yes" arg="/path/to/Ideas.txt"> <subtitle>Reveal in Finder</subtitle> <icon type="fileicon">/Applications/Finder.app</icon> </mod> <mod key="alt" valid="yes" arg="/path/to/Ideas.txt"> <subtitle>Trash</subtitle> <icon type="icon">trash.png</icon> </mod> </item> This would have a few advantages: It's possible to set an item to invalid for if, say, you want to require an additional argument by default, but override that in alternate actions. Currently, an action is always valid or never valid (this was the starting point). You can change not just the subtitle, but also the title and/or the icon, providing more and better contextual information (don't forget, some users turn off subtitles) You can change the arg. This means you can avoid a plethora of Run Scripts/Open URL actions and instead generate alternate URLs (e.g. to different search engines) right in your Script Filter and connect it to just one Open URL action. The same goes for copying different representations of data (e.g. colours, emoji or other non-ASCII text) to the pasteboard. (This would also require Alfred to allow multiple connections to the same Action/falling back to the "bare" action if there isn't another connection for the modifier) By avoiding hard-coded actions, it makes it easier to allow users to configure workflows without having their changes overwritten by a workflow update (which necessarily happens to any user-added actions and connections in a workflow) It wouldn't make sense to be able to override all of an item's options (e.g. uid, copy text and large text). It strikes me (and Florian) as a powerful addition. What do you think?