Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


kopischke last won the day on November 16 2013

kopischke had the most liked content!

Contact Methods

  • Twitter
  • Website URL

Profile Information

  • Location
    The Internetz

Recent Profile Visitors

1,014 profile views

kopischke's Achievements


Member (4/5)



  1. Nope, Google changed their API, the current workflow will not work anymore. The good news is: I’ve patched my workflow to use the new Google Translate URL syntax; the basic functionality, i.e. single term translations, is thus functional again. Being rather constrained for time, I will leave implementing a multi-sentence patch to the reader (PRs welcome, external interpreters need not apply). Grab the revised workflow at the repo. Thanks to Shawn Rice for the above link, and to GitHub user @g0to for bringing this to my attention. In the future, please follow their example and open an issue on the repo for problems to ensure I can react swiftly – I barely ever visit the Alfred forums, but I keep close tabs on my repositories and their issue trackers. EDIT: just pushed a quick update that fixes handling of multi-word (not multi-sentence) translation queries, which I broke when refactoring for the new API. Apologies to everybody who suffered from that – please download the updated version.
  2. Would be interested in hearing about this too. I’m using Jens Kutilek’s system font version of Fira Sans as my system font, and Alfred now sticks out like a sore thumb… I understand portability is an issue for arbitrary fonts in themes, but could we get an option to use the system font no matter what, maybe?
  3. You can safely shorten that to “It only works on Mavericks” and stop worrying about the SQLite3 gem dependency, as Apple is taking care of the issue for you: SQLite3 it’s part of the gems included in Mavericks’ system Ruby install, along CFPropertyList and Nokogiri: do gem list on a pristine Mavericks install, or gem which --all sqlite3 if you already installed gems of your own .
  4. Just for the record, Paul Kim, the developer of Hazel, struggled with the exact same issue when updating Hazel to manage Mavericks tags (I should know – I was the one reporting the issue to him ). AFAIK, he ended implementing the exact same solution…
  5. Sorry for not answering earlier, I haven’t been around the forums for a while… Short answer, I’m afraid, is no, not with this workflow, as the underlying utility does not support per monitor sleep.
  6. Just a hint: if any of the posters with problems happen to be running OS X in another language than English, the AppleScript will not work, as it searches for the relevant menu item by name, which, of course, is localized. If that is the case, the fix is easy: check your Finder and see what your window menu is called, and what the menu item to merge windows is called, then replace the second and third argument of the click_menu call on line 2 of the AppleScript action of the workflow by the localized versions. For instance, for German, replace click_menu("Finder", "Window", "Merge All Windows") by click_menu("Finder", "Fenster", "Alle Fenster zusammenführen")
  7. Absolutely. Brainfart of mine, corrected. Re-download or update via Alleyoop.
  8. Um, I’m not quite sure where you got the sleepDisplays command from? It’s not part of the default OS X set of CLI commands…
  9. Sleeping the Mac display is the fastest way to lock a machine if a password is set. Unlike switching to the login window (Alfred’s default strategy when using the lock command), all your apps keep running, enabling continuous operation of tools like Dropbox, Hazel or EventScripts, and even quasi-magical unlocking with Knock (if that’s your thing). On a machine whose keyboard has an Eject key, Ctrl+Shift+Eject will do the trick, but on those without, only hot corners are available. Sleep Display complements the inbuilt options by adding an Alfred keyword (sleepdisplay by default, though I prefer to disable standard locking and use lock) and an optional keyboard shortcut (unset by default). No more, no less. Grab it here, or go to the repo here. Changelog: version 1.0.1 – fixed hotkey bringing up Alfred NB: Mavericks only, as it uses a tool compiled with the 10.9 SDK.
  10. Well, actually, “Schlagworte” has a tradition in indexing contexts (albeit not computer based ones), so that wouldn’t have been too bad a a choice for either term, but not for both (and differentiating by subverting German grammar is … umh [to English speakers: it’s a bit as if keywords and tags were called, respectively, “keywords” and “keywordz”]).
  11. Yeah, it’s meant to be a dev tool, but it’s accessible to anybody with a free developer account, not just paid members of the iOS and OS X programs. The openradar mirror exists because the bug reports are only visible to the submitter, which makes it rather difficult to assess if the issue has already been noticed by others, and what patterns they have noticed… *mind blown
  12. Well, I keep hoping … and, in the meantime, filing localization related radars .
  13. Hah, looks like I jumped to conclusions when checking out your workflow, I assumed you were using the cli’s search functionality for the filter. With a file filter, adding application tags would just involve adding kMDItemKeywords to the queried fields, of course. Well done . Also, only ever so slightly OT: noticed this already?
  14. That solves it: we have run into an internationalization issue . Your syntax only works on systems configured to use English as their language, and mine is German (the correct version here would be mdfind 'Art:Gesicherte Suchabfrage'). Luckily, there is an easy way to work around this and make the workflow work no matter what the language settings: use mdfind "kMDItemContentType == 'com.apple.finder.smart-folder'".
  • Create New...