Jump to content

Packal: Workflow and Theme Repository

Recommended Posts



I'm happy to announce that after months of development, I'm ready to make a new workflow and theme repository available to the public as an open beta: Packal. Workflows and themes are taggable and searchable. You can add in the icons, screenshots, long descriptions, and brief ones. There are many different ways to find whatever you need there. Since this is an initial announcement, there isn't much content there yet, except for the workflows and themes that a few kind testers uploaded.


Themes are stored as a simple application URL, which means there are no files to download, but, instead, they import directly into Alfred2. Workflows are scanned for viruses after they are submitted but before they are made available publicly. Workflow authors can easily update their workflows just by editing the page and replacing the workflow file there.


What is even better is that Packal has its own updater for workflows. So, you have the option to update any workflows that you have downloaded from Packal.


I think that these are exciting developments for Alfred, and this sort of repository is what many people have been waiting for since these forums were created.


One great advantage for distributing your workflows via Packal is that you do not need to maintain your own download links for your workflows anymore, so you won't need to worry about download limits on sharing services. Another advantage is that it will receive more visibility as it is a place where people can look for workflows and themes without having to page through the impressive number of posts in these forums.


So, please, head over to Packal, browse what's there, and, very importantly, submit your own workflows and themes.



Edited by Shawn Rice
Link to comment

This looks absolutely outstanding, Shawn! I've been looking forward to this ever since you first mentioned it to me. I'm going to pin this to the top of the Workflows forum :)


Also, a note to anybody who uses Packal... Shawn has done this completely off of his own back and in his own free time, so please don't hound him with feature requests etc. He has hidden a PayPal donate near the bottom of the FAQ, so if you like and enjoy it, a little donation wouldn't go a miss. I know Vero and I will be donating!




Link to comment

