Alfred KAT

[nammin]

is there a way to copy the magnet so i can open it with peerflix?

[godbout]

there's a bug in Alfred that if sometimes you press command while choosing a result it will copy it to the clipboard. may be worth a try?

[godbout]

 

🙈️🙈️🙈️

[godbout]

anybody cares giving it a try? https://www.dropbox.com/s/t4blftd0x160546/KAT.alfredworkflow?dl=0

 

to make sure there's no issue with Developer ID bullshit and some other libraries missing crap. thanks!

[JJJJ]

3 hours ago, godbout said:

anybody cares giving it a try? https://www.dropbox.com/s/t4blftd0x160546/KAT.alfredworkflow?dl=0

 

to make sure there's no issue with Developer ID bullshit and some other libraries missing crap. thanks!

It works for me with no issues. Thanks for the workflow.

[godbout]

fantastic. thanks for the letting me know.

[godbout]

latest release version available here: https://github.com/godbout/AlfredKat

 

working the same as the previous one, but no PHP interpreter needed. ✌🏼️

[godbout]

 

👀️👀️👀️

 

https://github.com/godbout/AlfredWorkflowUpdater

 

👀️👀️👀️

[godbout]

On 3/21/2021 at 12:56 AM, godbout said:

anybody cares giving it a try? https://www.dropbox.com/s/t4blftd0x160546/KAT.alfredworkflow?dl=0

 

to make sure there's no issue with Developer ID bullshit and some other libraries missing crap. thanks!

 

ok so next time i need to write down how to release a Swift command line too with proper Developer ID AND embedded libraries coz i can't find how to release the next version 😂️😭️

[godbout]

version 6.1.0 available: https://github.com/godbout/AlfredKat/releases/tag/6.1.0
 
now Alfred Kat detects if there's an update available. if yes it appears as the first result item. you can download the update, or go to the release page.
 
currently it's checking for an update each time you use the Workflow. it's still fast, but not ideal. pondering the best way to avoid the constant check but still having a good UX. like automatic check, but still ability to force-check without having to fiddle around the Workflow Environment Variables. in conclusion, don't download this update. thanks.

[deanishe]

25 minutes ago, godbout said:

like automatic check, but still ability to force-check without having to fiddle around the Workflow Environment Variables.

 

Require the user to enter a specific query to force a manual check. Have a "Check for Update" result, but only show it if the query is "upd" (or a longer substring of "update").

 

In most workflows that use my libraries, entering "workflow:update" as the query will force an update check.

[godbout]

13 minutes ago, deanishe said:

Require the user to enter a specific query to force a manual check. Have a "Check for Update" result, but only show it if the query is "upd" (or a longer substring of "update").

 

In most workflows that use my libraries, entering "workflow:update" as the query will force an update check.

 

yes that's what i have in mind. but it's still too early to make decisions. i need to digest. like automatic frequent check, what does that mean? every week? every two days? do i allow a power user to change this from Workflow Variable? what keyword? i like "u" like "kat u". "time u". but that might only make sense for Workflows that have a delay before calling the ScriptFilter? what about if it's instant? etc etc. i don't want to think too much in advance but i'd like to still see this as a Workflow functionality rather than just for the Kat Workflow. so, still need some thinking. and i wanted Alfred Kat with the update out of the way 😀️ i can't handle more than three tasks in my todo list.

[deanishe]

Have a look at the way my libraries' updaters work, and how OneUpdater does it.

 

24 hours is a good interval, I think. It's what most apps use.

 

10 minutes ago, godbout said:

do i allow a power user to change this from Workflow Variable?

 

No. Why? If they're a power user, they're capable of deleting the appropriate files from the cache to trigger an update.

 

11 minutes ago, godbout said:

but that might only make sense for Workflows that have a delay before calling the ScriptFilter? what about if it's instant?

 

Don't do remote checks in a Script Filter. Fetch the list of available updates downstream of the Script Filter or in a background process. Consult the cached list of releases if you need to show something in your Script Filter.

 

[godbout]

32 minutes ago, deanishe said:

Have a look at the way my libraries' updaters work, and how OneUpdater does it.

 

i haven't checked yours coz i don't get much python. OneUpdater i had a look a few weeks ago and actually added it in Kat 6.0.0 but removed it in 6.0.1, i didn't like that it was breaking my flow when i wanted to use the Workflow and just launched the update. but maybe i haven't checked thoroughly and missed something. but again at the end i built my own thing 😐️

 

