CarlosNZ

Hi

 

I can't get the "movedrawer" function to work. I never get the path select dialog appear suggesting something is going wrong with calling the Applescript function.

 

I've manually updated the config file with a custom path and then all appears to work, so the basic feature of having a custom drawer appears fine, just not the workflow to define it. 

What version of OS X are you using? I've had it working on both Lion and Mountain Lion for me.

Nope, it's a limitation of Notification Centre unfortunately. I asked about this myself some time back. If you need longer, then use Growl instead. Sorry for being the bearer of bad news.

(On the plus side, it provides good practice at brevity )

Thanks for the feedback guys.

I've updated it to 1.1 with the following changes:

• Fixed the problem with cities with half-hour UTC offsets (eg. Adelaide—UTC+10.5, New Delhi—UTC+5.5
• You can search the list of displayed cities (useful if you've got a lot) — just start typing after the "tz"
• Hotkey to launch the list (set to Ctrl-Z by default)

Ignore. Replied to wrong post.

It's not ideal, but you could make your File Action script prompt the user with an AppleScript-based dialog prompting the user for additional text.

I've realised that this fails on cities with non-integer offsets (eg. Adelaide, UTC+10.5 and New Delhi, +5.5). Will put out an update to fix this later this weekend.

Here's another little tool I've just whipped up:

Get an instant list of the current time in various cities around the world. Which you can customize, of course.

• Main keyword: tz (for TimeZones) - this just shows the World Clock list (seen above). (Select a city for a Large Type display.)
• To remove a city from the list - option-select it.
• To add a new city - timezone add Name of City
• To update all cities' timezone offset information - timezone update
• To look up the time in a place without storing it (custom loookup), just keep typing the place name after the initial tz (eg. tz timbuktu)
• To move the location of your stored city list - timezone move

Download v1.7a

This workflow saves a list of your cities and their UTC offsets locally, so the basic world clock will display instantly. Adding new city information is done via an API call to Google Wolfram Alpha. The only downside to locally cached offsets is that there's no provision for automatically updating for Daylight Savings changes, but a manual timezone update will refresh all the cities with their current offset.

Enjoy. As usual, I welcome comments, bug reports, feature requests, etc.

----

28 March 2013 - UPDATE to v1.5

• Major rewrite - now uses Google Maps APIs, which should be a lot more reliable and consistent.
• Flag icons! Bit of eye candy, courtesy of http://www.free-country-flags.com (and managed to squeeze flags for every country in the world into just over 400k - thank you TinyPNG )
• More detail retrieved and displayed, including timezone name, country, etc.
• When doing a full "update", a text file is saved to your Desktop summarising any changes found.
• General enhancement and tweaks.

PLEASE NOTE: Because this version stores its data substantially different to previous versions, it will create a new timezones.txt file with default cities. However, it will attempt to save your old timezones.txt file to your Desktop, so you should be able to rebuild your previous list without too much hassle.

A quick note about the flags: The workflow simply compares the retrieved name of the country and does a simple name match against the workflow's local repository of flag icons. From my testing, it's working very well, but I'd appreciate it if you'd report back if you find any countries that don't properly match a flag icon. Cheers.

----

31 March 2013  - UPDATE to v1.6

• New feature: Custom lookups. Just keep typing a new place name after the tz keyword to look up the time in a place without saving it to your saved list.
• Added support for phyllisstein's Alleyoop auto-updater.
• [EXPERIMENTAL] - support for autocomplete for adding place names (timezone add). You'll need to add a keyword yourself to the script filter if you want to try it out. The reason I haven't enabled it by default is that I've found it kind of slow and I'm not sure it's actually an improvement over the current method. Let me know what you think.
  [Add a keyword to this script filter if you'd like to try it out]
• Novelty: Added (unofficial) Antarctica flag to flag repository. (Try tz south pole.   )

----

2 April 2013 — UPDATE to v1.61

• Small fix for Dutch (Netherlands) flag matching.

----

22 March 2014 — UPDATE to v1.7

• City List now always shows in the same order. (Achieved by removing “uid” parameter.)
• Removed Alleyoop updater.

----


22 March 2014 — UPDATE to v1.7a

•     New 256x256px icon

v1.2 - Move your DeskDrawer!

Was fairly simple, because I was able to mostly just copy-paste what I needed from my Time&Date Strings workflow. Let me know how it goes for you. The default keyword to move your DeskDrawer is "movedrawer".

I would stress that you might want to check your files are backed up first. While I'm pretty confident it'll work just fine, and I've tested it thoroughly myself, I would hate for someone to lose something important just because I forgot to close a bracket somewhere.

Hi Carl - great idea; I can see this becoming a part of my daily flow as I already do similar but manually using standard Alfred file actions. Good template too for how to create a pretty comprehensive flow too.

 

My primary request would be the customisation of the DeskDrawer folder. The current location is not indexed by Alfred and so the contents won't show in regular searches - while I can update Alfred's search scope, I'd rather not have to, plus I could also host the folder via Dropbox to sync the data between machines.

 

In the short term, I guess I just need to update the includes.sh file and  "deskdrawer="$CDWD/DeskDrawer" variable to manually change location?

 

EDIT: Found that changing $deskdrawer works if I manually create the deskdrawer folder - the check for the folder existing, and creating if not, it needs to be updated. Otherwise seems to work fine

 

Thanks again - great flow

Thanks for the feedback. Good point about the current location not being indexed by Alfred; I didn't think of that. So yeah, I'll make the ability to move the deskdrawer folder my No.1 priority.

Cheers.

Small update to take advantage of the new "Browse in Alfred" Action, rather than doing it clunkily with Applescript.

By the time v2 is finished (if I get time), if you set a bundle ID, the folder will be the same as the bundle ID and not a generated UID

Great. Just what I needed to know. Thanks Andrew.

Edit: Apologies. I only just noticed that the workflow forum has been split into two. This should really have gone into the other one. My bad.

[Mod: No problem, moved it over for you!]

FYI - you can use KeyRemap4MacBook to remap the eject key and then use AppleScript to trigger the new key. (Despite the silly name, it's not just for Macbooks).

I've had KR4M installed for a while now (to give me a forward-delete key), but I never actually realised quite how powerful it can be. In fact, I daresay that pretty much every hotkey related feature request I've seen on this board could be achieved with it.

I guess this is a question that only Andrew can answer, but maybe David F or Vero might be able to weigh in.

I just wonder if someone can confirm whether the folder that the workflow installs itself into is a random string, or is there something more systematic to it? I know that now, whenever I install/uninstall/re-install a workflow, it gets put into a folder like "user.workflow.155A5E43-853F-41C3-B8F4-AE4CF9C84992", and it's different every time, so it seems random. I'm just wondering if this is how it is always going to be, or if the final 2.0 release intends to "standardise" this so that the workflow folder name gets generated from the bundleID, and so will always be the same for re-installs of the same extension.

It's just that I've noticed with my EggTimer workflow, I've made it generate a config file (stored in Application Data/....etc.) that stores the workflow's location so that certain other routines will be able to find the scripts. However, if I delete then re-install the workflow, this config file is now wrong and some things don't work. I guess what I'm asking (in my roundabout way ) is: should I bother adding in some extra code to check this path and update it if necessary, or will this be a non-issue in later releases?

Of course, if deleting the workflow in Alfred also deleted the working folders (which it probably should, and I believe Andrew said something to this effect somewhere), then this won't be a problem either. Would be good to know what the plan is here.

Just wondering why you use the "Public folder" in Dropbox? - it's a deprecated concept: https://www.dropbox.com/help/16/en

You can create a shareable link from any file or folder in Dropbox.

Why do you use the "Public folder" in Dropbox? - it's a deprecated concept: https://www.dropbox.com/help/16/en

You can create a shareable link from any file or folder in Dropbox.

One tiny suggestion — make the keyword argument "optional", and just give the file a generic name if the user doesn't specify one.

Great stuff. Works really well. Make sure you upload it to the Alfred Repository so we can get auto-updates and the like.

This will be very handy. I've started "bundling" simple one-command workflows (like Relaunch Finder and Toggle Hidden Files) into one big System Utilities workflow, so my workflow list is a little tidier. Copy-Paste within the workflow editor will make this a lot less fiddly.

I have caps lock set to cmd-opt-control-shift.

That's a good trick. I must remember that. Do you hold it it down, or just toggle it on or off? And what app do you use to remap the CapsLock key?

You look like you're already well down the track now, but FYI — the bash functions "pbcopy" and "pbpaste" are exactly what you need to interact with the clipboard without resorting to Applescript.

You can remember those insane hotkey combos, but not the apps they're set to open?

Just kidding, I agree, it would be a nice little convenience if it showed this info.

Thank you! I admit that I'm reluctant to do that, but I'll take it under advisement and if the general feeling is for the change then I'll make it. I often like my plaintext files extensionless, and it I think that makes sense on a UNIX system, but as I said, if the collective user-will makes itself felt, I'll bend.

Great! At least one vote for a default extension.

Yep, count my vote for default ".txt" as well. Why don't you just set the default extension in a config file and then the user can set it to what they want?

You want to know my dirty little debugging trick I use for shell scripts? I drop in Growl notifications (via growlnotify) when I want to check that the script is going where I want it to (following the right "if" options, etc.) with the variables assigned as expected. I'm sure seasoned programmers would look down their noses at such nonsense, but it works for me, for now.

What you can do (I've just done it in a new workflow) is use Applescript to load the chosen item back into Alfred's text field. It's not perfect, but it's a pretty good stopgap solution:

tell application "Alfred 2" to search "{query}"

There is a workflow called "Background command" in the Alfred repository. Have a look at their script and see how they've dealt with this issue.