You are here

Chris's code-related ideas, plans and proposals

Chris Morgan's picture
Submitted by Chris Morgan on November 3, 2009 - 2:34am

This page is mainly for me to note down ideas that I have, which will be mainly about the Launcher, Installer and similar related things (I can't help with the Platform yet so I won't try to offer suggestions). I'll continue to update this page as I develop code for my ideas and as I come up with more ideas. Feel free to comment on the ideas.

Ideas and plans


Spaces in path fixer

( Installer, Launcher)

Implemented in Launcher.

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

( Installer, Launcher)

As above with detecting problems with spaces. In the 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 Portable the longest path name is App\openoffice\share\uno_packages\cache\registry\\ 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 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

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

( 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\

Unified Qt registry support

( Launcher)

Cleanup implemented.

I need to investigate this problem a bit more to come up with definitive answers. I wrote a simple code snippet for dealing with a lot of this here (there, now I can't lose that again so easily), and mainly just need to extend that a bit. The customColors thing will need a bit more looking at.


I think it could help if we add a [Limitations] section to AppInfo\appinfo.ini (or maybe a new file, AppInfo\limitations.ini). This is particularly related to the first three plans above. It will have a few values in it (and more can be added as needed):

  • InternalPathLength=integer - this one will be set by the Installer wizard, to an integer equating to the length of the longest path needed, so that the installer can refuse to install and the launcher refuse to run, in a path ($INSTDIR for installer, $EXEDIR for launcher), the StrLen of which is longer than 254-InternalPathLength characters. This value will not be for developers to set, it will be for internal use only.
  • SupportsDirectoryMoving=no|partial|possible|yes (default possible). The launcher will store in Data\settings\AppNamePortableSettings.ini the last directory it ran in and if it doesn't match (ignoring drive letter) with the current one, then: switch SupportsDirectoryMoving { case no: pop a message box saying it won't work until they move it back and save them from corrupting their data; case partial: warn them that it will probably break something and ask if they really want to continue; case possible: warn them that it may or may not break things and ask if they really want to continue, case true: continue; }

Update notes:

  • 3/11/2009: initial content
  • 21/11/2009: added "UNC paths"
  • 22/11/2009: while updating my NSIS syntax highlighting file for Vim (from 1.91 to 2.45) I noticed ExpandEnvStrings. BRILLIANT! This will improve the efficiency and power of the Launcher a lot :-) (no other changes on this page, just noting it here 'cos I can, and it's definitely related) <– this has been implemented.
    I've also noticed GetFullPathName $0 $EXEDIR\.. which should be able to replace ${GetParent} $0 $EXEDIR with slightly higher performance and (slightly) smaller file size.
  • 27/11/2009: added anchors for quick links
  • 28/01/2010: UNC paths section all implemented
  • 13/03/2010: replaced all instances of Universal Launcher with Launcher
  • 13/03/2010: spaces in paths implemented in Launcher
  • 26/3/2010: removed things which have been done, marked Qt as mostly implemented


John T. Haller's picture

Chris, we'll be building some of this into the universal launcher but moving directories won't be on the docket (or at least pushed to the bottom). It unnecessarily complicates things (especially SQL updates) for a very small subset of users and it's never been supported or recommended for any app (if it happens to work, cool, if not, that's why). Priority is getting the launcher stable and full-featured and fully working with the platform hand in hand.

Sometimes, the impossible can become possible, if you're awesome!

Chris Morgan's picture

I thought as much for moving directories - so I think that at least telling the user about it will be good enough (and that's not hard).

Thanks for reading it Smile

I am a Christian and a developer and moderator here.

“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1