Jump to content

CarlosNZ

Member
  • Posts

    392
  • Joined

  • Last visited

  • Days Won

    11

Everything posted by CarlosNZ

  1. Cheers. It's working fine, I just want to know which direction to go in for further development—Alfred notifications or roll-my-own Growl notifications.
  2. Hi all, just wondering what people think is the best thing to do in this situation. I'm working on updating my EggTimer extension to work nicely with Alfred 2. I've got it working pretty much as in V1, but I'm now trying to incorporate the script feedback capabilities to display running timers in Alfred's window: As you can see, I've used the keyword "stop" here, for the user to select a timer to stop running. However, all the other controls for this workflow start with the keyword "timer" (eg timer repeat, timer 5 Do something.., etc.) and it seems a little off having to create a separate keyword for a script filter. Ideally, you could use "timer stop" to launch this feedback, but there's no way to get a script filter to only respond to a specific argument and behave like a normal script in other circumstances. Things I've tried: Set the regular script keyword and the script filter to the same keyword: "timer". However, this looks a bit weird, and the default "regular" option is not always the top of the list, so I think it's too confusing to work nicely. Make the script filter keyword start with the same keyword, eg. script filter keyword is "timers". This is probably my best bet at this point, but it bothers me a bit because it's inconsistent with the other commands. What would be really cool is if Alfred could do this: i.e. the argument from a regular keyword input can become the trigger for a subsequent script filter. I wonder what the chances of this happening are? Assuming that won't be happening any time soon, I wonder what other people would recommend for this kind of thing. I'm sure I won't be the only one to have to deal with it. For example, when (if?) @jdfwarrior updates his Alfred+Tasks extension for V2, he'll probably have the same issue, where some commands (eg. "do list" would generate a feedback list) whereas others wouldn't (eg. "do task"). Just wondering what y'all think. Cheers.
  3. I wonder if Andrew might confirm whether this will be the established behaviour for V2. You see, I'm working on getting my EggTimer script playing nice with V2 (there's a prelim version on my site), and this affects how I launch the BG processes. If Alfred waits before allowing a new input, then I have to make my BG timers be "disowned" from Alfred. Which is fine, but then I can't feedback output to Alfred, so I have to do my own notifications. However, if the behaviour is as it was in V1, then I can use Alfred notifications, which would be simpler for the user to configure. Be good to have the definitive word on this. Cheers.
  4. This is a good idea, and perhaps you could include a couple of user-input text fields where the user can enter values needed for the script to run, eg. an API key, or in Pedro's case "overwrite, append or replace". Though that should really be a selector of some sort.
  5. Is the <valid> tag enabled yet? Because I've tried setting it to <valid>no</valid> and the argument is still getting actioned by the next stage of the workflow. Hmm...
  6. What you're saying is, is the only way to act on selected text via hotkey? I'm wondering this too. Surely you should be able to populate the Alfred window with selected text somehow?
  7. You can type * in your File Filter search and it will list all files. Just realised this myself. Pretty cool.
  8. Great stuff. Any chance of making it a File Action, rather than just acting on the Finder selection? Also, a notification on completion might be nice too. But great work, I'll use this one quite a bit.
  9. Thanks Pedro. That module has to be called from a python script, right? I'm after something that is a complete python (or other) that I can call from a shell script. I realise what I'm asking is a bit unreasonable. That's why I was wondering if anyone else had some experience handling XML data with bash shell scripts. Cheers.
  10. If you're doing a shell script, I found this tutorial pretty useful: http://www.dirtdon.com/?p=1384
  11. These broad categories are already baked into OS X - the "Kind" field that shows up when you do a spotlight search: Could Alfred use these? (I think that's the kind of thing the OP was referring to, right?)
  12. I was just trying to update my EggTimer extension to work with Alfred 2 and I discovered that Alfred 2 will now wait for all processes launched from a workflow to complete before allowing the extension to be called again. I used to have this in Alfred to call the timer script: #Okay, just launch the main timer script then... ./timer.sh "{query}" But now, with Alfred 2, the timer extension won't respond to any further commands until that timer has elapsed. So now I've had to modify it to: #Okay, just launch the main timer script then... ./timer.sh "{query}" > /dev/null 2>&1 & in order to get Alfred to ignore the spawned process completely and allow further input. I'm assuming this was a decision on Andrew's part to curtail rampant BG process launching from Alfred. Can we then assume this is to be the expected behaviour in Alfred 2 final? So there you go, just a little heads-up for anyone writing shell scripts that launch background processes.
  13. Is this capability going back into v2? I've got a handful of Automator workflows that I run quite regularly and, while I could re-build them in Applescript, it would be a lot easier to be able to keep using them as they are. Cheers.
  14. I couldn't get Pushover to automatically launch the url (ie auto-dial). I had to wait for all the notifications to load, click the latest notification to reveal the link, then click that link, whereas with Prowl, as soon as I open the notification - boom, we're dialling. Pushover may be better in some ways, but Prowl seems to be much better set up for actual acting on the information it gets.
  15. Now this seems great, as Tweetbot is my Twitter client of choice. Will be sure to check it out tomorrow (it's nearly midnight here, I'm typing this in bed) and let you know how I find it.
  16. Nothing terribly complex here, but I think it's pretty awesome we can do this sort of thing with Alfred: Download here (or go to my webpage for Alfred 1 version) Requires Prowl on your iPhone in order to receive the notifications and launch the dialling process. I'm assuming this could easily be modified to work with Android phones as well, but you'll probably have to wait for Boxcar or Prowl to release Android clients. Pushover might do it, but if it's as lame as the iPhone version, it won't auto-handle the "tel://" URL scheme. Love to know if it works okay for others. ---- 13 April 2014: Updated to v1.41a Fixed — inadvertently made incompatible with current public release of Alfred. 12 April 2014: Updated to v1.41 Bugfix — wasn’t creating storage directory for API key if not already present. 3 April 2014: Updated to v1.4 Removed Applescript GUI for API key input. Now just uses Alfred interface. Separate keywords in Workflow config. New icons (iOS 7 based). 25 March 2013: Updated to v1.3 Bug fix: hyphen “-” character was still causing invalid number error. Typos 20 March 2013: Updated to v1.2 GUI for user to enter API key rather than having to edit the code Documentation Better handling of other punctuation characters that might be in a valid phone number (including parentheses, *, # and .
  17. Just wondering if there's supposed to be any sort of "best practice" for the 'Bundle ID' field in new workflows? I'm assuming something like "workflowname.creator" would be fine. What about version number? Should the Bundle ID change with new versions of a workflow? It seems to me like it would be a good idea to include some sort of version info within the workflow. How do you reckon we should do this? Just in the filename? Or is the Bundle ID the place for this. Would be nice if the Bundle ID could be standardised to something like "workflowname.creator.version" maybe.
  18. Hi all, It appears pretty much all useful data that I want to interact with these days stores or presents its info with XML. Unfortunately, my programming knowledge really only extends to writing shell scripts (with a little AppleScript for good measure), which, as far as I can tell, can't parse XML very nicely. What do you reckon my best option is? Persevere with using clunky and tedious string manipulations (awk, sed, etc.) to extract what I want from the XML structure. Not very appealing, but I've got away with it so far. There are 3rd-party xml libraries for bash (eg. xmllint), but I'm wondering if they might be more trouble than they're worth for a simple Alfred workflow. Find a free php or python script that I can simply call from bash and have it return the xml values for populating into a bash array. Can anyone suggest such a thing? Just bite the bullet and start learning a "proper" programming language. And if so, what? (Python? Ruby?) I'd be interested in your thoughts. Cheers, Carl.
  19. Just wondering if Notification Centre output has to be limited to two lines? I'm assuming this is a built-in Apple limitation, so any workflows that require a larger output will really need to keep using Growl, no?
  20. Yeah, I agree, my list is getting a bit unwieldy too. And I can definitely see it ballooning with Alf 2.0.
×
×
  • Create New...