rice.shawn

Would you want to expand this workflow to include the terminal? That would be rad. Then you could make it so that the args would be "merge finder" "merge "terminal" or something like that. Although, I haven't looked into it enough to see if it works similarly enough. If you want to get fancier, you could also try "merge safari" "merge chrome," etc... I do understand if that's adding features that you don't want to put into the workflow. If that's the case, ignore this!

Works great on mine. Thanks, it's so helpful.

Actually, what I mentioned above about the accessibility is found here: "Please check [system Preferences] - [security & Privacy] - [Accessibility] - [Allow the apps below to control your computer.]." I took that from another workflow thread for a workflow that merges finder windows into tabs for Mavericks.

Mavericks changed some of the ways that it allowed Applescripts to control window resizing, as far as I remember, and so anything that was written for previous versions needs to be updated. At minimum, I know that you need to authorize each application for accessibility features, or whatever it's called. But, if that's an incompatibility with Mavericks, then it would explain perfectly why the Workflow isn't working on your computer. I'm a bit too busy to try to work on debugging another's project (I'd have to figure out exactly what it's doing and how, and I'm working on a really big and overly time-consuming Alfred project right now). I'd suggest contacting the Workflow author to see if they could provide a fix for it. Otherwise, the layouts Workflow that I pointed you to is really great. Actually, I had written one of those on my own (I hadn't released it), but the one that I pointed you to made mine look paltry enough that I stopped developing it and started using that one instead, which seems like the way to go. Sorry that I can't be more of a help right now. Shawn

Not sure if this is the problem, but... If you're invoking Growl via a command script rather than having it as an "output" in the Workflow, then you have the potential to get many instances. If your workflow is running with a script filter, then it gets executed quite a few times, so if there is a growl notification triggered within that script filter, then you'll get way more than you want. If that's not it, then I'm not sure what is...

