This is necessary so that Launch Services in OS X picks up changes
to the Info.plist file describing various aspects of the application.
See https://bugzilla.mozilla.org/show_bug.cgi?id=600098 for an example
of the kind of issue that failure to do this can lead to.
gtk_window_set_default_size() has no effect when the dialog
is marked as non-resizable with gtk_window_set_resizable(),
so the minimum size is instead achieved by setting a minimum width
on the progress bar.
* Centralize the error message text shown to the user in the event of a problem
installing the update in AppInfo::updateErrorMessage() and add a section
suggesting that the user should download a new copy from mendeley.com
The generated file_list.xml needs to specify the path
of the main binary and the name of the updater binary
to download. Change the format of the JSON config file to
allow these paths to be specified there.
* Update create-packages.rb to add the <is-main-binary> attribute
to the appropriate entry in file_list.xml
* Modify the sample config file
* Improve documentation in create-packages.rb
Build the GTK dialog as a separate shared library which
is embedded into the main updater binary.
At runtime the updater extracts the shared library and attempts to load it.
If this succeeds, the GTK UI is used, otherwise the updater will fall
back to something else - currently a silent install.
The current update dialogs do not support retry/cancel - if a file
cannot be installed the update will just fail with an error and
any partial install will be reverted.
The ability to prompt the user to Retry/Cancel file writes during installation is less
necessary now that we can move files that are in use. Without retry/cancel support
the update installation will just be canceled if it fails.
Following the change to FileOps::removeFile() to support 'removal'
of files that are in use in Windows, the cleanup of the updater's
temporary directory can be performed from the non-elevated updater
setup process once the main install process has returned.
This removes the --mode cleanup run mode in the updater.
* On Windows FileOps::removeFile() fails for updater.exe
since that file is in use by the current process.
Whilst it is not possible to remove the file whilst it
is in use, it can be moved or scheduled for deletion on reboot.
This commit changes FilesOps::removeFile() to simulate the
behavior of unlink() on Linux by moving in-use files to
a temporary directory and then scheduling for them to
be removed on restart.
There is no locking on the Log file so conflicting updater processes
may corrupt each others' entries - although in practice this has not
been a problem yet.
Previously the application was restarted from the main install process, which may have
been elevated. The main application must be started from a non-elevated updater/updater.exe
process otherwise the main app will inherit the elevated status from its parent.
* Modify ProcessUtils::runElevated() to return the status code of the process
* Change UpdateInstaller to run the main installation synchronously from the initial
updater process in the case where elevation is not required.
* Remove calls in main.cpp to relaunch the main application after the UI is closed.
* create-packages.rb takes an input directory containing all files as they are laid out in
the installation directory of an application, a JSON file mapping files to packages and
generates the file_list.xml file listing all files in the release along with the
.zip packages containing those files.
* Add single-package-map.json which is the simplest possible package map - putting
all files in a single package.
Per-project/build package maps can be written that separate files into different packages
based on the component they belong to.
This script replaces the autoupdate-setup tool written in C++ in the utilities/autoupdate-setup
directory in the desktop source tree.
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>
