Jump to content

Someone made a successor to Packal to share workflows


nikivi

Recommended Posts

17 minutes ago, deanishe said:

It is, but crucially they all started out that way.

 

There was never a package manager for Alfred, so the main problem isn't a technical one: it's getting developers to add the metadata file you need to workflows that haven't been touched in years.

 

 

That's why I mentioned composer. PHP didn't start out with a package manager, though we had PEAR at some point, but no one really likes that. I've writing PHP for almost 16 years and I think composer has only really existed/been widely used for the last 4 or 5.

 

18 minutes ago, deanishe said:

There absolutely is a need for a good workflow indexer/search engine, and there'd definitely be some buy-in, but many of us are also not keen on getting bitten again by another site for workflows that gets abandoned, and likely won't join in until everybody else does.

 

I know that you don't know me and it probably won't mean anything, but if I were to launch a platform, in whatever way, it would be sponsored and ran by my company. I literally write web applications every day, it's my job, and that won't be changing for a long time. Perhaps the code could even be open source so people could contribute to it, but that's another matter.

 

20 minutes ago, deanishe said:

That's what Pacmax and Vítor's solution get right: anybody can add a workflow. Unfortunately, Pacmax currently doesn't get a whole lot else right and Vítor's solution doesn't exist :(

 

For my part, I couldn't see myself bothering unless it came either from Andrew because that would be official, or from Vítor because he's the maintainer of Homebrew Cask and therefore has a sterling track record at precisely this kind of thing.

 

That's a very good point. It seems like they were all built based on a single persons idea. 

 

Perhaps the way to go forward would be to speak to users and workflow authors alike and figure out exactly what people would want from a site for workflows. Maybe it'd be best to build an indexer/search engine for workflows and go from there. I think that if that worked and it became widely used and popular, that'd open up an avenue for approaching the package manager option as there'd be an audience and level of credibility.

Link to comment

No but I don’t plan to leave the comfort of my editor in order to make it. I have too much invested in optimizing VSCode/Vim and I can’t imagine writing anything without vim at this point. 

 

For mobile I would definitely use React Native but for desktop I’ll wait for Swift LSP to mature or some other framework like Revery

Edited by nikivi
Link to comment
1 hour ago, deanishe said:

JSON isn't the simplest format, but it's better than XML

 

I prefer YAML, but I’m thinking of something most contributors will understand how to write and that will be easy to consume by other websites/services. The universality of JSON is what might make it an appropriate choice.

 

1 hour ago, deanishe said:

It's also a fair bit easier and faster to upload a small metadata file to your own webserver—or just add it to the workflow's repo—than to create a pull request and wait for it to get merged.

 

Having to do the PR dance is why I've never submitted the Alfred-Workflow docset to Dash.

 

Still, I guess someone would write a script to automate submitting the PR at some point, which would take the pain out of it.

 

That’s what I’m saying, I have written such a script for Homebrew Cask that in a single line (that is mostly script-name --flag version) makes all the necessary changes and automatically submits a PR. You never have to even open the Github website. I’ve also made similar scripts for a bot that checks for and submits updates for my own taps. As to getting it merged, we usually do it in a matter of minutes, but even that can be automated with Github actions (we’re doing it).

 

1 hour ago, nikivi said:

This is soo infuriating!

 

It’s also one of the reasons I never touch node Workflows. As interesting as one may look, as soon as I read npm, I close the tab.

 

1 hour ago, deanishe said:

I'm sure you've noticed that an awful lot of Node developers think absolutely everything should be written in JS

 

Two years before node even existed, we already had Atwood’s Law: “any application that can be written in JavaScript, will eventually be written in JavaScript”.

 

1 hour ago, nikivi said:

The developer experience of building an electron app in TypeScript and the ecosystem surrounding it is very hard to dismiss.

 

Not to mention the documentation. The reason I’ve made a few Electron apps and zero native apps (technically I’ve made a few with AppleScript) is that I found immediate clear documentation on the features I wanted. For Cocoa, it’s a struggle.

Link to comment
1 hour ago, ollieread said:

I've writing PHP for almost 16 years

 

About the same for me, but only when I can't avoid it.

 

I understand what you're saying, but it doesn't matter how good the tool is if you can't get people to use it. Most workflow authors aren't, shall we say, "application developers".

 