34 minutes ago, deanishe said:

24 hours is a good interval, I think. It's what most apps use.

 

now that you've mentioned further down downloading and caching the releases info that makes sense yeah.

 

35 minutes ago, deanishe said:

Don't do remote checks in a Script Filter. Fetch the list of available updates downstream of the Script Filter or in a background process. Consult the cached list of releases if you need to show something in your Script Filter.

 

i hadn't think yet of caching the list of releases. good point, thanks. as usual i'm building for my current needs and the last few Workflows i did scrap some page or reach some APIs and coz it takes time anyways i didn't bother. but for something quick yeah, you definitely don't want the release check to slow down. don't know yet how to do background processes in Swift. that's the next step of the library i'm building for updates. ultimately if i didn't screw up the research i should be able to rerun a Script and show the download progress in an item that is not valid. but no idea how to start and even less grab back info from another process. 

[deanishe]

49 minutes ago, godbout said:

i didn't like that it was breaking my flow when i wanted to use the Workflow and just launched the update.

 

Yeah, I don't like that either, but it's essentially unavoidable given its simple, bolt-on nature. My updaters are arguably more user-friendly (depends on how the workflow dev uses them), but they need to be properly integrated into a workflow and aren't as flexible as OneUpdater.

 

49 minutes ago, godbout said:

coz i don't get much python

 

The Go one works the same way. The update example shows how it works.

 

49 minutes ago, godbout said:

i hadn't think yet of caching the list of releases. good point, thanks. as usual i'm building for my current needs and the last few Workflows i did scrap some page or reach some APIs and coz it takes time anyways i didn't bother.

 

The caching API is the most important part of my libraries, imo. Any data retrieved from a server or app gets cached (even if only as long as the user is using the workflow) for speed. I think that's actually more important when you're using a language like Swift or Go because you're throwing away near-native performance by not caching data that take a while to retrieve.

 

I'd cache any KAT responses for 5–10 minutes, so when you re-open Alfred to go back to try a different Linux ISO, the results are available instantly.

Edited April 10, 2021 by deanishe

[godbout]

9 hours ago, deanishe said:

Yeah, I don't like that either, but it's essentially unavoidable given its simple, bolt-on nature. My updaters are arguably more user-friendly (depends on how the workflow dev uses them), but they need to be properly integrated into a workflow and aren't as flexible as OneUpdater.

 

yeah, absolutely. not denigrating it at all. pretty smart solution actually. it's just a matter of values i think. i want something for myself that doesn't break my flow, that doesn't do anything too unexpected. so ultimately it wasn't a good solution for me. i've built a library that helps the boring part of checking and fetching updates, but that you can integrate the way you want in your Workflows (menu Item, background download, etc...). kinda best of both worlds for me.

 

9 hours ago, deanishe said:

The Go one works the same way. The update example shows how it works.

 

man that is another level of documentation. but i don't see any *shit* or *fuck* anywhere. is that deliberate?

 

9 hours ago, deanishe said:

The caching API is the most important part of my libraries, imo. Any data retrieved from a server or app gets cached (even if only as long as the user is using the workflow) for speed. I think that's actually more important when you're using a language like Swift or Go because you're throwing away near-native performance by not caching data that take a while to retrieve.

 

makes sense. nice. something to keep in my mind. thanks. the first version of Alfred Time i did was caching some results, but ultimately i wasn't happy. i always wanted the live data. ultimately it was fast enough so that i got rid of the cache. but i don't build enough Workflows i think. if i did i might reach the same conclusion as you. i'm just an amateur Workflow Creator. nothing as professional as you.

9 hours ago, deanishe said:

I'd cache any KAT responses for 5–10 minutes, so when you re-open Alfred to go back to try a different Linux ISO, the results are available instantly.

 

`Linux ISO` LMAO

but i'm not sure i get it. how would that work? like you want to look for another ISO but you see results of the past search first? sounds like noise to me.

 

[deanishe]

1 hour ago, godbout said:

man that is another level of documentation. but i don't see any *shit* or *fuck* anywhere. is that deliberate?

 

I save them for the RTFMs

 

1 hour ago, godbout said:

