kopischke
-
Posts
47 -
Joined
-
Last visited
-
Days Won
2
Content Type
Blogs
Gallery
Downloads
Events
Profiles
Forums
Articles
Media Demo
Everything posted by kopischke
-
@funtrix the revised version should work fine (I tested “ögon"). @jink0421 let me know if the revised version handles this correctly (Chinese worked fine in my superficial tests).
-
Well, if you ask like that… Revised version that: handles non 7-bit ASCII characters (aka “what them foreignas use”) correctly, both as input and as output, handles phrases correctly (i.e. as phrases, not as multiple separate terms), adds a Paste into foreground application action (Cmd modifier), uses a central script file so that adding languages is a matter of adding a simple command to a new script filter (./translate '<language code>' '<language name>' "{query}"), is certified 100 % awk and sed free (you saw that coming, right?). (note the Russian and Chinese translations have only been added to showcase the international support – by default, the workflow still only translates to French, English, and Spanish). As usual, repo is here, direct download here.
-
I’ve updated Florian’s original workflow. This version has a friendlier display, including correct drive icons handles volumes with spaces in their names displays the correct name of the system drive offers actions on the drives (Finder reveal and Alfred browsing) is certified 100 % awk-free The repo is here, direct download here.
-
Just a quick heads-up: there is another last.fm workflow by Filipe Barros (with minor contributions by yours truly) over here. It lacks the smooth drill-down interface (I really like that) and requires a last.fm account, but offers a much more extensive selection of last.fm queries (track and album info, loved and banned tracks, love, ban, tag and untag currently playing track etc.).
-
You heard the man: do open issues on GitHub if anything is amiss. I’m following the repo and will try to pick up anything that looks like it is Ruby 1.8 related pronto. To help me do that, please do not forget to include your system stats when posting issues (i.e. Running Alfred 2.0.8 (212) on OS X 10.8.5, German locale). And thanks to Filipe for his terrific work on this!
-
The issue is with an incompatibility with Ruby 1.8 when writing the configuration file on authorization. I thought I already fixed that, but I obviously lost the changes somehow and did not catch this when submitting my changes to Filipe. My bad entirely (Filipe can’t test 1.8 compatibility). I also fixed the track actions, which would not work in Ruby 1.8 after Filipe refactored them in the 1.1.1 release. There is an unofficial 1.1.2 release here, and I submitted a pull request to Filipe, so expect the official release to catch up very soon.
-
Hey @Empyreal, I’m sorry to say that is not possible, to my best knowledge. To get the current selection, the application which contains the selection must be focused for the selection to be extracted – which it is not when Alfred’s window is open and waiting for input. There are ways to navigate around this if you can script the background application (and, even more to the point, know which one you need to target), but none built into Alfred, at least currently.
-
Yeah, that would have been me . Unluckily, my efforts went at cross purposes with Filipe’s ongoing refactoring of the original extension, so that there are, currently, two incompatible versions: the one Filipe is maintaining, which will only run on Ruby 1.9+, and my fork, which will work with all Ruby versions from 1.8 (standard on current OS X) to 2.0 and contains some fixes and improvements not currently present in Filipe’s. Filipe has kindly announced he will try to merge both versions, but until he gets around to doing that, if you are on OS X < NDA-you-are-not-meant-to-mention-that, my fork might be your best solution. Still, all kudos to him for the development work, it’s an awesome extension, which is why I felt it needed system Ruby compatibility below OS X dont-you-mention-it (I could actually have made it run on my system by forcing it to use my Ruby 2 install, but thought other might appreciate not having to install a separate Ruby version).
-
Hello @xilopaint, sorry for the late reply. I’m afraid there is not much I can help to do about this, as it is a limitation of the underlying utility the workflow uses to retrieve the numbers. See this issue on the GitHub repo.
-
Hi @hzlzh, much as I appreciate what you are trying to do, I’ll not submit my workflows to your directory as long as a direct upload is required. I provide Alleyoop updating in all workflows because, for time and efficiency reasons, I want to keep new version uploading to one target only: the GitHub repo the workflows are stored in. However, should you ever decide to drop the direct (“backup”) download requirement and accept GitHub-only submissions, I’ll gladly add my workflows to your list (and of course I won’t object if somebody else wants to take it upon her or him to do so – the collected workflows are WTFPL licensed, after all ).
-
For those who prefer using Ali Rantakari’s Tagger.app for OpenMeta tagging to pure Alfred solutions (like the one posted here), I have added another small workflow to my miscellaneous repository. As usual, it updates via Alleyoop. GitHub repository. Direct download link.
-
Whoops, I messed up the original workflow package while repackaging. Fixed; download should now actually install in Alfred.
-
Annoyed at Finder’s occasional stubborn refusal to correctly update the contents of network shares? Catching yourself developing a case of F5 envy? Fuming at your Windows buds* gloating? Despair no more: I’ve ported Söderhavet’s fine Refresh Finder utility to an Alfred workflow. Hotkey or the refresh keyword refreshes the file listing of the frontmost Finder window, another hotkey or alt-keyword refreshes them all. Updates via Alleyoop. Blog post here, GitHub repo there. Oh, and direct download is here. * if such a thing even can exist.
-
I’ve just updated the workflow to the Searchlight edition which improves the call search functionality: uses a more sane default number sequence (starting with mobile and excluding fax) also searches nicknames for a match refines results incrementally for every word added to the query, over all searched fields (i..e name, company, nick): fixes case sensitive / insensitive matching of UTF-8 strings. EDIT: version 1.1.1 fixes result sort order; these will now match the collation rules for your locale. version 1.1.2 fixes incremental searches not respecting case sensitivity under certain conditions.
-
@wbranson sorry, but this thread is for the Alfred PushDialer extension – not for generic iOS / Apple hardware compatibility with OS X support. If by “pairing” you mean PushDialer pairing, I suggest you ask the PushDialer author (whom I am not affiliated with) for support.
-
Some bugfix updates since first release (see update list in original post). Also wanted to tease that I am working on a few real features extensions, the biggest one having to do with the request by Domenic above .
-
Display and calculate with current date and time
kopischke replied to iEnno's topic in Share your Workflows
Very nice idea, but wouldn’t it be much simpler (not to mention probably both faster and less prone to PHP warnings) to use the POSIX date utility that ships with OS X? -
Easily. The dialing logic proper is in the final script action (rightmost column in the workflow window), just change the open call there to a curl call for Prowl or Pushover. Everything else in the workflow does not depend on PushDialer. Note however that the Ruby sanitization script (middle column in workflow window) strips an eventual tel: protocol prefix, so you will either have to edit that to bypass the stripping, or re-add it in the final step if your destination expects such a protocol to initiate dialing (Prowl does, AFAIK).
-
Or wrap the XML content string into a CDATA tag, i.e `<[CDATA[your string ]]>` (ran into that issue when doing the phone number filter in http://www.alfredforum.com/topic/1680-dial-with-pushdialer-workflow/ – renaming contacts is not really an option )
-
SSH with smart hostname autocompletion
kopischke replied to isometry's topic in Share your Workflows
Ha, so that is what has been driving traffic to this old answer of mine lately? Well, thanks for the upvotes, folks . -
Big fan of your workflows here, too. I’ve used your PushDialer one as a kickoff for my first foray into workflow creation – you might want to have a look, it is a bit more extensive than yours : http://www.alfredforum.com/topic/1680-dial-with-pushdialer-workflow/
-
I’ve gone and created a workflow to dial numbers found on your Mac with your iPhone via PushDialer, as I found Florian Pellet’s PushDialer workflow a bit simplistic for my taste. This one has the full trimmings (dial from text selection via hotkey, from the Alfred prompt, or from the Alfred contact viewer), more robust filtering and error handling, Alleyoop support for updates as well as a nice little extra in the form of script filters allowing you to find numbers to call right out of Alfred: There is a somewhat more detailed post announcing it on my blog, and the workflow itself is on GitHub (direct download link is here). Hope somebody finds it useful. Updates: 1.0.1 fixes escaping of shell metacharacters (aka “who wants to dial your $PATH”). 1.0.2 queries with non-ASCII characters now work (aka “der Süden tanzt”). 1.1.0 Searchlight edition: significant improvements to the search functionality of the call family of script filters (see this post for the details). 1.1.1 fixes sorting of script filter results (aka “Alphabet, sagtest Du Alphabet?”). 1.1.2 fixes case sensitiveness in incremental searches (aka “a flock of cases”). Check for updates with Alleyoop, or re-download from GitHub.
