jdfwarrior

If the other person isn't using 1password then there is no reason to save his info as a login item and not just a secure note. So why not just save his info as a secure note then it won't show in Alfred

The 1Password integration filters based on your input. That being said, why not just type an extra character or two more toward what you are intending to find and let Alfred filter the search results down into a better managed set (not showing all the extras)? Or if you are worried about someone stumbling upon sensitive data, you could always just disable the 1Password feature.

I started tinkering with this at one point and while it CAN be done, its kind of a pain in the butt. I could be wrong or maybe just having an off day but I think the only way to do it with a workflow would be to use mdfind to get a list of all events. Then read and parse each file to get the relevant data out. In other words, it would probably be kinda slow. As mentioned you would have to use mdfind to get all events, read each file, parse it, find the data you want, reformat (dates) and then build xml from the small subset of events you actually want.

You can do that or just make a small script to do it. Doing a simple replace to get rid of parenthesis, hyphens, and spaces seems to work well. Replace the, with nothing so it passes a string of numbers to the imessage url scheme

If you set up Custom Actions for Contacts you can make it pass the selected phone number into the imessage url scheme. See screenshot here As far as being able to autocomplete phone numbers... I wanted to say no, but apparently you can. You could have a script that would use mdfind to locate contacts and return data for you if you really wanted it. Wouldn't be something I would suggest, but if you really want to do it.. mdfind "kMDItemContentType=com.apple.addressbook.person && kMDItemTitle = '*Ferguson*'" That would search for contacts where their name matched Ferguson. You'll probably be asked if you want to allow mdfind to search your contacts. That should return a list of files that match. Then you could run mdls on the files to get the data from them. As I said, this isn't something I recommend. I would just stick with creating a custom action for the phone number

Edited the bash script to run JUST ru "{query}" and it worked fine for me..

Have you checked console for any errors? Also, what about the escaping in the script? Are those options set correctly?

Slow your roll guys Once v2 is out we may look into setting up some kind of repo. Right now, getting things feature complete and working out bugs are the biggest issue at hand. Tom Hunt's repo was definitely an awesome idea but popularity of Alfred and its workflows and extensions should always be kept in mind when planning something for Alfred. I learned that the hard way with my original v1 Wolfram extension. Wolfram limits requests to 2000 per day. My original thought was, "that should be plenty!". My API key got killed a few days later, averaging 9-10k requests a day. Oops And that was back when it only fired at the end when the extension was executed... not at every keystroke like it does now with Workflows. Alfred v2 obviously isn't even available to everyone yet so imagine how much traffic would be hitting a server if you put up a workflow that searches an API and returns data, on every keystroke, when Alfred v2 is in full swing and everyone has it. Simple, cheap web hosting services aren't going to cut it.

1. It fires on every keystroke to match the filtering that is found in the regular, non workflow searches. It makes it perform more as a filter than a, enter in all your text and then search. This has been discussed numerous times already and been suggested quite a few times here already as well. The current method of execution works well. One way we have suggested to resolve issues like this is, in your code, restrict the execution of the code until the input string reaches a specific length. In other words, Don't perform the search until after the input is at least 3 characters long. By doing that, when your script does actually fire and search for matches, the number of potential matches should be a smaller and help improve execution time. Another thing you could do is cache the results and search the cache as opposed to performing a full search every time 2. As long as its formatted to match the style that Alfred uses, you can make it just use the contents of a file, however, Alfred won't be performing the search, that would still be on you. This could easily be done with a workflow though. 3. Having a bunch of stuff just randomly listed in Alfred's initial search would probably not result in the best user experience because, even when that's NOT what you are looking for, you will have this random group of things cluttering up your results. If you set good keywords, and after you've used those workflows a few times, Alfred learns that you prefer those items and you could start actioning them by typing only 2-3 letters. I know typing 2-3 letters sounds like more of an inconvenience than not typing at all, but if they were to show up, then you have to arrow 2-3 times to get to the actual result you are looking for. It also requires you to watch the results to see which on you have to select. Also, another option would be to create a workflow that has all of these items in it that you wish to have quickly/easily visible, then set the keyword of all of them to maybe, a comma? Then when you could open Alfred and just type a comma and have all those results listed.

