deanishe

Umm, I take back my previous comment. It doesn't really work with any workflow. The "download" link just points to GitHub's <repo>/zip/master link, which is a zipped copy of the source code, and not appropriate for the vast majority of workflows. For some repos, there may be an .alfredworkflow file inside the zip that can be easily installed. For others, such as Vítor's monorepo, there'll be dozens of .alfredworkflow files in there. In many other cases, the user will either have to: Copy the unzipped directory to Alfred's workflow directory, Copy a subdirectory of the unzipped repo to Alfred's workflow directory, or Install a complete Node/Go/Swift/whatever development environment in order to build the workflow. Just changing the .zip file to .alfredworkflow file will not work in any situation. For a very large proportion of workflows that aren't in monorepos, the .alfredworkflow files that Pacmax should be linking to for download are found in the GitHub releases, where built programs are supposed to be. I presume that means that people only have to paste a URL in the box instead of submit a pull request (which is a complex procedure if you're not familiar with git and GitHub). @mjwalfreds I've noticed that someone has submitted a bunch of my workflows to Pacmax. I'd like to ask you to remove them at this time. I don't want to be fielding support requests from people who downloaded a copy of the source code from Pacmax instead of the .alfredworkflow file from GitHub releases, and don't understand what's going on.

I've just been testing Pacmax. It doesn't appear to like "monorepos", where a user keeps all their workflows in a single repo (or perhaps I didn't wait long enough).

By first fixing Firefox, tbh. The post Vítor linked above explains the problem with Firefox. In order for most browser workflows to work with Firefox, Mozilla must first uncripple its support for external scripting.

@LaurentP also hasn't posted since then, so I wouldn't hold your breath…

Is there an objective reason why I should implement this change? I don't really see the point myself. OTOH, I don't work seriously with numbers, so I'm always open to making justifiable changes.

Shawn (the developer of Packal) had a field for a PayPal email or URL (I don't recall exactly). That would presumably require user accounts, though. I don't think donation links for workflow authors is important, but I think you really ought to at least mention the workflow authors. Every comparable site I know, from packagecontrol.io to npmjs.org to packages.debian.org lists the developer/maintainer. Have you tried Vítor's workflow? It's tuned for this forum and the awful, buggy Invision editor. You might get used to it, but I don't think anybody likes it. It's riddled with annoying bugs.

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.

Why did you post the link in the first place, then, if you think it's a bad idea to submit workflows there?

Yeah. In that regard, I'd be much more amenable to a fully-automatic, no-user-input site that just scans for GitHub repos tagged with alfred-workflows. Workflow discovery is definitely a problem (a forum is a pretty crappy format for that), but "here's another site to submit your workflow to" worsens the situation, rather than improves it, even if the site itself is good. The "Awesome Alfred Workflows" list is a different matter, imo, as it's a curated list, not a free-for-all (and importantly, maintained). And given decent curation—and I believe Dave is doing a good job in that regard—there's definitely value in it.

Not really, no. Like I said, this isn't an issue with Alfred. Alfred is getting the bad UTI (dyn.ah62d4rv4ge80g55r) from your system. There's nothing Alfred can really do about that. And if this only happens with folders under your ownCloud directory, then it's most probably an issue with ownCloud (or ownCloud+Mojave). In any case, the output from Alfred's metadata tool (which Vero linked above) might be of some interest/use. FWIW, dyn.* UTIs aren't random. This one means "file extension = com".

Saw that, too. Looks good, but I'd feel much better about it if the gent who built it were at least a forum member. Packal was never official, but it was built in close communication with the Alfred team. Yeah, it's somewhat similar to the frontend I've been planning to build (though my plan includes a spider, not just manual submissions). I've been waiting for Alfred's built-in update mechanism to crystallise, so there's a standard metadata format to work with, rather than having to build a (hit-and-miss) spider.

If this is the case, it might be a good idea to ask on an ownCloud forum. There are doubtless some ownCloud users on this forum, and they may be able to help, but as this problem is related to the system metadata index—not Alfred—you'd probably have more luck finding someone who knows what's going on on an ownCloud-related forum.

Hi @kstoff, welcome to the forum. Nope, I don't think so. I believe this is due to the way the system metadata index (which both Spotlight and Alfred use) resolves the search scope. AFAIK, Alfred's search scope works in the same way as the -onlyin option to mdfind (the CLI version of Spotlight) or Finder's search (in this case). The upshot is that search paths don't cross partition boundaries, so although a global search will find stuff anywhere, once you specify a search path (even /), you will only get results that are on the same partition. That is to say, you currently have to specifically add each partition to Alfred's search scope, just as you would have to add an -onlyin /Volumes/blah for each partition to an mdfind command. You can see the same behaviour in Finder if you explicitly "Go To Folder…" /Volumes (which is hidden by default) and try to search for something. I believe the only solution would be for Alfred to special-case the search scope item /Volumes and explicitly add every mounted partition to the search scope on each search.

I don't think that's necessary, tbh. The new posts in this thread will have bumped it back to the top of the forum, and the Alfred team are almost certainly following the discussion, even if they haven't weighed in yet. If I had to guess, I don't think an option will be forthcoming, but I'd say there's a decent chance of getting ^J and ^K added as additional keyboard shortcuts. Unless Andrew is an emacs guy, of course…

Hi Philippe, welcome to the forum. I'm afraid the answer is "no". Alfred uses the same index as Spotlight, so if Spotlight can't see something, then Alfred can't either. This is something that can only be fixed by the pCloud developers (or by configuring it so the files are stored locally).