I wanted to get some opinions on including the instructions for the PortableApps.com Installer within the appinfo.ini files directly, which should eliminate the need for coding installers for most developers. It'll still be using the PortableApps.com Installer as it is now and it will still be GPLed with exceptions (and more exceptions with 1.0), but the code will be autogenerated. I'm thinking the following section at the bottom of AppInfo.ini:
[Installation] DeleteAppDirectory=true DeleteDataDirectory=false DeleteOtherDirectory=true DeleteRootDirectoryFiles=false KeepDirectoryCount=2 KeepDirectory1=App\firefox\plugins KeepDirectory2=App\firefox\searchplugins CheckRunningCount=2 CheckRunning1=FirefoxPortable.exe CheckRunningName1=Mozilla Firefox, Portable Edition CheckRunning2=Firefox.exe CheckRunningName2=Mozilla Firefox InstallerComments=For additional details, visit PortableApps.com. InstallerFileName=Firefox_Portable_2.0.0.14_en-us InstallerLicenseAgreement=eula.rtf
In addition, the Details section will be expanded with ShortName and Trademarks:
[Details] Name=Mozilla Firefox, Portable Edition ShortName=FirefoxPortable Publisher=Mozilla & PortableApps.com Homepage=PortableApps.com/FirefoxPortable Category=Internet Description=Mozilla Firefox, Portable Edition is the popular Mozilla Firefox web browser packaged with a PortableApps.com Launcher as a portable app, so you can take your bookmarks, extensions and saved passwords with you. Trademarks=Firefox is a Trademark of The Mozilla Foundation.
The above will then be used within the installer itself to fully build the installer. For most apps, deleting the App/Other directories will be sufficient to be able to avoid having to do a WinMerge comparison on old/new releases and manually deleting files.
The KeepDirectory entries serve two purposes. First, they let the installer preserve directories used for user plugins, additional fonts, etc without the developer having to keep track of all files. Second, they let the installer more accurately calculate the space taken up by apps for upgrades.
Let's open up the floor...
Curious... why no version in the details section?
It goes in the version section, as it does now. For the above snippets, it'd be:
Sometimes, the impossible can become possible, if you're awesome!
Okay, sorry, I just saw there was some more lines, and was thinking maybe you merged everything. Thanks.
Why would this have any advantage over having an installer.ini in the Other directory?
cowsay Moo
cowthink 'Dude, why are you staring at me.'
It simplifies things a lot. Since all apps will be using the installer, it's essentially part of the format. And there's overlap with the two. So, why not combine them into one thing. That way, when you're updating an app, the only place you need to update a version number, etc is in one file.
Sometimes, the impossible can become possible, if you're awesome!
I think this would work well for smaller apps, however with larger apps like GnuCash or OO.org the installation time would increase by quite a bit if the entire app directory was deleted with each release install.
Also I assume there would be more entries to handle the multi installer and perhaps updaters? I would think you would need at least an InstallerType (standard, multi...).
formerly rayven01
I'm not so sure I like the idea of deleting those folders.
It's either that or coding is required.... or really complicated INIs. Most apps are essentially cases of ditching all of App on each upgrade anyway with small exceptions (like plugins in Firefox).
Sometimes, the impossible can become possible, if you're awesome!
How about adding the opposite of the "KeepDirectory" structure for deletion:
And also for individual files:
formerly rayven01
It'll make it more complicated to calculate install size. And, generally, most apps are ditch all of app types with small exceptions for keeping individual directories (like plugins, searchplugins, etc).
Sometimes, the impossible can become possible, if you're awesome!
It isn't too bad in terms of time increase. I used OO Portable as an extreme test (since it's our biggest app)... and on a drive where OOP takes about 14 minutes to install it only added about a minute to the install time. And the updater shows the files being deleted... so it doesn't just sit there doing nothing.
MultiInstallers we should probably add now... perhaps the following at the end:
Cleanup bits could be handled manually as they are now. The installer will already have a PortableApps.comInstallerPreInstall.nsh and PortableApps.comInstallerPostInstall.nsh in Other\Source for apps needing extra custom stuff... we could do the same as a PortableApps.comInstallerMultiCleanup.nsh.
As for updaters, we can just use the standard installer with App, etc set not to delete. Updaters should only be used exceedingly rarely and only for minor errors like an incorrect file being included.
Sometimes, the impossible can become possible, if you're awesome!
This gives me ideas:
What about Pre-Install and Post-Install code? I suppose you could do something likeDeleteFiles=
and have them separate the folders and the files with a ||I'm bored.
Insert original signature here with Greasemonkey Script.
I like it if things get simplified
And I wondered how long it would be doable to have the installers in their current form as it gets increasingly complicated to include all the files that have to be deleted while updating from different versions.
So if an App doesn't store any additional personal settings (like dictionaries or plugins) in the App folder that cant get moved, I think deleting the whole App folder is a good idea to ensure that the most recent files are there. And for those Apps who do have plugins, the KeepDirectory entry is the way to go.
And its definitively better&easier to have only one ini to update.
EDIT
Whats the benefit of having the ability to delete the /Data folder?
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
Deleting the Data folder could be useful if the base app moved to a new standard for saving it's settings. Of course we would have to include a message informing the user that their data would be lost.
The developer formerly known as ZGitRDun8705