It should be ready out of the box, but it would be better to ask this question in the announcement for that Workflow itself so that the author can see it and help you out. (Here's the thread: Layouts) Just as a guess to your question: to use a workflow you need to use either a hotkey or a keyword. The keywords are set within the workflows (so, for the layout one: open Alfred and type "lay full" then, after you press enter try it again with "lay left". All the hotkeys are stripped when you initially install the workflow, so if you want to use them, you'll have to set the hotkeys yourself. If that doesn't answer your question, just head over to the thread above and post there. All of these are written by users just like yourself, not the kind folks who wrote Alfred, so Andrew (the genius behind Alfred) won't be able to help you troubleshoot individual workflows, but the authors can, and the author of the layouts one is a super nice guy who is also really helpful, so just ask the question there. You'll find that most of the documentation on creating Workflows and about how they work are contained in these forums. I'm working on a way of centralizing everything so that we can keep all the great knowledge and work that everyone has done so far.

I really hate how I have to enable accessibility on all these applications now... Just venting. Looks nice. Could you include an option just to open the terminal in the current finder window? I love doing that.

Check the arguments in the command itself. It has these: i -- prevent idle sleep d -- prevent display sleep s -- prevent system sleep u -- emulate user activity (this means that you computer will stay awake even if the lid is closed... be careful if you're on a laptop). m -- prevent disk sleep (mavericks only). Check the command issued in the workflow to make sure that it has "d" in the options. Generally, when I invoke Caffeinate I use: caffeinate -di -t <TIME> & That's my preferred method. Not to hijack, but I just came across this thread as I was posting the second version of my old caffeinate workflow. I won't link, but you can find it on the forum. --Shawn

Update: rewrote the entire thing as a bash script. It's much faster now. All the links are the same. Grab it if you want. Let me know if there are any bugs. (I couldn't find any). Caffeinate Control v2 v3 I just pushed a major update to my old Caffeinate workflow, and I figured I'd just start a new thread. It is a complete overhaul. Find version 2 3 on Packal.org: packal page. Option Configuration You can configure how you want Caffeinate to work for you. Do you want to keep the system awake? Just the display? Everything? Just type "caff configure" (or "caff c"), and you can set the options easily. If you want to change how it works later, then just run the config again. Change however frequent you want! Defaults We default to "i" or just to keep the system from idling (which lets you display turn off). Just run the config and choose more options to as you please. Multiple options are available by pressing cmd while clicking. Commands Just type "caff" to get started. It will tell you the status and give you the most relevant option first. Example Arguments "caff e" enables caffeinate indefinitely "caff d" disables caffeinate "caff 15 2" enables caffeinate for 15 hours and 2 minutes "caff 23" enables caffeinate for 23 minutes "caff 2h" enables caffeinate for 2 hours "caff configure" opens the configuration dialog "caff help" opens the help dialog. Here are some screenshots: Shows the status left in hours / minutes, depending on how much time is left. You can also see the configure and help entries in the bottom. I need to get around to uninstalling caffeine because I don't use it anymore. Configure the behavior of how you want it to sleep. Just select the options and press "Set Options". If you input one number, it defaults to minutes. If you put in two numbers, it interprets as hours and minutes. You can specify with arguments too. Feel free to type out the whole words "hours" or "minutes" or whatever part of them you want to. Here's the help, explaining it a tiny bit more. Click on "More Info..." to be taken to the caffeinate man page. If you get really excited about typing a lot of minutes, then we'll still let you know how many hours that is... (edited to add more pretty screenshots.)

Thanks, Tyler. Also, if anyone knows how to optimize nginx configurations for high traffic site better than I do, please contact me! Shawn

One way to "force" the configuration on first run is to use a script filter. Then you can check to see if a "first-run" file exists in your data directory. If it doesn't, then you can present the user with only the option to configure. If you need more interaction than a script filter would provide for the actual configuration, then I'd recommend using some applescript dialogs. I do think that it's a good idea not to install anything on the user's computer without letting them know and giving them the option to just delete the workflow instead of installing. If you do install something, then you should probably put it in the data directory, and, if you want to get fancy, then add in an "uninstall" command to remove those components.

I never know how to feel about writing a background daemon for these sorts of things as Alfred workflows. The point of Alfred is to invoke things manually. Writing a daemon is really more of writing an application, and so packaging it as a Workflow is possible, but, again, I'm not sure if it should happen. Although, if you do want to make it happen, then you'd need to do a few things: look at this stackoverflow discussion. That would make it so that it really isn't a daemon that runs all the time, but, instead, it would be a script invoked at certain times. For the workflow, you'd probably want to put in an "install" command that would copy the relevant file that is packaged with the Workflow to the relevant place (if you're using launchctl). If you're using Cron, then you'd want to write an entry to the crontab, but you'd also want to make sure that it doesn't add in the line multiple times because, then, the command would be run too often. I'd recommend invoking the install with an applescript so that you can put in the line "with administrator permissions" or whatever it is exactly. Otherwise, you'd have to use 'sudo'. If you want to run it as a daemon, what you can do is to write a bash script that runs the script and receives the output and then sleeps for however long you want it to sleep. When you do this, make sure that you 'disown' the process. Otherwise, an Alfred thread will be continually running, which will interfere with Alfred's normal functioning. Include a command to kill the daemon. Also, make sure that the daemon isn't launched multiple times (you can use 'ps aux|grep <daemon name>|grep -v grep'; then, if there is any output, it'd mean that the daemon is running and not to launch it again. To kill it, instead of finding the process, you could just invoke the "killall" command in which you'd just send "killall <processname>". This setup would make it so that Alfred would have to launch it and kill it. So, it won't be started each time you reboot your computer. If you want to do that, you'll have to include it in the start-up items (which I think is a bit harder with Mavericks). I'd also recommend putting in a "status" command with Alfred to see if the daemon is running. For the notifications, you have a few options: you could write an applescript that will send a dialog whenever things are low. However, this will be intrusive. You could also invoke growl to send the messages (this requires a tiny bit of configuration with growl and you can't assume growl is installed). The third way would be to package the ruby gem 'terminal-notifier' which creates regular notifications. You'd just invoke the script and make the notification sticky. So, with this approach, the Alfredworkflow would just install and manage the daemon or cron job. You'd also want to put in an uninstall command (especially if you're using cron, and you'd want to have an automatic uninstallation feature if the workflow is deleted). But, again, I'm uneasy about using Alfred to write daemons. Temporary ones are fine (think of a timer that works similarly to what I've outlined above, but one that stops itself after a certain amount of time), but daemons that become a perennial part of your system just seem like something that is entirely different than Alfred. Lastly, if you do write something that includes a daemon that runs permanently, then I believe that you should make it clear and explain how the daemon works when you release the Workflow. That way people know what you're putting on their computer. --Shawn

Well, this isn't a Workflow to be shared, but I figure that this is the most appropriate place for this post. I've been developing a robust repository for Workflows and Themes, and the site itself is ready for testing (there is a companion Workflow that still needs further development, and the site won't be made public until the Workflow is ready). I've been in conversations with Andrew about how best to go about it, and, so far, he seems pleased (but, there is no official endorsement). So, can you help test it out for me? I'm especially looking for people who will contribute Workflows and/or Themes so that the more advanced, and breakable, aspects of the site can get better testing. If you're interested, send me an email at rice [-at-] shawnrice.org, and I'll direct you to the site. Please do so only if you're willing to send me feedback about what needs to be improved and about what might break. -- Shawn

Glad you like the idea. I haven't completely forgotten about this project, but currently, for my Alfred projects, it's behind one major one that should be released soon. Version 1 of WHW was a great idea, but it does suffer from usability concerns, and these were in part due to the way that I decided to generate the help files. I've since figured out much, much better ways to go about it, and I have some of the framework done for a better version. The next version won't use quicklook (well, I might have that as an option but not the default); instead, it'll use a custom viewer as default with other options of opening the file in a browser window and generating it as a PDF and opening it in Preview. Instead of generating markdown files, it'll instead generate richer HTML pages with quite a bit of javascript that should make navigation and layout much better. It'll have the option to just view one workflow as well as all of them. The plist parsing will be done quite a bit better for more accurate results. It will also allow workflows to define their own help files for richer content. If the help file exists in the workflow folder, then it will use that, and it will fall back on plist parsing. The workflow will also include an easy help generator for workflow authors so that they don't need to write out xml/json/plist files by hand. Lastly, it'll have a nice speed increase by "caching" the help files and regenerating them only when it senses that a workflow could have changed. I don't have an exact timeline to finish it, but it should be pretty sweet when the new version sees the light of day. Shawn

In order to avoid bloat, it seems like it would be better to write a different workflow to open a window on another desktop / display. This workflow is perfect for moving windows once they're opened, but what you're asking for seems to be a completely different feature, albeit one that would complement this one well. Subject22, maybe you could take a shot at writing it up for all of us?

So, I'm trying to write a workflow, and my life would be so much easier if I could launch a php-fpm daemon for just a minute or so. I just noticed that it's native on at least 10.8. Does anyone know if it's there for earlier versions? (Mostly 10.7). The executable is at /usr/sbin/php-fpm

It's probably not Chrome itself but an app that I installed inside of Chrome. When I get a chance, I'll look through those and see which one might be screwing it up.

Yeah. It's a Chrome thing. (I should have checked this before posting the last one). When I switch my default browser back to Safari, then it works just fine. So, I guess this isn't a bug. Andrew, Vero, just ignore this thread.

Still happening for me... So, then it's a real puzzle if it's working for you when it's not working for me. Damn. I thought that it would be a quick fix. My setup probably has some other quirky-something-or-another going on then. I'll look more into it on my end. Maybe it's a Chrome thing (are you using Chrome?), or maybe it's a Chrome app that I installed. That might make sense.

I think the URL for the Google Images search is broken. All the other search ones that I've tried work. I type "images test" Alfred send me to "https://images.google.com/images?q=test" I get a 404: "The requested URL /images was not found on this server." So, the URL probably just needs to be switched out. OS X 10.8.5; Alfred v2.0.9(214) --Shawn

Sounds great. I'll check out the Ruby Version. There are a couple of very inelegant hacks that you could do with Applescript in order to put it into Fullscreen Mode. The first would just be to place the clicker in that upper right hand corner of the window that has that little fullscreen icon, send a mouse click, then reposition the cursor where it started. But, that's awkward. Another thing you could do is to have it send a ctrl+cmd+F keypress, which seems to be the hotkey for at least a few programs to enter into Fullscreen (often in View->Enter Full Screen). But that just seems unnecessary as it already has a hotkey, so you could also consider the Full Screen as an unnecessary feature... Shawn

I ran into that same issue with the delays, but I never noticed the Python Launcher.app showing up. The delays made me go back to using one that I wrote with Applescript that is sometimes wonky (I never ironed out certain bugs) but doesn't have those delays.

This looks great. Do you want to share any of those cheatsheets that appear in your workflow? They look appealing.

For 10.8, there is a workaround. If you put in the sudo command before the `networksetup` command, then it can work seamlessly without needing a password as long as you follow the instructions that I pasted below (it's part of a commented bash script I wrote). # If you want to avoid putting in a password, then make sure that the # sudo variable below is uncommented. AND add the following line # to /etc/sudoers (sudo nano /etc/sudoers) -- type in your pword at the prompt # USER ALL=NOPASSWD:/usr/sbin/networksetup # "USER" needs to be replaced with your username (or the username of anyone # who uses Alfred2 and this workflow.)

Looks neat, but the link is dead. Can you reupload it?