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.
The zlib build system is not integrated with the updater's build
system. Rather than write a small CMakeLists.txt for the build,
this commit just adds a pre-built version of zlib
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
