Alfred KAT

[xilopaint]

9 minutes ago, deanishe said:

 

Looks that way. My post that you quoted looks weird, too.

 

I've found the bug. If the quote on that post is expanded the quote button/link is not clickable.

[deanishe]

16 minutes ago, xilopaint said:

I've found the bug. If the quote on that post is expanded the quote button/link is not clickable.

 

Nice one. I suppose you could try reporting the issue to Invision, but fixing bugs isn't really something they do, is it?

[godbout]

20 hours ago, deanishe said:

 

Disagree. It seems to me that the problem here is that you're not happy with the your own system configuration and instead of spending 15 minutes putting a single line of bash in an Automator/Platypus app to fix it, you want @godbout to spend an hour or two of his time adapting his workflow to suit you instead.

 

I mean, you didn't even consider how to support command-line clients in general (e.g. "provide an optional workflow variable to specify a shell command to open the magnet:// URL"). You just asked him to hard-code your favourite one.

 

I think @deanishe makes very good points. To be honest I had never thought of the torrent command line clients. What's the advantage? Why do you guys use that rather than a GUI client?

 

I coud still add something more like for power users. Like if there's a global variable `cli`, use that instead of open. Quick to do. If it does make sense and help, I'll add it.

Edited June 6, 2019 by deanishe
Try to remove Grammarly markup

[xilopaint]

4 hours ago, godbout said:

I think @deanishe makes very good points. To be honest I had never thought of the torrent command line clients. What's the advantage? Why do you guys use that rather than a GUI client?

 

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.

 

4 hours ago, godbout said:

I coud still add something more like for power users. Like if there's a global variable `cli`, use that instead of open. Quick to do. If it does make sense and help, I'll add it.

 

Sounds a good implementation to me.

Edited June 6, 2019 by xilopaint

[deanishe]

What's going on with this thread? Now I can't quote @godbout, or select text.

 

@godbout In addition to CLI clients, some people use seedboxes (at home or elsewhere), so they need to send magnet links/torrents to a different machine (e.g. via a script).

 

Adding a custom command option is certainly helpful.

 

For my part, I just don't want to live in a world where users expect every workflow author to add custom opening logic because for some reason or another, they aren't happy with the way they've set up their own system. I'd really like that to be seen as a problem for users to solve for themselves.

[Vero]

9 minutes ago, deanishe said:

What's going on with this thread? Now I can't quote @godbout, or select text.

 

Give me a minute - Looks like something's funny about @godbout's post, like there's some crazy spacing around that "2". 

 

Please leave it as is for a bit so I can send the IPBoard support to this thread, so they can see what's been entered. If it gets fixed/edited, I won't be able to show them in-situ.

 

Cheers,
Vero

[Vero]

@godbout @deanishe Are either of you using Grammarly before pasting text into here? When I go to the first page and look at the blank section above @godbout's post, I see a tooltip that says "Protected by Grammarly".

 

Could it be that some weird metadata is being pasted along with the text? Or that a Grammarly browser plugin is inserting some non-text weirdness with the visible text?

 

If you can let me know, I'll still report that to IPBoard as something that could/should be improved, but both posts where there's some uncopiable text and weird spacing, I get the Grammarly tooltip.

 

 

Cheers,
Vero

 

[deanishe]

1 minute ago, Vero said:

Could it be that some weird metadata is being pasted along with the text?

 

There is some HTML weirdness going on: there's a bunch of huge, empty divs inside the quote. It doesn't look like IPB markup, as there are inline styles. If I delete them via the Web Inspector, the page is useable again.

 

You shouldn't be able to insert tags into the page like that yourself. That's a big 'ol security hole. Whatever Grammarly is doing on @godbout's machine, the forum software should absolutely not allow custom Grammarly markup to be saved in the actual post.

[deanishe]

Now IPB has had a look, I've fixed the borked posts.

[godbout]

5 hours ago, Vero said:

@godbout @deanishe Are either of you using Grammarly before pasting text into here? When I go to the first page and look at the blank section above @godbout's post, I see a tooltip that says "Protected by Grammarly".

 

