The following is my experience in creating a PAF. I hope this to show any weaknesses in the process.
About the app
The app I am packaging is naively portable, but like most such apps it does not have proper separation of application and settings. It also has the capability of calling another program that has been packaged as a PAF, so I want to edit the default settings to point to the correct path.
First steps
I start with the PAL beta's template, and rename everything as needed to fit the name of my program. I create a folder in the App folder named after the application, and place the executable inside.
Creating AppInfo.ini
I run PA.c Installer and follow its prompts to generate the appinfo.ini file. I answer all the questions, but I've got some concerns about the publisher field which I will touch on below.
At the end, the intsaller creator fails with the error "ERROR: AppInfo.ini - Control - Start is missing.", which is rather odd considering the AppInfo.ini it generated does include that item. Even more odd is the fact that none of the question's I just answered were written to the new appinfo.ini file.
If I run the PA.C Installer a second time, then everything works right, so I believe I've found a bug in the installer.
Concern about Publisher Field
Now about my concern for the publisher field. While I don't plan to maintain this app, I do intend to submit it as a candidate for inclusion as an official PortableApps.com app, assuming I can find somebody willing to maintain it and can verify licensing with upstream. The installer suggests the publisher line should thus be "Developer & PortableApps.com".
That is fine, but the application I am packaging is actually a fork of another application. Thus the majority of the code was written by one person who is upstream's upstream. Upstream itself made some significant code contributions, and would definitely be the correct person to list in a "publisher" line, since he published the exe I actually wrapped. But I also just does not feel right to credit him without crediting the original author of the program.
Thoughts?
Configuring the launcherThis went relatively straightforward.
Creating the icons
This was probably the most inconvienent part of the process. While IcoFX Portable makes this tolerable, it would really be nice if there were a special utility that extracts the Default ICON_GROUP resource of a chosen executable, verifies that all the required icon sizes and color depths are present, and extracting the 16x16 and 32x32 RGBA versions to create the appicon_##.png files. Such a utility would obviously display a report at the end indicating any missing icon sizes to let the user know that use of IconFX or equivalent is needed.
Potentially more to come
I may update this post in the future if I think of anything else about the process that would be worth noting.
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
You shouldn't be using the installer to generate the appinfo.ini
It is the developers of the base app. If you won't maintain it don't bother submitting it. Part of the requirement of having a build relased as official is that you must support the portable build for 6 months or so. I caa't remember the official length of time.
Too many lonely hearts in the real world
Too many bridges you can burn
Too many tables you can't turn
Don't wanna live my life in the real world
I don't intend to submit it. I intend to find somebody who would be willing to maintain it and give them what I have done, they would submit it. If I cannot find anybody willing to do so, I might maintain it myself, but at this stage I'm not willing to commit to that.
As for generating the AppInfo.ini with the installer, don't be absurd. It works for that just fine. If it were not intended to be possible to generate an AppInfo.ini file with the installer, then surely it should simply error out instead of generating a stub file if one is not present.
Obviously it is worth reviewing the generated AppInfo.ini in a text editor and comparing to the specification, but for a simple application with only one executable there is little reason not to use it to generate the AppInfo.ini, since minus the apparent bug it works just fine for that.
The installer is not intended to fully produce an appinfo.ini... at least not yet. It's setup to allow you to interactively enter any entries you may have forgotten (if there is one already) or to start you on the path if you haven't yet created one by creating one with nearly everything... I've been progressively adding to it and it's at the point where it does everything except the Control section. It's an optional mode that is enabled by default to assist newer developers.
Sometimes, the impossible can become possible, if you're awesome!
Well other than needing to run it twice, it seems to be working rather well at producing a basic appinfo.ini, it even seems to generate a reasonable control section for the app in question.
I'd never expect it to be able to handle all the most advanced cases, but the "start you on the path if you haven't yet created one by creating one with nearly everything" you mentioned is really how I was using it anyway.
For example it does not ask for a trademark section, but most of the apps don't need one, and those who do can edit the file manually easily enough. Similar logic applies to almost everything else it does not current ask about.
Would you agree though that the not writing the answers given to appinfo.ini if said file did not exist when the installer is started is a bug?