Instead of moving the whole <update> section to an embedded <update-v3>
node, just use a different name for the <install> section since older
clients will ignore the new <packages> section.
For older clients:
* The <install> section lists the packages to download. This will exist
in addition to the <packages> section.
* The real <install> section listing the files to install is renamed to
<install-v3>
* Add WIN32 flag to add_executable() so that cmake generates a GUI application
* Add WinMain() entry point which converts the unicode command line arguments to ANSI and then calls the standard main() entry point.
The unit test continues to pass although I am not sure whether
converting command-line args from Unicode to ANSI will cause problems
with filenames passed on the command-line that contain non-ANSI
characters.
std::string::npos is defined as the unsigned type size_t but given a value of -1,
resulting in a warning when trying to compare an unsigned int with a size_t.
Fix this by declaring pos as a size_t.
* Fix ProcessUtils::runAsyncUnix() not returning a value
* Fix UpdateDialogGtk::updateRetryCancel() not returning a value
* Add missing includes in TestUpdaterOptions.cpp
* Fix unsigned/signed int comparisons
This prevents the dialog being closed part-way through update installation,
leaving the user unable to restart the application afterwards by clicking
the 'Finish' button.
UpdaterOptions::parse() will probably not have a need to modify its
arguments but for consistency with the declaration of main() it takes a char*,
so strdup() the strings.
In the event of a failed update, display the details in a message
box and allow the user to restart the old application once the
update has been reverted.
Details of the problem will also be written to the log file.
This prevents the user closing the dialog whilst the update is in
progress. Once the update has been installed, the user can click
the 'Finish' button to close the dialog and restart the application.
* Link the updater application with the Cocoa framework on Mac
* Construct a UI in code and display it when running the main install process.
Usually UIs on Mac are contained in a .nib file created with Interface Builder
but in this case the UI is created directly in code to meet the single-binary requirement,
although it may be possible to bundle the .nib into the binary itself.
* Add support for entries in the update script being marked with
a boolean <is-main-binary> attribute which is set to true for the main binary.
* In UpdateInstaller::restartMainApp(), look for the file marked with <is-main-binary>
and restart it after installation. With the current structure, this requires that
the main binary is included in the update, which has always been the case up till now.
If we find that we want to do updates that do not affect the main binary, the
<is-main-binary> attribute could be replaced with a <main-binary> string value
at the top of the XML file.
* Add optional GTK mode to the updater build. This pulls in a large number of extra dependencies,
but dependencies which should be fairly ubiquitous on Linux systems. If these dependencies prove
to be a problem we could look at providing an alternative, more basic UI and loading the appropriate
UI dynamically.
* Implement update progress dialog for GTK. The dialog needs visual polish but is functional.
* Set the --wait argument when launching new updater processes with the ID of the process to wait for.
* Add ProcessUtils::currentProcessId() utility method and PLATFORM_PID define
The old syntax uses a series of Key=Value pairs, instead of
the more standard "--key value" syntax.
This is required so that the old Mendeley Desktop versions can
launch the new updater.
* Support XML scripts where the V3 script is wrapped in an <update-v3> element.
* Add some basic unit testing facilities - if we find that something more sophisticated is needed,
we can look at using cppunit, googletest or similar.
* Add a test that parsing the same script with both the old and the new structure
yields equivalent UpdateScript instances.
* Add FileOps::fileName() to get the base name for a file
* Add ProcessUtils::runSync() to run a process, wait for it to exit and then
return the status code from that process.
* Change ProcessUtils::runAsyncUnix() to use execvp() in order to search PATH
for the specified binary if the filename is not absolute.
Prepend the install directory to the file path specified in the
<uninstall> section of the XML file to get the path of the file
to remove.
If the file cannot be uninstalled because it does not exist,
log a warning and continue.
The cleanup is currently run in another process - on Windows for this to
work the updater will need to be run from outside the temporary installation
directory. Running the cleanup from the updater binary in the temporary
directory will fail since the binary to be removed will then be in use.
On Linux, Mac the cleanup could just be run from the main update installation
process.
This test compiles two 'versions' of an application,
then runs a script which creates an install directory containing
the 'old' app and a directory containing a file_list.xml update script,
a copy of the updater and a zip file containing the 'new' app.
The script then runs the updater, then runs the installed app
and checks that it is the new version.
* Add ProcessUtils::currentProcessPath() to get the path to the current application
and add a Linux implementation.
* Implement ProcessUtils::runAsync() on Unix using fork/execve.
* Setup updater to run the main installation phase with the correct arguments.
* Add '.zip' to the package name to get the path of the package file.
