xilopaint

@xilopaint can you try this version? https://www.dropbox.com/s/bdtphtve5vfr1dh/KAT.alfredworkflow?dl=0
 
Add a `cli` global variable. It should contain the command and a `{magnet}` variable that will be replaced by the magnet link chosen through Alfred. There' also a possibility to copy the magnet with the cmd modifier. (It's version 3.0.0 because I've updated some of the workflow's objects and I should work only with Alfred 4 from now on.)
 
Let me know if it works well. If it does I will release an official update.

Yes, definitely going to the  "it's the user's problem" route. Although, I don't like this idea that much because of that need to edit the workflow again after an update, on the user's side. As a developer I want to be able to push an update every day if needed. As a user, I want my workflow to get broken as less as possible. If I make a change myself and I need to do it again after an update, that's a lot of cognitive load (at least for me). Small stuff to remember that are not worth the pain. So currently, it seems that the best idea would be a global variable like `cli`, if those variables don't get erased by an update (I guess the "migrate settings" when an updated a workflow allows for that).

Here's the fix:
 

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.

Oh, right. I was talking about a separate app to handle magnet links system-wide, not editing the workflow.
 
Have you looked at the source code? There must be a /usr/bin/open command in there somewhere that you can swap for /usr/local/bin/transmission-cli.

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.

Thank you for the advice.
 
I have never used GitHub but I'll try it eventually.

This is a rather bad argument, as they're both using the same mechanisms under the hood. It's a question of quality of implementation. Certainly, I don't see why you would need AppleScript for that.
 
 
Yes, it is. This is largely a result of the fact that Alfred's "native" format is lists and LB's is trees—a much better fit for navigating a filesystem. A such, you're always going to be able to implement better filesystem navigation in LB than in Alfred.
 
That said, it'd be nice if Alfred were more inclined to copying good ideas from other launchers.
 
Hopefully, Alfred 4 will go like Alfred 3, and Andrew will add a bunch of significant new features with dot releases.

It should be an option on the Power Pack page of the Preferences program so that we can really use it as a tip jar at any time!

Meh. It's worth having at least one of them for copying/moving lots of files, as they all queue copy/move actions instead of doing them all at the same time, as Finder does.
 
I mostly use ForkLift for SFTP stuff. It's a crap file manager because its window/tab management is awful.
 
Marta's quite nice, but it's not very Mac-like. It lacks basic features like the ability to move tabs to a different pane/window.
 
Basically, I'd just like a file manager that's good at, you know, managing files. But those three all lack some basic feature(s) that makes them a bit crap.

Services are also available via the Menu Bar (App > Services), so the menu bar workflow should still find them.

The issue is that Google isn't returning the page the workflow expects. The results are there, but the workflow's parser doesn't understand the HTML in the returned page.
 
You'll need to ask the workflow's author to fix it.

The problem is the workflow data folder path is hard coded for Alfred 3. You can fix this by changing the line 7 of the workflow.scpt file to this:
set my _data to (system attribute "alfred_workflow_data")
 
I encourage @Carlos-Sz to use script environment variables in his workflows.

Right-click on the workflow icon on Alfred Preferences and click on Open in Finder after that.

Update (v2.16)
 
• Fixed a bug that prevented the Crop file action to work properly on PDF files with mutiple pages.
• PyPDF2 replaced with PyPDF4.

In case you haven't seen our tweet from a few days ago...
 
Prepare your keyboards and stretch those finger muscles, Alfred 4 is coming in June!  
 
We've posted a very high-level list of just some of the features and improvements you can look forward to here:
https://www.alfredapp.com/v4/
 
You'll answer find answers to questions about upgrades, and an email signup if you'd like to hear about Alfred 4 as soon as it's available!
 
 
 

Dependencies
 
Default App uses duti to change assigned apps. 
You need to install duti first before you execute the Alfred Workflow
 
brew install duti  
Usage
 
dapp ext
 
1. ext you can type any extension, the workflow will ask for confirmation to change the assigned app
2. Choose one of the Apps to assign the extension to.
 
Download on Git
 
https://github.com/Acidham/alfred-default-app

Thanks. Fixed in v1.8.1.

That's a fair point.
 
Still, it seems a bit odd to post a site that you say you don't want to submit your own workflows to.
 
Now I look more closely, I think it questionable that the site doesn't mention workflow authors at all. Every page says "Maxwell Jordan White" but never mentions the people who're providing the content that makes the site anything but completely pointless.
 
Notably, there's also a  big "Donate to Me!" link, but none for the workflow authors (which Packal always had).
 
Quite likely an oversight by Max, but all the same, not super cool.

I’ve updated the workflow to use Alfred’s environment variables to get the paths to its data storage locations.
Please re-download.
 
To remove the old data in Alfred 2’s cache and data folders, launch Terminal and execute the following commands:
rm -rf ~/Library/Caches/com.runningwithcrayons.Alfred-2/Workflow\ Data/com.targumanu.ibookssearch rm -rf ~/Library/Application\ Support/Alfred\ 2/Workflow\ Data/com.targumanu.ibookssearch  

My local kebab shop always puts up a notice when they're on holiday that says "back in two weeks".

Handy.
 
You should probably change it to use the Workflow3 class, not Workflow.

Workflow is for Alfred 2 and doesn't support Alfred 3's new features.

Thanks anyway,
 
I might go deeper into Swift and try to do it myself.

Presumably before you updated to Mojave. You need to grant the appropriate permissions in System Preferences.

Things for Alfred

Interact with Things 3 using Alfred.

Download and Installation
Download the workflow file from GitHub releases and install it by double-clicking on Things.alfredworklow.

Usage
Use the keyword todo to show Things lists and action any of them for displaying the corresponding to-dos. Action a to-do to display it in the Things UI. Try the modifier keys either in lists or in to-dos to know other actions. Contribute
To report a bug or request a feature, please create an issue or submit a pull request on GitHub.

Credits
This workflow relies on qWorkflow library by Ursan Razvan and OneUpdater by Vítor Galvão. The to-do icon is created by Jason Zigrino and released under the Creative Commons BY-NC-ND 3.0 license.

License
Things workflow code is released under the MIT License.