Could it be that some weird metadata is being pasted along with the text? Or that a Grammarly browser plugin is inserting some non-text weirdness with the visible text?

 

If you can let me know, I'll still report that to IPBoard as something that could/should be improved, but both posts where there's some uncopiable text and weird spacing, I get the Grammarly tooltip.

 

 

Cheers,
Vero

 

 

Yes I'm using Grammarly. I type directly in the box, no copy paste or anything like that. Never had any problem till now. I've disabled it for the Alfred Forum for now.

[godbout]

6 hours ago, xilopaint said:

 

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.

 

Yeah, I was thinking about the progress. Personally I find it more annoying to check in the browser when I need it rather than having the Transmission app running in the background and sending a notification once it's downloaded but ok I see your point.

[godbout]

5 hours ago, deanishe said:

 

@godbout In addition to CLI clients, some people use seedboxes (at home or elsewhere), so they need to send magnet links/torrents to a different machine (e.g. via a script).

 

Adding a custom command option is certainly helpful.

 

For my part, I just don't want to live in a world where users expect every workflow author to add custom opening logic because for some reason or another, they aren't happy with the way they've set up their own system. I'd really like that to be seen as a problem for users to solve for themselves.

 

Yeah but the workflow isn't outputting the magnet link. I haven't focused on those cases. I don't mind adding something at all, I just want to understand the issue, and add it correctly. So, would copying the magnet link to the clipboard helpful? Scripts could then catch it up.

 

I absolutely agree with your last sentence. And I'm not trying to answer to every user cases. But usually I build stuff that I need right in front of my nose. Too many things to do and to care about, so I grab knowledge through feedback after, from other people, like you guys in that case. If something makes sense, then I've learned something along the way, and I might build it. But I want to build it correctly.

[godbout]

7 hours ago, xilopaint said:

Sounds a good implementation to me.

 

What about if when using `cmd` it copies the magnet to the clipboard rather than opening the magnet? You should be able to do something with that. That sounds more proper to me, for the workflow.

[deanishe]

27 minutes ago, godbout said:

Yeah but the workflow isn't outputting the magnet link. I haven't focused on those cases. I don't mind adding something at all, I just want to understand the issue, and add it correctly. So, would copying the magnet link to the clipboard helpful? Scripts could then catch it up.

 

Assuming we're going my "it's the user's problem" route, I think the best way to handle this is not to open files/URLs from deep within your code, but where practical to use a separate Run Script action with a simple open "$1" (or an Open File/URL). Then if a user doesn't want your workflow to open stuff in the default app, they can very easily change it without having to "crack open" the workflow and edit the source code. (And it's easier to edit again after an update.)

 

Copying the link to the clipboard by default might be useful in some cases (web interface to a remote torrent client, for example), but in that case, the user can easily swap the above Run Script for a Copy to Clipboard (or swap the open command for pbcopy). Or add an additional action with a modifier.

 

I mean, if the workflow does output the magnet link, instead of handling it internally in code, the user can add whatever actions they want relatively easily.

 

If possible, the workflow should be using the magnet URL for each item's arg. In that case ⌘C will copy the URL to the clipboard without any additional developer effort needed. It looks like fetching the search results and the magnet links are separate steps, though, so that wouldn't work here, I guess.

Edited June 6, 2019 by deanishe

[deanishe]

14 minutes ago, godbout said:

What about if when using `cmd` it copies the magnet to the clipboard rather than opening the magnet? You should be able to do something with that. That sounds more proper to me, for the workflow.

 

A Copy to Clipboard option is rarely a bad idea.

[xilopaint]

1 hour ago, godbout said:

What about if when using `cmd` it copies the magnet to the clipboard rather than opening the magnet? You should be able to do something with that. That sounds more proper to me, for the workflow.

 

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 handling it internally in code.

Edited June 6, 2019 by xilopaint

[godbout]

17 hours ago, deanishe said:

 

Assuming we're going my "it's the user's problem" route, I think the best way to handle this is not to open files/URLs from deep within your code, but where practical to use a separate Run Script action with a simple open "$1" (or an Open File/URL). Then if a user doesn't want your workflow to open stuff in the default app, they can very easily change it without having to "crack open" the workflow and edit the source code. (And it's easier to edit again after an update.)

 

Copying the link to the clipboard by default might be useful in some cases (web interface to a remote torrent client, for example), but in that case, the user can easily swap the above Run Script for a Copy to Clipboard (or swap the open command for pbcopy). Or add an additional action with a modifier.

 

I mean, if the workflow does output the magnet link, instead of handling it internally in code, the user can add whatever actions they want relatively easily.

 

If possible, the workflow should be using the magnet URL for each item's arg. In that case ⌘C will copy the URL to the clipboard without any additional developer effort needed. It looks like fetching the search results and the magnet links are separate steps, though, so that wouldn't work here, I guess.

 

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).

[deanishe]

2 hours ago, godbout said:

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).

 