Hopefully some other "old men of the forum" will chip in with their opinion, but I'm fairly sure that the only way you'll get a majority of workflows to have metadata files is if Alfred itself automatically generates them alongside the .alfredworkflow file. And even then, that leaves the "long tail" of very useful, but largely abandoned, workflows without.


Have you browsed the "Share your Workflow" forum or the workflows on GitHub?

 

1 hour ago, ollieread said:

I literally write web applications every day

 

I don't doubt your commitment. If you write a tool that can generate the necessary metadata file from my existing workflow repos, I'll surely run it on a few.

 

But ultimately, metadata files and GitHub releases and webhooks just aren't something I see a large proportion of workflow authors buying into because many aren't that technically inclined. They just built a simple workflow or two to scratch their own itch, bunged them on GitHub (or Dropbox or Droplr) for anyone else it may be of use to, and posted a link on the forum.

Edited by deanishe
Link to comment
36 minutes ago, vitor said:

I prefer YAML

 

Over JSON, definitely. I kinda like TOML, though. I tend to use that instead of YAML these days, but I'm not entirely sure why. Probably because it's less "magic", and it's more popular in the Go ecosystem, where I tend to be these days. Perhaps I'm just a mindless conformist…

 

36 minutes ago, vitor said:

That’s what I’m saying, I have written such a script for Homebrew Cask that in a single line (that is mostly script-name --flag version) makes all the necessary changes and automatically submits a PR.

 

Okay. I'm sold. Especially if you're the maintainer.

 

36 minutes ago, vitor said:

Not to mention the documentation.

 

Apple's macOS documentation is appalling. Either woefully out-of-date, next-to-useless, or—most often—both.


You should check out Qt. It's a fantastic GUI library, has bindings for loads of languages, and the docs are absolutely wonderful.


In the past, I mostly used wxWindows (via wxPython), but I decided to try Qt for a super-simple app to upload torrents/NZBs a few years ago. And then I re-wrote it in Cocoa last year. Thanks to the awful and wonderful documentation for Cocoa and Qt respectively, it took me longer to figure out how to get drag-and-drop to work in Cocoa than it did to write the entire Qt app.

 

36 minutes ago, vitor said:

“any application that can be written in JavaScript, will eventually be written in JavaScript”.

 

It's true, and I don't really understand why. I get why someone would do it just to see if it could be done. But not why someone would—in all earnest—decide to build something like Electron. It's offensive at every level. A dodgy language on a platform designed for handling as many web requests as possible, bundled with its own, non-shared copy of an entire browser known to be a resource hog.

 

It's the software equivalent of Naked Came the Stranger.

 

Edited by deanishe
Add anti-Electron screed
Link to comment
16 minutes ago, deanishe said:

Do you also cut your bread with your favourite spoon

 

I don’t bread as much as I type. You use Vim too I know, I am sure you wouldn’t be able to stand a day developing in Xcode.  

 

That is considering I already have global vim emulation to a certain level across all apps I use. I just find myself enjoying writing and editing code in vim too much. Neovim embedded in Xcode or a proper Swift LSP is something I wish happens in my lifetime. 

Edited by nikivi
Link to comment
1 hour ago, nikivi said:

You use Vim too I know, I am sure you wouldn’t be able to stand a day developing in Xcode.

 

Yeah, I mostly use neovim. But of course I use Xcode, too. If I want to write a good GUI app, then I should start with a good GUI library. And then I use the editor/IDE that works best with that library.

 

I'm trying to write halfway decent software, not have a great time writing a turd. I don't see any point in epic productivity gains if, in the end, that leads to producing crap.

 

drink-coffee-do-stupid-things-faster.jpg

Edited by deanishe
Link to comment

Hi again all! Just wanted to follow up on a few improvements I've made to Pacmax with your feedback. Have even more in the works for hopefully later this week that should be even more exciting. Here's what's new, though:

 

- Added: Created By field on posts (links to the author's GitHub profile) - this might be my favorite addition
- Added: A scroll to top button for long pages
- Fixed: Rewrote About page to help better explain different aspects related to PM & Alfred; also created a GitHub repo for anyone interested in helping make About better! :)
- Fixed: Styled README section of posts make clearer that they're from the project's repository
- Added: Support for wider screens on Explore (fill it up!)
- Fixed: Pagination on Explore
- Fixed: Last Updated field displaying wrong time
- Improved: Several styles across the site

 

Check out the changes at https://pacmax.org/

 

Thanks!

 

P.S. Great reading all the conversations here. I look forward to more!

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...