iandol

@pankajsz Yes you can control sync direction (bidir, one way etc) see here. Conflict resolution is also configurable, and there is a nice safety net/versioning system to keep old or conflicted copies. Overall very safe. Consuming about 85MB RAM and 0% CPU right now on my system, syncing 65K+ files.
 

 

@Nuno iCloud isn't currently recommended due to being slower at syncing (sometimes not syncing at all for a long period of time), being less reliable and doing a poor job of file conflict resolution.
 
In our internal testing and when supporting users who chose to use iCloud, we saw preferences being lost, especially due to file conflicts where iCloud loses files or reverts to old versions when it's unable to resolve them.
 
We're very keen to improve the sync options and already have a broad plan for this. There are quite a few aspects to doing this well, such as adding an automatic local backup option, ensuring that if syncing goes wrong, you have a recent backup you can go back to, so we'll be looking into this further once Alfred 5 is out and settled.
 
Having said that, if you'd like to experiment with using iCloud, you can do it; Just make sure you keep your preferences backed up using Time Machine or another regular backup service of your choice.

Syncthing has a version that's bundled as a macOS native app. It's open-source, a universal binary so runs well on M1, and hasn't let me down once in over 2 years syncing my Alfred prefs along with 30+GiB of other files between 2 Macs. Highly recommended.
 
https://github.com/syncthing/syncthing-macos

Confirms this now works great, copies the image, resizes it 50% then ships it to ImageOptim to compress it:
 

 
 
 

Made a smaller release with this change and another Finder-related addition (getting selection).

Thanks Vitor, you are leagues above the automation team at Apple!!!

It should, yes. The change to Duplicate will come in the next release.

We have a really exciting roadmap for Automation Tasks during Alfred 5 and into the future, including improved organisation and searching tasks, so stay tuned  

Gosh, can I just say how darn beautiful the new workflow editor looks, Alfred really deserves to win a design award!!! 😍
 
And then sweating the details (accessibility)!
 
And it is super great news that a workflow gallery is coming, and even more amazing if this makes it into the UI itself.
 
Congratulations, just from the screenshots alone this is amazing work!
 
 

Once Alfred 5 is out and settled, the Alfred Workflow Gallery will be our top priority, including integration directly into Alfred.
 
The Workflow foundation changes I've made in Alfred 5 pave the way for some really exiting new features (for Alfred 5.1, 5.2 etc). We'll be sharing details in due course!
 
Cheers,
Andrew  

A new Workflow Gallery website is in the work and will be released after v5, as mentioned by @Vero in this post:
 
 
 

Is there any work being done to make pre-built workflows more accessible throughout the community? I've found myself having to scour this forum and github for existing workflows. Having a dedicated official website or in-app solution for this would be great. That said, amazing work on improving an already great piece of software !

You’re not using the File Action but the Script Filter. Write “remove” there and you should see two options. It happens because you have on Alfred Preferences → Features → Universal Actions → Workflow Script Filters.

When Packal was still active it was GREAT for workflow discovery and the Packal workflow update was amazing! Still haven't found a great solution for updating workflows besides just checking by hand. Or some will update when you run them. 

Usage

Examine your internet connection via the netquality keyword. Analysis takes a few seconds to complete.





⤓ Install on the Alfred Gallery | Source
 

Made a few small updates. Added support for the new notificator and removed support for the old one and terminal-notifier. I also improved the process of getting packages from GitHub, to ensure a .alfredworkflow is downloaded.

You don’t have to add the new version to your Workflow if you don’t want and it’s working fine; nothing was broken, the behaviour is the same.

@iandolThank you! 😊
 
The workflow basically parses the .bib file and caches that, yes. on every run, the shell script checks whether whether the bib file has more recently been modified when the cache file, and if so, re-creates a new cache. So it will pick up new references as soon as they are added to the bib file, yes.

Wow, i only just noticed this. I use Bookends which now auto-syncs to a bib file. My database is ~8000 items. This workflow is super-quick!!! I assumed it was using some sort of native code voodoo, but no, this is made from well-made shell scripts and JXA javascript. Really nice feature set, and includes cheatsheets and other things like a CSL downloader. I would heartily concur this is the most elegant citation picker yet created!
 
Chris, what happens when the bib file is edited externally, does this workflow cache the contents or will it pick up new references when they are added?
 
Beautiful workflow, congratulations Chris!!! 

