Jump to content

xilopaint

Member
  • Content Count

    538
  • Joined

  • Last visited

  • Days Won

    18

Everything posted by xilopaint

  1. It works! Thanks! Why didn't you add the cli variable on the configuration sheet?
  2. That can be useful in some cases but I want the torrent added to transmission via CLI. It's not a big deal if you think this feature doesn't suit your workflow as I will add it anyway. In any case I agree with @deanishe that your workflow would be much more versatile if it does output the magnet link instead of handlin´╗┐g it internally in code.
  3. The main and obvious advantage of the CLI is the same of Alfred: you can do tasks without a GUI. Just add your torrent and forget about it. It will be downloaded in your ~/Downloads folder. No GUI, no distractions. "Oh, but I want to check the download progress sometimes and I don't want to type a command in Terminal for this". Not a problem, just type 127.0.0.1:9091 in your browser's address bar. You will have a functional web Transmission GUI. Or better than that, just create a bookmark for this URL and use Alfred to open it. You just don't need a separate GUI app. With your workflow + transmission-cli I can have my downloads delivered at the proper folder in the most alfredish way, which means no browser, no Terminal, no third-party GUI apps, just the Alfred panel. Sounds a good implementation to me.
  4. I've found the bug. If the quote on that post is expanded the quote button/link is not clickable.
  5. I don't even know if other CLI clients exist.
  6. @godbout a key modifier seems fine to me. You can use a dynamic subtext to show a warning like (e.g. "You don't have transmission command-line utilities installed") if the action is not applicable to that user. EDIT: Weirdly I can't quote your last post. A forum bug?
  7. The problem here is the user has to make the changes for every release if the workflow author doesn't implement them.
  8. Thanks! I achieved to do it by changing this: public static function download($magnetLink = '') { $crawler = (new Client())->request('GET', getenv('url') . $magnetLink); $magnetLink = $crawler->filter('#tab-technical a.siteButton.giantButton')->attr('href'); return exec("open $magnetLink 2>&1", $result); } to this: public static function download($magnetLink = '') { $crawler = (new Client())->request('GET', getenv('url') . $magnetLink); $magnetLink = $crawler->filter('#tab-technical a.siteButton.giantButton')->attr('href'); return exec("/usr/local/bin/transmission-remote -a \"$magnetLink\" 2>&1", $result); } Still I think this integration would be a nice improvement to the workflow.
  9. Are you sure it's the current behaviour for keywords? I was pretty sure that in my last PR this was changed to not listing blank keywords. It seems to me @bk161124 is running an outdated version of the workflow.
  10. I just don't know how to pass the magnet link to the command-line interface if it's not output by the workflow.
  11. But the Script Filter doesn't output the magnet link.
  12. Would you consider to integrate your workflow with transmission-cli? It can be installed with `brew install transmission` and work headless. That would allow us to start downloading the file from Alfred without the need of any GUI BitTorrent client which is the perfect scenario. A possible implementation would include a check for the existence of the CLI in the user machine, otherwise the current flow is used. An environment variable on the workflow configuration sheet would make the job as well (the user would set the value to 1 to use the flow with the integration).
  13. What is the average Alfred user profile? Is he/she aware of Homebrew? If so I'm in favor of promoting Homebrew Python/Ruby rather than bundling runtime. There's no difference in UX when you have Python installed via Homebrew and I don't think the comparison with node is accurate. With node you have the workflow installed in some shady path. I'm more curious to know what will be the future of Alfred-Workflow. Will it be converted to Python 3 since there's no longer advantages to stick with Python 2?
  14. I'm completely unaware of this discussion but wonder how big the workflow size could get by doing this.
  15. Any reason for maintaining the .scpt files? I recommend you don't place compiled and uncompiled versions of the files in the same directory. This is a repository of an AppleScript based workflow for your reference.
  16. You might want to use .applescript extension rather than .scpt on GitHub as the latter one is for compiled files and can't be read within the repo.
  17. Have you seen the post immediately above yours?
  18. Jesus, you're right! Because I never use these services I forgot they also live in the menu bar.
  19. If by macOS services you mean those you can see in the right-click menu the answer is "you can't". This workflow is meant to search the commands of the menu bar, not the right-click menu. Also that workflow was built for Alfred 2 and is currently unmaintained. This other one, written in Swift, is newer with a similar implementation and works with Alfred 3 and 4.
  20. Are these file managers worth it? I've never used any of them. What is the best one?
  21. It works for me, but with this important caveat: The rate limit makes the workflow unfeasible for my routine.
  22. Carlos, have you ever considered to push the source code of your workflows to GitHub? There's a lot of advantages on it: 1) better discoverability; 2) ease to document; 2) contributions from the community to expand the workflow, fix bugs and report issues; 3) versioned releases; 4) using OneUpdater to allow auto-updates. It's very simple, straightforward and even fun. Maybe you are familiar with all of this and just don't want to do it for whatever reason, but if it's not the case you can check out my Things workflow as a reference. It's written in AppleScript as well.
×
×
  • Create New...