the first version of Alfred Time i did was caching some results, but ultimately i wasn't happy. i always wanted the live data.

 

Well, yeah. They're basically real-time data. But something like a weather forecast or KAT search results won't really suffer from being 5 minutes old.

 

1 hour ago, godbout said:

how would that work? like you want to look for another ISO but you see results of the past search first?

 

Cached results are keyed by search query. So if you search for "buster", but accidentally grab the ARM ISO, you can very quickly go back and grab the AMD64 one instead because the workflow loads the results for "buster" from the cache. It's basically for the case where you re-open Alfred and hit ↑ specifically to repeat a previous search.

 

I dunno. Perhaps I just select the wrong thing an awful lot, and nobody else actually cares about that.

[godbout]

1 hour ago, deanishe said:

Well, yeah. They're basically real-time data. But something like a weather forecast or KAT search results won't really suffer from being 5 minutes old.

 

hmm true. but probably truer in Germany where when it starts raining it lasts for a week. on islands one minute it's pure fireball the next is deluge. (just trying to find points to fight about 🥊️)

 

1 hour ago, deanishe said:

So if you search for "buster", but accidentally grab the ARM ISO

 

LMAO²

 

1 hour ago, deanishe said:

It's basically for the case where you re-open Alfred and hit ↑ specifically to repeat a previous search.

 

I dunno. Perhaps I just select the wrong thing an awful lot, and nobody else actually cares about that.

 

yeah ok i didn't see the point because in my case i love typing. i would type 1000 times over moving my hand from the home row to press one of the arrow key (although Ctrl+p is acceptable).

 

that's the great thing about being able to write Workflows. each of us can use their brains and creativity to build things that match their quirkiness, and values.

[vitor]

15 hours ago, godbout said:

OneUpdater i had a look a few weeks ago and actually added it in Kat 6.0.0 but removed it in 6.0.1, i didn't like that it was breaking my flow when i wanted to use the Workflow and just launched the update.

 

You didn’t ask, so I didn’t know you were having an issue. That sounds like you were using the wrong option in the wrong place. You should add the Run Script version at the end of the Workflow. That’s the proper way for it to only check for updates after your action is done.

Alternatively, just deleting the open "${HOME}/Downloads/${alfred_workflow_name}.alfredworkflow" line near the end will make it do everything as usual, but it won’t open the Workflow itself. Meaning the user gets a notification that a new version was downloaded but has to manually open it from ~/Downloads at a later time.

[godbout]

2 hours ago, vitor said:

 

You didn’t ask, so I didn’t know you were having an issue. That sounds like you were using the wrong option in the wrong place. You should add the Run Script version at the end of the Workflow. That’s the proper way for it to only check for updates after your action is done.

Alternatively, just deleting the open "${HOME}/Downloads/${alfred_workflow_name}.alfredworkflow" line near the end will make it do everything as usual, but it won’t open the Workflow itself. Meaning the user gets a notification that a new version was downloaded but has to manually open it from ~/Downloads at a later time.

 

hey no worries. yeah, it does actually make sense to put it at the end 😅️ i didn't spend too much time with OneUpdater to be honest because i quickly felt i wanted to 1) show the user there's an update as a result item 2) still have some control over when i update 3) play with Swift 😛 

 

but yours is definitely the way to go if you don't want to be fiddling around and want something that works with any language.

 

 

[godbout]

updated to 6.2.0: https://github.com/godbout/AlfredKat/releases/tag/6.2.0

you can now sort by wo'eva KAT uses as sorting type like "Fight Club ^seeders" to get the highest seeders count first.

you can't mix #tags and ^sorting coz i don't need it and i'm lazy af. ask if you need and i'll implement.

[godbout]

updated to 7.0.0: https://github.com/godbout/AlfredKat/releases/tag/7.0.0

 

dropping support for old macOS versions, and fixing where cache is stored. thanks @xilopaint for reporting.

[godbout]

updated to 7.1.2: https://github.com/godbout/AlfredKat/releases/tag/7.1.2
 

adds the new Updater that works in the background. getting your Alfred Results is therefore faster. next updates will show up directly in Alfred.

[godbout]

updated: https://github.com/godbout/AlfredKat/releases/tag/7.2.0

[godbout]

updated to 8.0.0 for Alfred Gallery: https://github.com/godbout/AlfredKat/releases/tag/8.0.0