Same as that. I always forget which workflows I've changed and then wonder what's wrong after an update. Despite being caught out by this dozens of times, I still haven't had the sense to start keeping notes…

 

2 hours ago, godbout said:

if those variables don't get erased by an update (I guess the "migrate settings" when an updated a workflow allows for that).

 

That's correct. Alfred retains user-set variables, hotkeys and keywords across updates.

[godbout]

20 hours ago, deanishe said:

Same as that. I always forget which workflows I've changed and then wonder what's wrong after an update. Despite being caught out by this dozens of times, I still haven't had the sense to start keeping notes…

 

Probably you don't keep notes because subconsciously you know it's another cognitive load  in which app did I store that? Which note? Personally I want software to save my time AND my cognitive load. If it's a pain every time I update, I stop using the software.

 

I started tinkering with an update for the workflow and I see how passing the magnet link around as variable would help to copy to clipboard and do other things. At the same time it makes the structure of my own code worse (again, in term of cognitive load). I remember with my first workflows, I found it was such a pain to handle menus through Alfred. Now basically all my workflows have the same structure: one script filter for the menus, one script filter for the actions. It makes it harder for user to modify the workflow, but way easier for me when I need to update and come back to my code.

[godbout]

@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.

[xilopaint]

1 hour ago, godbout said:

@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.

 

It works! Thanks!

 

Why didn't you add the cli variable on the configuration sheet?

[godbout]

16 minutes ago, xilopaint said:

 

It works! Thanks!

 

Why didn't you add the cli variable on the configuration sheet?

Is that too much for you to add?  🙄️😂️

 

I will not add it by default. It'll be like a 'pro user' thing. If there's no `cli`, then it will open the magnet link with the default mac app. If there's a `cli` variable, then it will use the cli. Knowing myself, if I add it, I'll forget to remove it. Now that you added it, it will stay there on subsequent updates.

 

 

[xilopaint]

12 minutes ago, godbout said:

Is that too much for you to add?  🙄️😂️

 

I will not add it by default. It'll be like a 'pro user' thing. If there's no `cli`, then it will open the magnet link with the default mac app. If there's a `cli` variable, then it will use the cli. Knowing myself, if I add it, I'll forget to remove it. Now that you added it, it will stay there on subsequent updates.

 

 

 

Please, make it at your own discretion. I really appreciate your effort in supporting CLIs. I just didn't understand why you didn't leave the environment variable with a blank value.

Edited June 9, 2019 by xilopaint

[godbout]

11 minutes ago, xilopaint said:

 

Please, make it at your own discretion. I really appreciate your effort in supporting CLIs. I just didn't understand why you didn't leave the environment variable with a blank value.

 

Because rather than testing for the value of the variable, I check for the variable existence. Again, no point confusing users that don't need it with an empty variable.

 

New release is out!

 

Thanks for the comment guys. Glad you helped the workflow get better.

[xilopaint]

18 minutes ago, godbout said:

New release is out!

 

Thanks for the comment guys. Glad you helped the workflow get better.

 

Please, change the GitHub link in your first post to https://github.com/godbout/alfred-kat/releases/latest.

Edited June 9, 2019 by xilopaint