Thanks for the support and the pin, Andrew (and the promised donation — it's appreciated but not necessary).


That donation link in the FAQ goes toward me, but you might see other donation links on the Author's profile page. When you register for an account, you have the option to enable a donation widget on your profile page, and those donations go straight to the author, not to me. So, feel free to buy them coffee/beer for their hard work.


I'm open to feature requests, but I've got a few dissertation deadlines coming up, so I won't be able to implement anything new for a bit, but I'll note them all. However, I will jump on bug fixes immediately. So, if anything goes awry, please email me.


And I do encourage everyone to submit their work on Packal. I'd love to see Packal live up to its full potential, but it can't do so unless you, you wonderful workflow and theme authors, upload your hard work.



Link to comment

Well, it would be "official" only if Andrew or Vero declared it as such, but I have no official ties to Running with Crayons or Alfred. That being said, I did have many conversations with both of them about the direction it should go, including security concerns.


While the site can still be much improved, I do think it 's the best infrastructure for giving workflows visibility, keeping great work from getting buried in the forums. When I finish the "update" workflow, then the Alfred2 ecosystem will become all the more robust.


I really do hope that people will continue to to contribute. I get excited when I see new workflows and themes pop-up there.

Link to comment
  • 3 weeks later...

Very impressed with the site.


Have you considered allowing external download URLs? You could copy the file from there to Packal's GitHub repo.


You could check the download URL regularly, download any updated versions and run them through your virus/malware checks.


From a workflow dev's point of view, it would also be one less place to upload the workflow to. You know what devs are like: they hate having to do the same thing more than once …


In that regard, I reckon that if you could implement the whole upload form contents as something that could be updated via a URL to a JSON file a la browser userscripts, it'd be a nailed-on winner.


A lot of the info could be extracted from the info.plist (why am I adding the bundle ID when it's contained in the workflow?), especially if devs wrote the Readme as MultiMarkdown using the standard YAML frontmatter tags. Or a README.md file in the workflow (for tags etc.).


If that were the case, pushing a new version to GitHub (or wherever) with an updated version number would be enough for Packal to notice the new version and update its own database.


That would be pure awesome!


Speaking from my own perspective (and given the state of a lot of READMEs on GitHub, I think I'm better than average in this regard in that I actually do this), it's a real chore to update the GitHub README and the corresponding thread on here and now also Packal. I guess I could now dump the forum thread usage/changelog etc. and just refer people to Packal instead, but I'd still be doing everything twice, and I'd love to be able to just update the repo and have Packal pick up the changes.


Obviously, that'd be a lot of work for you, so I'd be happy to help any way I can, be it with the PHP code (not my strong point) or writing a script that can generate the necessary metadata file(s) from info.plist.

Edited by deanishe
Link to comment

Obviously, that'd be a lot of work for you, so I'd be happy to help any way I can, be it with the PHP code (not my strong point) or writing a script that can generate the necessary metadata file(s) from info.plist.


Those are all features that I have on a @todo list on my computer and on the server itself. I had started to program that Github ping ability to get Packal to update from there, and I've thought about pulling as much of the info from the plist as possible. The most important one would be checking to make sure that the bundleid in the workflow matches the one entered (which is important for the internal logic of the Packal update workflow, still in progress). I've also thought about creating a workflow for developers to push updates from Alfred itself.


BUT... the reason why these haven't been implemented is the part that I quoted from your post.


I've gotten a decent amount of experience working with the Alfred Plists via the Packal update workflow as well as the WHW workflow that I pushed out quite a while ago, and they're interesting to work with, and Apple makes working with Plists in compiled code pretty great, but they're sometimes a pain using interpreted languages. If I knew my python better, then I'd be able to do so easier.


Packal is built on Drupal, which provides many, many benefits, but it also makes it harder to implement some simple features. Another problem with pulling the information from the plist is that many workflow developers don't fill them in. One feature of Packal that I'd like to implement is, during the server-side processing part, to open the plist and fill in any fields information in the workflow file that are blank from the info entered on the Packal page.


As for pushing workflows from Alfred to Packal, I'll need to develop an entire API, which has it's upsides and downsides. Putting more into the front end of the site makes the entire site slower, which is a problem because Drupal isn't necessarily the fastest platform. I've tried to compensate with quite a few caching layers, which has produced some strange artifacts themselves.


On the time aspect, I'll also mention that I'm trying to finish a dissertation this semester, and I have to teach college classes, and I have another fellowship on top of that, so time is, well, scarce. That being said, I'm still making some time to Packal and other Alfred projects. If you'd like to help develop the site, send me an email, and we can talk more about the technicals.

Link to comment

I don't doubt that many devs don't fill in the Readme in Alfred's dialog (it was a long time before I noticed it myself), but the info.plist is a good place to start.


Enter your workflow's URL, hit enter and fill in the remaining blanks … Very pleasant. I reckon that if it were clear to devs wanting to submit their workflows to Packal that they need to enter X or Y into Alfred's sheet (or a README.md/Workflow.md/whatever file), there's a good chance they'll be persuaded if it means they can enter a URL once and only update the referenced file. 


Python is very nice for working with plists (yay plistlib), but only if they're in XML format … and Alfred saves them in XML format. If they're binary, you have to run plutil -convert xml1 /plist/path first. But Alfred generates XML plists, so parsing them without a Mac is not an insurmountable problem.


Regarding helping development, I'd be happy to (I have a fair amount of free time). As I say, PHP is not my strong point, and I know naff all about Drupal, but I'll PM you my email address. Perhaps I can contribute something.

Link to comment

I've gotten a decent amount of experience working with the Alfred Plists via the Packal update workflow as well as the WHW workflow that I pushed out quite a while ago, and they're interesting to work with, and Apple makes working with Plists in compiled code pretty great, but they're sometimes a pain using interpreted languages. If I knew my python better, then I'd be able to do so easier.



FWIW, this'll convert a Plist to JSON and spit out the result if you'd rather work with another language. plutil -convert json /file/path.plist does the same on a Mac.

# encoding:utf-8
# plist2json.py

from __future__ import print_function
import sys
import plistlib
import json

print(json.dumps(plistlib.readPlist(sys.argv[1]), indent=2), file=sys.stdout)

plistlib.py itself would be pretty easy to translate to any other language with an event-based XML parser.

Edited by deanishe
Link to comment

plutil -convert json /file/path.plist does the same on a Mac.


'plutil -convert json' vomits on many plist elements, like dates and data fields. Don't use it on system plists, it'll fail randomly when some app stores something in the plist that plutil doesn't like. 

Link to comment

You can also user PlistBuddy, which has been native for quite some time. Strangely, you have to invoke it from the full system path: /usr/libexec/PlistBuddy.


Although, what's really important, is that if we want any of this to happen on the server rather than the user's computer, we can't use any of these utilities (except for python modules and the like) because I don't think Ubuntu can work with them. There is a nice PHP class that can deal with most every kind of plist, however, which is pretty great.


We can keep talking more about this privately. And if anyone else has an interest in helping implement these features, then feel free to contact me.

Link to comment

Just a note, Workflow authors can now use Markdown for the Workflow descriptions. Under the description text field, click on the drop-down box, select Markdown. The field might get a little small (I'll fix that later), but you can just grab the bottom of it and pull down.


Here are a few images to show you.













Edited by Shawn Rice
Link to comment

Can you send me a PM and let me know what the errors were? It seems like most of the errors come from missing a required field (usually the version number, which has placeholder text, forgetting to press "upload" after choosing the workflow file, or not checking a category.) Others have been getting workflows through, so it should be working.


Send me a PM.



Link to comment

to show others the development I post the error report here:

* select file to upload

* click upload

Result: File doesn't show up.

* retry select file to upload

* click upload

Result: File often shows up

* Do this with all upload data

* fill out every field with a "*"

* click submit

Result: Long loading time; redirected to the fill out form; sometimes it resets parts of the form or the form in general

* retry all above again

Result: sometimes an overlay pops up showing an AJAX error message. Sorry, did not copy it.


Currently I don't have more time to spend to go into details or retry everything again or at least get the error message again. I am studying computer science and I know how evil bugs are, which aren't easy to reproduce.

I hope you can find some repetitionable errors by examining my report. Sorry again I did not save the error msg =]


In any case: great project =D would appreciate to see it working for me.

Link to comment

I've had similar problems before with Packal. It appears to be related to the aggressive caching (at least in some cases). The upload etc. is actually working, but the form isn't updating correctly (i.e. an old, invalid version is coming from the cache). Mashing the save button a bunch of times sometimes persuades it to update.


Shawn: Can't you turn off caching on the upload/update part of the site? Traffic to that part of the site is surely rather minimal.

Edited by deanishe
Link to comment

I know the general roadmap, I was just wondering if it will be dependent upon users to check for updates periodically, or if it will be possible to prompt users to update. That is, will the final product be dependent on the user for keeping workflows up-to-date, or will there be a mechanism that will allow the workflow creators to help people keep their version up-to-date.

Link to comment

The general roadmap is all there is at the moment.


I imagine that users will have to manually ask the Packal workflow to check for updates. Alfred offers no way to schedule actions, so having an automatic background update check would require us to implement something outside of Alfred. If we wanted to post notifications, we'd have to release an app on the App Store …

Link to comment

Simply as a thought-experiment, would it be possible/helpful/permissible to add some sort of update checking into Packal workflows? 


Here's one possible implementation: Use a Outputs -> Run Script which all of your workflow actions pipe into. This script will make a call to the Packal page for that workflow (use some sort of id for this). Packal will return a simple JSON string, which will include the version number of the workflow housed on Packal. If that number differs from the version being used, then prompt a reminder to update. Clearly this would require a JSON file in the workflow which holds the installed workflow's version. 


Now I believe this is similar to the now-defunct Alleyoop set-up. I started writing workflows after this system died, so I've never used it, but it doesn't seem *too* difficult to implement something like the above to make it easier to know when to update. 


I press this issue as someone who has a complex workflow that had fairly limiting bugs in early versions. When I fix a bug, I want everyone to have the new, better version. And I can't trust everyone to regularly check for updates. It just seems like a highly beneficial feature. 

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