dfay

You'll have a much easier time debugging if you write the scripts in Script Editor, verify that they work there, and then move them into Alfred.

Since a couple of people have asked about it, here's a (functional but ugly) rough cut at a Mission Control / Spaces workflow: https://www.dropbox.com/s/bem2k9a0eufaraf/Apps%20and%20Spaces.alfredworkflow?dl=0 It just uses Applescript to type keystroke commands, so if you've modified your keys, it may have unexpected results. I'm not going to have time to work on this in the near future, but if anyone wants to run with it (find some nice icons, figure out how to get command-tab working, etc.) feel free.

Looks like you found the other post on sending keystrokes. FYI if you don't need a modifier, you can just use a Clipboard Snippet.

Yeah, I'd second Shawn's sentiment - it's best to only use UI Scripting in Applescript when there is no other alternative. It can be fragile, esp. if users have customized their keyboard shortcuts at all.

Brilliant. I had tried that but I had the second tell command inside the first one. With the code reordered as you suggest it works perfectly. Interestingly it lets you quit the Finder, rather than restart it.

Following are some Applescripts that allow Alfred Remote to control the zoom on your screen. First go to System Preferences > Accessibility > Zoom and make sure "Use keyboard shortcuts to zoom" is checked. You will probably also want to check the Smooth images checkbox. Then for each of the following scripts, go to Alfred Preferences > Remote > System Commands (or wherever you want on your remote) > + > Run Script > language: /usr/bin/osascript then paste in the corresponding Applescript. Zoom In: tell application "System Events" key code 24 using {command down, option down} end tell Zoom Out: tell application "System Events" key code 27 using {command down, option down} end tell Toggle Zoom: tell application "System Events" key code 28 using {command down, option down} end tell These scripts are pretty trivial but it took me a bit of searching to realize that using Applescript's keystroke command doesn't work, but using key code # does.

Yeah....but I was hoping to do it without needing to name the app. The first script works on the frontmost app regardless of what it is. Creating a quit script for every app I might run is a little impractical

