Jump to content

luckman212

Member
  • Content Count

    17
  • Joined

  • Last visited

About luckman212

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thank you @GuiB that is definitely helpful. I will try fooling around with this probably this weekend when I have more time (hopefully)
  2. @GuiB Thank you for posting this! It's a very interesting solution. I'm not sure I'm up to the challenge of rewriting my bash script in JavaScript so I'll have to see about that. Also, I need the output of the program to be passed along as a parameter to the next step in the Alfred workflow. Not sure how to do that since the "meat" of the task is now running in a subprocess. I guess maybe in the JXA script it should output results to a /tmp file and then when control returns to Alfred, it can read that file back in and push it back into the {query} ?
  3. @deanishe Simply brilliant! I had to muck around a bit but you got me started in the right direction and I eventually nailed it. Thank you so much Is anyone interested in the solution? I can post it if yes.
  4. hey Alfred gurus! I've got a workflow that I use frequently to initiate calls via my Polycom desk phone. It's super handy but I'd like to go a step further and be able to use it for clickable tel:// links found on webpages etc. I think what I need is to register a "protocol handler" for this. I assume it would be something like make a small AppleScript that calls the Alfred workflow with the parameter register that App as the protocol handler for tel:// URIs I think I can probably handle step 1 but I'm not sure how to handle part 2. Anyone done anything like this?
  5. Thanks - would that be possible if no Alfred window is showing? Because primarily this workflow is triggered via hotkey only. Got any links or examples where I can read up more about the `rerun` thing?
  6. Thank you, I believe this would be very useful, for creating singletons/mutex's/lockfiles etc. as well as a bunch of other things.
  7. For an example of what I'm talking about, try pasting this script into Script Editor and running it set n to 5 set progress total steps to n set progress description to "Script Progress" set progress additional description to "This should be helpful" repeat with i from 1 to n delay 1 set progress completed steps to i end repeat If you save that as an Application and run it, you get a very nice popup progress bar... But, running this code from within Alfred does nothing. Also, I've tried using cocoaDialog (both 2.1.1 and the 3.0b7) and can't get either of them to run from within a workflow, I think possibly due to SIP/code signing issuues.
  8. Hey workflow gurus! I have implemented a workflow to perform various file hashing functions (md5, sha1, sha256) on selected files, and display results in a LargeType window, or optionally send to a CSV and open in Numbers.app. It also supports triggering via both a Hotkey as well as a Keyword, and supports queueing up files and then processing the queue later. It's pretty nifty and I'm almost done polishing it and I plan to make it publicly available. One thing I'm having a hard time with is- on large files (e.g. 1GB+) the hashing takes a bit of time as Alfred churns through a Bash script, and there's no feedback to the user that anything's happening. I'd like to show some type of progress bar or progress display in the menu bar etc. I have been banging my head on this for a while now but I can't figure out a good solution. I know AppleScript supports the concept of Progress (see Mac Automation Scripting Guide - Displaying Progress) but when I tried this from inside Alfred, it just didn't work properly and always stayed at 0%, even though the exact same script when run from Script Editor worked fine. I've found a couple of "helper apps" that I am considering but none are very actively maintained and I was really hoping for a "native" solution that didn't involve adding more 3rd party tools and dealing with licenses etc. links: https://cocoadialog.com/ -- related https://github.com/cocoadialog/cocoadialog/issues/108 https://github.com/tsntsumi/ProgressDialog https://www.bluem.net/en/projects/pashua/ - GitHub page: https://github.com/BlueM/Pashua Anyone got any ideas for this? thank you
  9. Thanks @vitor It isn't working for me outside of script actions. For example, try this simple workflow: Hotkey settings Large Type settings The output for me is:
  10. These script environment variables (e.g. `alfred_workflow_uid`) have been very useful to me. https://www.alfredapp.com/help/workflows/script-environment-variables/ I'd like to be able to use them outside of bash or python script actions. Any reason they're not made available throughout the entire workflow?
  11. Simple question but I searched a bit and couldn't find any discussion of it. Has there been any consideration given to adding top/bottom (vertical) "connection points" for the workflow objects? It would make the graphs a lot neater looking when there are lots of paths being followed. The left/top points would be for "input" and the right/bottom points for "output". example, this vs. this:
  12. Well, that was a long & winding road. I'm new to Alfred so I'm still figuring things out. I tried everything I could to avoid using a /tmp file but this was the only way that worked. Everything else—using variables, trying to process the clipboard buffers from within the workflow itself, using external triggers etc, all failed. This seems to be due to the way Alfred processes the query buffer as it passes through the workflow. Internally, a reference like `{clipboard:11}` will always return that exact text (e.g. if used in a comparison statement from bash or python) -- it only converts it to the actual clipboard value during OUTPUT actions such as Large Type or Write Text File. The 2nd problem is, if `{clipboard:11}` contains a NULL (empty) value, instead of returning BLANK (which would be expected), Alfred insists on instead outputting the dynamic placeholder itself. So, if you have only 5 clips and you ask for 10 to be merged, the last 5 will be written out as just `{clipboard:6}, {clipboard:7}...` etc. TL;DR I could not find a reliable way to test for "empty" values and omit them from the output other than using Write Text File and then processing it with sed. This works fine though, and the script cleans up the /tmp file after itself and is pretty quick about it. If anyone knows a better way I'm all ears. But I think this is something that would have to be fixed in Alfred itself. Here's the new version: changes omits empty strings from output if you request > clips than exist in the history configurable MIN_CLIPS and MAX_CLIPS variables added notifications for success/failure https://github.com/luckman212/clipmerge-alfred-workflow/blob/master/README.md
  13. Thanks. Yes, I noticed the same thing after posting. I'm working on a fix for if you type a number that exceeds the number of clips you have in the history.
  14. Figured out a way - not sure if it's the "right" way but, it works well enough. I used a couple of bash scripts to validate/filter the input as well as loop & process the output. If you want to have a look... (link removed, scroll down for the new version)
  15. I'm trying to make a workflow that accepts a single parameter "N" (a number) and then uses that to merge the last N clipboards, and paste that to the frontmost app. Let's call it "clipmerge" and it uses keyword `cm`. e.g. "cm9" would take {clipboard:0} {clipboard:1} ... {clipboard:8} and merge them. Anyone got any ideas on how to achieve this? edit: I figured out my own solution... click here
×
×
  • Create New...