[Patch][WinGUI] AppData for Queue recovery; GUI Version

[ExDeus]

1. If Queue recovery is meant to be reliable over time, then using the user's temp folder is risky. The Temp folder can be emptied at any time, and it should not contain data needed over time/reboots.

I've created a patch that moves the Queue recovery file from the user's Temp folder to the ApplicationData\HandBrake folder when a queue file is found in the Temp folder, and continues to write the queue file to the AppData folder. If there are files in both the Temp and AppData locations, then the newer of the two files is used.

When a temp file is found, it is first copied to a backup file in the Temp folder. If no file is found in AppData, the temp file is moved to AppData. If a file is found in AppData, then the file is backed up, then the temp file is moved, replacing the original AppData file.

Pastebin: http://handbrake.fr/pastebin/pastebin.php?show=1060 (Edit: Added backup of Queue recovery file if user elects not to restore the queue.)


2. Since we are changing the GUI more frequently than builds are available for the CLI (at least for me, since I'm not setup to compile the CLI), it would be helpful to show both the CLI and GUI versions in the About dialog.

I added a patch to show both versions, taking the GUI version from the assembly info of the HandBrake.exe exectuable.

Pastebin: http://handbrake.fr/pastebin/pastebin.php?show=1058

[s55]

Sorry for not getting back sooner.

1. If Queue recovery is meant to be reliable over time, then using the user's temp folder is risky. The Temp folder can be emptied at any time, and it should not contain data needed over time/reboots.

Wasn't really designed with that in mind. It's more an "App just crashed, restart app". I didn't really feel it as something that would be kept long term.

I see no reason it can't be stored in AppData with everything else. There isn't any need for that backwards compatibility code. You don't really want to recover a queue between versions. If you did that between 0.9.3 and 0.9.4 for example, you would probably run into problems. Users can always copy/paste the file if they are feeling dangerous.

2. Since we are changing the GUI more frequently than builds are available for the CLI (at least for me, since I'm not setup to compile the CLI), it would be helpful to show both the CLI and GUI versions in the About dialog.

The Assembly version is meaningless. It doesn't change between revisions. It's not hooked into the svn revision so doesn't mean much.

[ExDeus]

There isn't any need for that backwards compatibility code. You don't really want to recover a queue between versions. If you did that between 0.9.3 and 0.9.4 for example, you would probably run into problems. Users can always copy/paste the file if they are feeling dangerous.

I wrote the backwards compatibility code because I wanted to use it myself. I believe the risk in leaving it in is low and has the added benefit of keeping users inside the app instead of mucking around in the file system, but I understand if you want to pull it out so it doesn't have to be maintained.

The Assembly version is meaningless. It doesn't change between revisions. It's not hooked into the svn revision so doesn't mean much.

I understand, but perhaps I'm not the only one that changes the AssemblyInfo file to match my build, so I can track what I'm using. Is there a keyword or something that can be expanded inside the AssemblyInfo.cs file to start including svn info?