Jump to content

kopischke

Member
  • Posts

    47
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by kopischke

  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'".
  15. Gah, no, that was me being stupid – I forgot to cd to the workflow dir before testing in in Terminal *facepalm. That being said, I still do not get any results, and when testing in Terminal (with a prealable cd ) the output of python smartfolders.py <fragment of existing smart folder name> is </ items>.
  16. Smart Folder search fails for me on Mavericks (using system Python 2.7.5): Traceback (most recent call last): File "/Users/martin/Library/Application Support/Alfred 2/Alfred.alfredpreferences/workflows/user.workflow.7C3E0EAA-5F6E-480A-87CA-E1573BE3CDDF/smartfolders.py", line 22, in <module> import alfred File "/Users/martin/Library/Application Support/Alfred 2/Alfred.alfredpreferences/workflows/user.workflow.7C3E0EAA-5F6E-480A-87CA-E1573BE3CDDF/alfred.py", line 21, in <module> preferences = plistlib.readPlist('info.plist') File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plistlib.py", line 75, in readPlist pathOrFile = open(pathOrFile) IOError: [Errno 2] No such file or directory: 'info.plist' info.plist is present in the workflow, of course. I can (more or less) read Python code, but am not conversant enough with the interpreter / env internals to find out where what goes wrong.
  17. This is a nifty workflow – I noticed the utility a few days ago and have wondered if implementing a workflow based on it would make sense. This one is feature complete and well done, kudos: if you want tag management from the Alfred file browser, go for it, by all means. However, and without wanting to denigrate the workflow, if all you need is a keyboard interface to tag management, I would suggest simply defining a hotkey for the Tags … command in System Preferences (hat tip to Brett Terpstra for the idea). It’s lightweight and integrated, and will offer autocomplete suggestions among other things. Also, the workflow search is for user tags only – if you want and / or need to also search application specific tags like those set by Delicious Library, Evernote and others (aka Spotlight keywords – when Apple fixes CoreData Spotlight importing on Mavericks, that is), you might want to use a workflow based on an Alfred file filter (like my Tagg’d – sorry for the plug, really). The speed advantage James Berry’s utility claims over mdfind is entirely lost when using a workflow [EDIT: I didn’t pay attention: the workflow already uses a file filter] you will have to add kMDItemKeywords to the scope of its .tagged file filter, optionally also kMDItemOMUserTags for OpenMeta tags (essentially recreating my Tagg’d workflow). Again, kudos for the workflow. Please consider the above a set of differentiating footnotes, not a fundamental critique.
  18. I’d love that, but there is no way to achieve that with OpenMeta tags I am aware of, as there is no central database of the tags [Leap, a tag centric file browser which offers an “all tags” view collects these by actually scanning the whole file system hierarchy, which is far too slow to be useful in a filter, and all tagging apps with autosuggest I am aware of (Tagger and DefaultFolderX) simply cache the tags used in their own apps to suggest new ones]. The same is true of Spotlight keywords, with the added complication that these are set by apps privately and their only interface is … Spotlight. If Mavericks tags end up superseding OM tags and app specific Spotlight keywords, the whole issue will be worth revisiting, but until then, I am afraid the answer is no.
  19. If you need a companion workflow to retrieve these tagged files afterwards, I shamelessly recommend my Tagg’d workflow.
  20. A simple file filter to search all bookmark (keyword web) and web browsing history (keyword hist) files accessible to Spotlight. Why use this instead of the default Alfred functionality? Well: More targeted search, less clutter in default results. Smarter search: History search searches the URL, bookmark search ignores it; JavaScript bookmarklets are excluded from bookmarks searches. Searches bookmarks in Pinboard.in / Delicious accounts registered with Delish and Webbla, including tag search (Webbla, needs OpenMeta enabled, Delish works out of the box). If you’d like the workflow to support more browsers and bookmark / history formats, please attach an example of a pertinent bookmark and / or history file to this issue. As usual, repo is here, direct download there. Updates: Version 1.0.0 hotfix 2013-10-23 – fixes Alleyoop updating (you need to redownload), workflow file renamed Version 1.0.1 2013-10-25 – update for final Mavericks tagging scheme
  21. A simple file filter companion to my tagging workflow. Will search OpenMeta tags, application specific tags (as long as they are stored as Spotlight keywords – kmdItemKeywords to the savvy) and Mavericks native tags. As usual, repo is here, direct download there. Updates: Version 1.0.1 2013-10-25 – Update for final Mavericks tagging scheme
  22. Hmm, I had a quick look thinking you might have hit a snag with escape characters in XML content, but TextMate parses the XML fine. Considering the issue is then very likely in Alfred’s parsing, just a few thoughts on the posted feedback output: unless I missed something in the docs, shouldn’t args be an attribute of item, instead of an XML node? by the same token, shouldn’t the XML output also lead in with <?xml version="1.0"?> (@Jb_Bryant: or did you omit that from the copied output)? least likely, but ya’ll never know: the uid item attribute is only optional since Alfred version 2.0.3 – which version of Alfred are you running, @Jb_Bryant? (just throwing random suggestions at the wall to see if anything sticks – feel free to ignore me ).
  23. That‘s odd – the very same command runs fine on my system, and I have had no other reports of it being otherwise, Lion or Mountain Lion. As there is no documented incompatibility of contacts with 10.7 (which it predates, BTW) I can only surmise there is an issue specific to your system. Are there any logs in Console.app that say more than “illegal instruction”?
  24. Make sure Alfred is not set to escape spaces in the script filter settings. The only checked escapes should be backquotes, backslashes and Dollar signs (as these are shell metacharacters that will be interpreted inside double quotes) as well as double quotes (as they end the quoting, obviously).
×
×
  • Create New...