Jump to content

ctwise

Member
  • Content Count

    307
  • Joined

  • Last visited

  • Days Won

    23

Everything posted by ctwise

  1. This probably won't work either then, but you can give it a try: property newLine : (ASCII character 10) set results to "" set flag to true tell application "System Events" tell network preferences to set locs to every location repeat with loc in locs tell loc set vpns to every service repeat with vpn in vpns if flag is true then set flag to false else set results to results & newLine end if set vpnName to (the name of vpn) as string set results to results & vpnName set results to results & "|" & (kind of vpn) end repeat end te
  2. Vote for this - https://remotedesktop.uservoice.com/forums/287834-remote-desktop-for-mac/suggestions/9280833-allow-the-application-to-be-controlled-with-apples The workflow breaks constantly due to having to script the GUI - Microsoft keeps making GUI changes and throwing up dialog boxes. Until Microsoft makes the app scriptable the workflow will remain buggy.
  3. Yeah, since the AppleScript is busted, you have to use the command-line. You can get the connection status of a VPN using this command-line: scutil --nc show "<vpn name>" | grep Disconnected > /dev/null That returns an exit code of zero if the VPN is disconnected, anything else and the VPN is connected. You can start a VPN with this command-line: scutil --nc start "<vpn name>" And stop it with this command-line: scutil --nc stop "<vpn name>" So a Ruby script to toggle the status of a VPN connection would be: vpn_name = ARGV[0] status = system("scutil --n
  4. Thanks to _patrick, I have updated my VPN workflow to work correctly on El Capitan. If you've upgrade to El Capitan and your VPN workflow no longer works - try this one - http://www.packal.org/workflow/vpn-toggle
  5. Looking for info from anyone on this issue. Pulling VPN info using AppleScript appears to be broken in El Capitan. Most services have an empty (null) value for the current configuration. So you can't determine connection status.
  6. This might help - http://www.packal.org/workflow/menu-bar-search
  7. I just updated the workflow on Packal to add remote triggers.
  8. I suggest using the new queue setting to terminate the script filter when a new keypress is received. It shaves a few microseconds off when typing, not a big difference but definitely adds a snappier feel.
  9. Very, very, very few workflows will benefit from compilation. Most workflows actually _do_ very little work. If a script takes 100 milliseconds and a compiled version takes 10 milliseconds, you won't be able to tell the difference. The exception is when your workflow takes seconds to run _and_ the reason for the delay is computation, not network lag. A much more likely reason for compiling code for a workflow is that it's the only (or easiest) way to interact with something in OS/X.
  10. Yep, it's well and truly broken. There's no longer a search so there's no way to narrow down the items and select one programatically. Crap. On the other hand, it looks like 8.0.6 has full URI support now. It's possible I can generate the RDP URIs and use those to connect. It won't be for a while though.
  11. Yep, it's one of the downsides of UI scripting instead of true AppleScript support from the app. I put in a feature request on the Microsoft support site but I'm not holding my breath.
  12. Awesome! I added it to the workflow.
  13. You are correct. The only way in Alfred to act on selected text is through a hotkey. Otherwise the Alfred input box becomes the text source. I'll update the workflow.
  14. It's the upgrade notice dialog box that comes up. Start the RDP app directly and dismiss the dialog box. Everything will go back to normal. You can thank: 1. Microsoft for displaying the stupid box. 2. Microsoft for not supporting Applescript in the app. 3. The brittleness of UI scripting since there's no Applescript support.
  15. If you're using the latest Alfred, can you turn on workflow debugging and see if you see any output?
  16. I just tested the workflow and it's working fine here. The only thing I can think of is your cursor isn't somewhere that allows pasting.
  17. Yet another RDP workflow. This one works exclusively with Microsoft Remote Desktop and lists all of the defined desktops. It works reliably, regardless of the state of the Microsoft Remote Desktop application, this has been a problem with other workflows. You can select from the desktop list or continue typing to filter down to just the desktop you want. It's on Packal already. https://github.com/packal/repository/raw/master/com.tedwise.rdp/microsoft_remote_desktop.alfredworkflow
  18. And you can find one that was already there - http://packal.org/workflow/network-info That one works for all interfaces including VPN tunnels.
  19. The plutil parsing of com.apple.LaunchServices.plist fails on my system with an error "invalid object in plist for destination format". My file contains a '<data>' field for the LSHighResolutionModeIsMagnified key.
  20. He's looking for a workflow that will tell him the manufacturer of a device based on the MAC address, e.g., 'b8:f6:b1:00:00:00' => 'Apple'.
  21. Funnel takes text and converts it to some other text by running it through a filter. The filter can be a shell script one-liner or a full script. Anything that takes standard input and outputs to standard out. At the moment, the following filters are implemented: - Base64 - decode - Base64 - encode - AES-256 - decrypt with passphrase 'X' - AES-256 - encrypt with passphrase 'X' - x509 - fingerprint - x509 - hash - x509 - certificate information - Change case - lowercase - Change case - uppercase - Change case - capitalize - Change case - title case - JSON - format - String - reverse - Stri
  22. It looks like there's a second file - ~/Library/SyncedPreferences/com.apple.finder.plist - that has a list of all of the "pure" tags, e.g., not a label that acts like a faux tag. Unfortunately, this list is only updated by Finder when you assign a tag to a file through Finder. If you tag a file and never interact with it through Finder then the tag doesn't show up in this file. Still, if you merge the contents of both preferences lists you'll get closer to a comprehensive tag list.
  23. Here's something you can experiment with. - Use Homebrew to install 'tag' (https://github.com/jdberry/tag/). - Create a test file and tag it with a tag that's not in use on your system. - Create another test file and go to Finder. Bring up the info view and click in the tags area. If you start to type the name of your test tag, it'll autocomplete. Finder knows about it. - Look in the com.apple.finder.plist. The tag isn't in there. So _something_ is monitoring tags and keeping a running list of tags used on the system. It might be just in memory but I don't think so, because the lis
  24. I wish I had a suggestion as well. :-) I was looking for exactly this a while back and the only reliable way I found was to brute force it, extracting tags out of every tagged file then collating the results. Obviously Finder has a way to get that list, so somebody needs to trace Finder and see where it's pulling that list from.
  25. I applaud your ingenuity in using the Finder prefs to find all the tags, but that doesn't list all the tags on the system. It's a subset.
×
×
  • Create New...