When configuring a Run Script or Script Filter, Alfred provides a Language dropdown listing the runtimes which have historically been included with macOS. But what if you want to run a script from another language which you have installed on your system? Be it Node.js, Lua, or something else, it’s dead-simple to call them. Either:
Save your script with a proper shebang (examples: #!/usr/bin/env node; #!/usr/bin/env lua) and use External Script as the Language, pointing to your script. Use /bin/zsh (or /bin/bash) as the Language and tell the runtime to call your script (examples: node MY_SCRIPT.js; lua MY_SCRIPT.lua). The first executes (marginally) faster but the second allows you to send preset arguments to your script. They work as they are assuming the languages were installed with Homebrew, as Alfred includes its directories in its PATH.

I do have some other code that makes the python=python3 assumption, and in my case I have to flexibility to go this route. I totally agree for most users the Alfred instructions, along with your willingness to step in and your hard work in making this solution work is much appreciated, thank you!!!
 

They shouldn’t assume it. While is is possible for python to link to python3, code which relies on Python 3 should call python3—that’s the official name of the binary.
 
 
Naturally, you are free to edit these to your heart’s content and build your own setup as you desire, but the updated Workflows listed here are updated in the way they can remain closest to the originals.

I agree! Which is why I prefaced it with qualifiers such as “seem” and “unlikely”.
 

The beta which introduced this change was announced only recently. Again, no one predicted they would deprecate Python 2 in a point release. They handled PHP better.
 

I do not understand your anger. You didn’t post in the right place to begin with and it’s back where it started. Nothing has been taken away from you.
 

No, my reply was getting off topic. And because it was safe to assume you would want to respond, I didn’t want to derail that thread which is for user requests of Workflows to fix.
 
You may disagree, but I don’t like when I’m subscribed to a thread and keep getting off topic notifications. I aim to extend that courtesy to others. If you frequent the forum, you’ll know I’m consistent about it.
 

Which is exactly what is happening. The thread is still visible and at the top of new conversations in the main forum page. If anything, it’s getting more visibility. Just now it got another reply by another user. All I wanted was to avoid derailing a thread where I need to pay attention to every post to be able to help effectively.
 

That is patently not true, and verifiable by anyone who frequents the forum. I am engaging you in good faith and would appreciate the same courtesy.
 

That is not how this community works. To my knowledge, only spammers have ever been banned. But I will ask you to moderate your tone if you do decide to engage further. Alfred aims to foster a friendly community.
 

Which is a valid choice. But please understand you are in the minority. I have always been upfront that the ideal outcome is for those Workflows to be updated but that requires the creators to do it. Or for the community to help. Both are happening as we speak and everyone is welcome to contribute.

Respectfully, that is unreasonable and unfair.
 
With only six posts in the forum, you don’t seem to be a regular. Otherwise, it is unlikely you’d have that view regarding Alfred’s community management. Every post in this forum—the official venue for discussion—is read, and it’s rare one does not get a reply.
 
This could not have been completely avoided. (Most) Workflows are by third-parties and Alfred is flexible, it makes no demands over what language those people develop in. Many chose Python 2 because it is popular, shipped with macOS (Workflow developers tend to value minimal setup needed for users), and it continues to work. An overwhelming number of those Workflows were made when Python 2 was still supported and they weren’t updated (which is also up to the individual developer and contributors) because they didn’t need to be.
 
Everyone knew Python 2 was going away; nobody expected it to happen in a point release. There’s little point in continuing to discuss that. Apple decided it and it is done. This wouldn’t have been disruptive if the Python team hadn’t botched the transition, but that too is done. They survived and learned. That is not in the slightest a reflection of Alfred’s underlying architecture, which uses the tools Apple provides.
 
Finally, this is not scrambling. The workaround has been pondered and developed in a way to be the least disruptive to most people, getting them up and running fast without continuous futzing. The instructions install Python 2 in a self-contained fashion, meaning you can get rid of it easily and at any time. Ideally those Workflows will be ported, but that’s outside Alfred’s sole direct control. The community is discussing how to proceed. Reinstalling Python 2 and updating Workflows by request should help prioritise those the community cares the most for.
 
I split the conversation into its own again because it’s getting too off topic and I want that thread to remain focused.

I’ve updated it since, in preparation for when Ruby gets removed from macOS. If you installed with Homebrew, you’ll be able to see the update.

@michbsd Please don’t post in multiple places. That makes the conversation more difficult for everyone, including people coming after.
 
@Smpl Technically it’s not using Homebrew, it’s using pyenv. But the reason is the same: installations are self-contained and don’t affect anything else on your system. If you ever decide you no longer want Python 2, you delete ~/.pyenv and the symlink and you’re good to go. In contrast, the download provided on Python’s website is a PKG installer which can do anything and will leave you with receipts. Plus, they don’t provide a v2 installer for Apple Silicon.