You can also add Advanced Commands to Dictation via Automator workflows in Yosemite (see http://www.macworld.com/article/2834532/ok-mac-using-automators-dictation-commands-new-in-yosemite.html for an overview). Here are a pair which add commands to Hold and Release the Control key (useful for Alfred workflows that offer options when Control is down). (I also describe how to do this from Alfred Remote here: http://www.alfredforum.com/topic/5414-sending-keyboard-modifiers-ctrl-etc/ ).

You can hold and release the Control key (and others) via Applescript as well: http://www.alfredforum.com/topic/5414-sending-keyboard-modifiers-ctrl-etc/

A lot of Alfred workflows and commands have options when certain keys are pressed. These keystrokes can be sent from Alfred Remote with a bit of Applescript. e.g. to hold and release the Control key, add the following: Alfred Preferences > Remote > System Commands (or wherever you want on your remote) > + > Run Script > language: /usr/bin/osascript then paste in the following short Applescript: tell application "System Events" control key down end tell Name this item "Hold Ctrl" but BEFORE YOU TEST IT add a second command following the same procedure: tell application "System Events" control key up end tell Name this 2nd item "Release Ctrl". Now you can test it and make sure it works. If you test the first script before adding the second, you will end up with a practically unusable computer b/c the Control key will be down and you will have no way to release it. I found this out the hard way and had to reboot. IMPORTANT - this does not work with the Option key for reasons that are unclear. You can create an Applescript to hold the Option key down, and it will work, but the corresponding script to release does not work, and you'll be forced to reboot to get your keyboard working normally again.

Alfred Remote combined with Apple's built-in Dictation seems to have amazing potential. First, set up the following script in Alfred Remote: 1. Start Alfred Preferences 2. Click Remote 3. Click System Commands (or wherever you want to put the commandon your remote) 4. Click one of the + signs on the grid 5. Select Run Script from the pop-up menu 6. In the window that opens, set the Language drop-down to /usr/bin/osascript 7. In the script field, paste in the following short Applescript: tell application "System Events" -- mute volume while dictating, or turn it back on when done -- optionally one could add commands here to play/pause iTunes etc. here set myVolume to get volume settings if output muted of myVolume is false then set volume with output muted else set volume without output muted end if -- toggle dictation key code 63 -- fn key code 63 end tell I then added this icon as well: https://ntk.me/assets/img/2012/12/17/dictation/icon.png Second, if you don't have it enabled already, turn on Dictation and enable Advanced Commands as described here: http://support.apple.com/en-us/HT203085 Now you can use Alfred Remote to turn on Dictation, Show Alfred (or your custom search, workflow, etc.), speak your search terms, (optionally edit as necessary with advanced dictation commands), then speak the command "Press Return key". Magical. Now....this could be even more awesome if Alfred could turn on Dictation then redirect the iPhone microphone to the Mac audio input...then I could stand at the back of my classroom with 500 students and run my laptop on the podium....

Alfred Workflows currently have the debug icon which gives options for logging the actions taken by scripts etc. Alfred Remote gives the option to Run Script or Run Applescript, but as far as I can tell, there's no way to open the debugger. This came up in my other post today where one script works, and another virtually identical script doesn't....I'd love to be able to see the debugger to have a better idea why. Could the debugger be added in a future release?

Simulating keypresses is easy with Applescript -- see the script I just posted to close a window for an example.

After a few minutes of using Alfred Remote to launch apps on my Mac, I quickly realized I'd also want a way to close windows and/or quit apps. Closing windows proved to be easy: Alfred Preferences > Remote > System Commands (or wherever you want on your remote) > + > Run Script > language: /usr/bin/osascript then paste in the following short Applescript: tell application "System Events" keystroke "w" using {command down} end tell I then added this icon as well: http://icons.iconarchive.com/icons/oxygen-icons.org/oxygen/256/Actions-window-close-icon.png Once I had that working, I used the same steps to try to quit the frontmost app instead of closing it. I tried this script: tell application "System Events" keystroke "q" using {command down} end tell and this one: tell application "System Events" set theName to name of the first process whose frontmost is true tell application theName keystroke "q" using {command down} end tell end tell without success. neither does changing the keystroke in the second block to quit. I realize this is more of an Applescript question....but it raises Alfred Remote script issues that I'll bring up in another thread.

After all the excitement over Alfred Remote wore off (or dissipated enough to think clearly), I noticed this in the release notes of 2.6: "New Script Filter runtime behaviour options giving more control over when scripts are executed"

There's currently no way to link one workflow to another. You could reverse-engineer that workflow and copy its code or figure out how to call the scripts in the package directly. But I'd recommend spending $9.99 for Moom and doing this: http://www.alfredforum.com/topic/1891-moom-and-launching-apps-files/ I set it up for exactly the kinds of scenarios you describe.

Cool. I'll try to get PySerial (or some other serial port library) working instead. I didn't find an OS X version of PySerial but I didn't look that hard.

Cool, thanks for the update. What language are you working in? I messed around a bit last week and came with an Applescript function to send a message and get the reply, using the Serial Port X scripting addition. I figure if you are targeting / working with a device accessed via Ethernet I'll need to do some customization to make it work with the serial port in any case. (9600, 8, n, 1 ... Now that's a name I've not heard in a long time. A long time....)

Ok...just in time for Christmas...I have the cable & drivers working and can echo commands to the driver and have the Onkyo respond appropriately.

You can do this already with an Open URL action in a workflow. Create a new blank workflow, then using the plus sign in the upper right > Actions > Open URL

Seriously....I was going to chime in and suggest using System Events but I would never have known about the sqlite database.

You'll need to use Applescript UI scripting, i.e. write an Applescript that clicks the button, then call it from the workflow.

Here are a couple other useful resources: applescript - How to know the name of UI elements using Accessibility inspector (or any other tool) - Ask Different Finding Control and Menu Items for use in AppleScript User Interface Scripting - Mac OS X Hints

Well I dug through the garage and found a female RS232-USB adapter but no male and no gender changer. So I had to order a new cable. I'll give it a try once that arrives.

I have a Onkyo TX-SR806 that I inherited, and have barely checked out what it can do. Looks like there is an RS-232 port for automation so presumably I'd need a cable to go in there & connect to USB on the Mac? i'm sure I have one somewhere, deep in a box in the garage.... This looks helpful: http://www.xlobby.com/forum/viewtopic.php?f=25&t=6020 I don't see my unit listed there but the SR805 is and the commands look pretty standard. The linked spreadsheet with commands there is from 2007 but I think the SR806 is a more recent model....it looks like the protocols are basically unchanged from one to the next so I expect it would work. So, yes, I'd be interested, and happy to work with you on testing if needed.