The option exists if you right click on the Workflow in the list on the left.

Ah yeah, I missed that.. If the file doesn't exist, it falls back to writing to the data folder instead. Yeah I'll have to find a way to fix that

Unfortunately I thought I had fixed this but I hadn't, it should be fixed now I believe

Only because this is only available to beta members right now. Trust me dude, like I said, I made this mistake with my v1 Wolfram extension. If/when it gets noticed by the masses.. its going to cause a problem. Also, it's 2000 calls a month, not per day. My Alfred 1.x extension was doing 10k+ until they killed it

And yeah... the library makes it SOOOO quick and easy to do stuff and create a workflow. Did all the documentation make sense to you?

Ok I think I figured it out. I got mixed up on my logic for selecting paths. What it does is.. when you pass it a path to write to, it checks to see if that path exists, if it does, that means it could be in the current workflow folder, OR its a full path. I needed to add an extra check to see if it was full path. If it isn't then it prepends the path to the workflow. So, just for clarification.. now.. when you try to read a file for instance, it will 1. Check to see if the file given exists 1a. If so, check to see if its the workflow (current) path, or a fully specified path. If its in current path (just the filename was passed), then it prepends the full path to that file. 2. If not.. checks to see if the file exists in the data folder, if so, prepends data path to the front of it. 3. If not.. checks to see if the file exists in the cache folder, if so, prepends the cache path to the front. 4. If not.. fails. Same applies for the write/set. 1. Checks to see if it exists in current. 1a. If it is in current, prepends full path to that, otherwise, assumes its full path already and leaves it alone 2. If not.. checks data path 3. If not.. checks cache path 4. If not.. falls back and writes to data path. Make sense? So if you don't use a path.. for writes.. it checks locally, checks to see if it exists in data, then cache, and if not, just writes to data. For reads.. it checks local or assumes full, if not it checks in data, then cache, if the file wasn't found, it fails (returns false). Download the update on Github

Appears to be an error on my part in the logic of which location to select. I'll work on fixing it and push it back to github.. Sorry

The 'Shutdown' keyword can do this

Exactly why I didn't recreate this from my v1 extension. If you left your app ID in.. just know, it will be used, your limit will be hit, and you won't be able to use your own You should release it without the app id, and instruct people how to get their own. Trust me on this one..

Several people have already suggested this. As of now, obviously, this functionality doesn't exist. You can't fake it by simulating keypresses with applescript either because you can't simulate the eject key. I've recommended to several people, just download Sleep Display. Then just run it, or create a hotkey for running it (in workflows)

I have an idea of how to accomplish this... let me poke around at it a bit, hopefully tonight, and I'll try to post something back. If you don't hear back from me in the next day or so, bump this thread again. I've been extremely busy and an liable to get busy and forget

Great suggestion by Tyler. The only downside to this method is that you would have to create the filters for each folder. Not sure if you'd but up for that or not?

I'm not sure what exactly it is that you are looking to do but as Jonas suggested, you can pop up Alfred using Cmd+Space (or whatever your hotkey of choice is), then press Cmd+, will open the preferences window. You can also pop up Alfred and type 'preferences' and 'Show Alfred Preferences' should be one of your actionable results. Or, finally, if you meant from a script: tell application "Alfred 2" activate tell application "System Events" to keystroke "," using {command down} end tell That would activate Alfred and send the Cmd+, keystroke for you and show the preferences.

Thank you sir I still haven't heard back from them about my api access request.. Wonder what's taking them so long..

So... you are wanting to open a terminal and execute a command? I'm not really clear on what it is you are wanting to do?

Yeah it's definitely what twinpeaks described and isn't some kind of workflow updater.