Chris's code-related ideas, plans and proposals

At least one of our applications doesn't work with spaces in its path (Stellarium Portable). The solution with it is that the launcher pops up an error message box if you run it with spaces in the path. This could be improved with an extra thing in AppInfo to specify applications which can't cope with spaces in paths; then the LeaveDirectory function in PortableApps.comInstaller.nsi and the Launcher could pick this up, so that you can't install it to a location with spaces, and to make it much easier to block running where it'll just crash.

Long path fixer

(PortableApps.com Installer, PortableApps.com Launcher)

As above with detecting problems with spaces. In the PortableApps.com Installer wizard, scan the App directory to find the longest path that it will have to deal with, and then add a snippet to the LeaveDirectory function in PortableApps.comInstaller.nsi to complain if they specify a directory longer than 254-StrLen path characters long. For example, in OpenOffice.org Portable the longest path name is App\openoffice\share\uno_packages\cache\registry\ com.sun.star.comp.deployment.configuration.PackageRegistryBackend\ registry\data\org\openoffice\Office\Linguistic.xcu (165 characters, spaces added for line breaking) so it would restrict the installation path to 89 characters (89+slash+165=255 which is the longest safe path length). What's more, also this length should be placed somewhere where the PortableApps.com Launcher will see it (putting it into AppInfo seems a good idea, maybe we could have a section [Limitations] which the installer wizard would add it to) and complain if it's too long (as with the above space-in-path). This would also tie in with portable application directory moving.

Moving the application to a different directory

(PortableApps.com Launcher)

Many of our applications (Songbird comes to mind) can't cope with them being moved to a different directory. Drive letters we can cope with, but sometimes we won't be able to cope with moving. Plan A: make it so that the PortableApps.com Launcher (and our implementations with the Launcher) will always update all paths. Nice idea, but I'm not sure if we'll be able to handle it too easily. I'll see. Plan B: make the launcher detect when it goes to a different path (not just drive letter) which is easy, and then warn the user that it may not work because they did that, are they sure the want to continue? We could also do it as a field in the launcher configuration, so that the launcher will "know" that it will work fine (ignore), or there are side-effects (warn) or that it won't work (stop them before they corrupt things).

Unified Subversion password management support

(PortableApps.com Launcher)

Currently we have a couple of applications in development which work with Subversion. My own Subcommander Portable [2.0 Beta 4] currently doesn't keep saved passwords with it (which is bad), and gluxon's Eclipse does, but there is a problem when we have multiple applications which "do anything" with Subversion passwords. If you tell the SVN client to save the password you enter, it will be saved (by the SVN client backend) in $APPDATA\Subversion (and you can't get round it with any environment variable changing). Thus we can see that the data has to be backed up and moved, the way we do with various things. Now let's pose a scenario; I fix Subcommander so that it backs up to $APPDATA\Subversion-BackupBySubcommanderPortable, while Eclipse still uses $APPDATA\Subversion-BackupByEclipsePortable.

1. Open Subcommander Portable [SP]. Local settings in -BackupBySP, SP saved passwords local.
2. Open Eclipse Portable [EP]. Local settings in -BackupBySP, SP saved passwords in -BackupByEP, EP saved passwords local.
3. Save passwords, use saved passwords, get things all muddled further...
4. Close SP [warning bells ring... closure not nested]. EP passwords in SP (!), local passwords local, SP passwords in -BackupByEP.
5. Close EP. EP passwords in SP, local passwords in EP, SP passwords local. Whoops. Big security hole there.

This is pretty obviously a problem. So I need to write a snippet of code which will backup to a consistent location, and store Subversion settings in a common location - I reckon that CommonFiles\Data\Subversion would be a good location. The applications will then find one another (write a file in $APPDATA\PortableApps.comSubversionSupport.dat which will identify all the applications using it), and if we get applications which will be using different sets of Subversion passwords (e.g. F:\PortableApps\SubcommanderPortable and then run G:\PortableApps\EclipsePortable), don't copy the new lot of passwords across and just warn the user that any passwords used will be a different set of saved ones or something. This bit is the hard bit to do well. On closure of all applications with a line in this $APPDATA\PortableApps.comSubversionSupport.dat, the last one will move the files back to CommonFiles\Data\Subversion and restore $APPDATA\Subversion-BackupByPortableApps.com.

Unified Qt registry support

(PortableApps.com Launcher)

Cleanup implemented.