Chris's code-related ideas, plans and proposals 5c1v4h

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.crackfree.orgInstaller.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 r3u33

(portableapps.crackfree.org Installer, portableapps.crackfree.org Launcher)

As above with detecting problems with spaces. In the portableapps.crackfree.org 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.crackfree.orgInstaller.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.crackfree.org 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 1q2u4y

(portableapps.crackfree.org 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.crackfree.org 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 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 management gb2v

(portableapps.crackfree.org 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 s 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 s. If you tell the SVN client to save the 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 s local.
2. Open Eclipse Portable [EP]. Local settings in -BackupBySP, SP saved s in -BackupByEP, EP saved s local.
3. Save s, use saved s, get things all muddled further...
4. Close SP [warning bells ring... closure not nested]. EP s in SP (!), local s local, SP s in -BackupByEP.
5. Close EP. EP s in SP, local s in EP, SP s 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.crackfree.orgSubversion.dat which will identify all the applications using it), and if we get applications which will be using different sets of Subversion s (e.g. F:\PortableApps\SubcommanderPortable and then run G:\PortableApps\EclipsePortable), don't copy the new lot of s across and just warn the that any s 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.crackfree.orgSubversion.dat, the last one will move the files back to CommonFiles\Data\Subversion and restore $APPDATA\Subversion-BackupByportableapps.crackfree.org.

Unified Qt registry 40674z

(portableapps.crackfree.org Launcher)

Cleanup implemented.