* Re-organize the sections into a more logical order.
* Tidy-up the wording of the introduction.
* Add more details to the section on customizing the updater
Add a VERSION_INFO section to the executable's resource file specifying
the product name and description.
The organization is currently set as 'Mendeley Ltd' - other projects
will want to customize this.
When the produced executable is digitally signed, the product name
and description are shown in the UAC prompt asking for admin
permissions.
Mendeley Desktop <= 1.0 clients pass a relative path for the script argument but
run the updater from the directory containing the main application binary instead
of the package dir. The script argument, if relative, is therefore treated as
relative to the package directory.
Mendeley Desktop <= 1.0 clients set CurrentDir to the directory containing the main
application binary rather than the root of the install directory.
Change the parsing in UpdaterOptions and adjust the test accordingly.
The updater binary is listed as a package on its own but is not
compressed. The program downloading the update can then download
all packages for the new version including the updater executable
'package' (in reality, just the plain file) and then invoke that updater.
This also allows for substitution of the updater binary with a different
version via the -u parameter.
* Abort if running the zip tool fails
* Abort if multiple file path rules match a given file
* Remove part of the special updater binary handling - this needs to be reworked
* Sort the file paths before feeding them to the zip tool, so that multiple runs with
with the same set of files will generate the same packages
These specify the target version for the update and the platform and are embedded
in the <targetVersion> and <platform> elements of the generated file_list.xml file
Ordinarily the script will use the updater binary from the input files directory which
matches the path of the updater binary specified in the package config file.
However it may sometimes be necessary to use a different binary, which can be done
via a -u option.
* Embed the app icon in the updater executable on Mac and
use it as the application's icon.
* Transform the application from a background to a foreground app when the
Mac dialog is shown, so that the dock icon is shown.
* Forcibly give focus to the updater application so that the progress window
gains focus when it is shown.
There is a remaining glitch with the application where the icon briefly transforms
back from the app icon to the terminal icon as the application shuts
down. This presumably happens because the custom icon set on the NSApplication
is reset before the dock icon disappears.
Mendeley Desktop is currently built for Mac OS 10.5 and newer,
so the updater needs to work on the same platforms.
With this change, it will not be possible to build the updater
on Mac OS 10.7 directly.
The utimensat/futimens system calls were introduced in relatively recent Linux
kernels and are not available on Mac. Use utimes/futimes instead - since
microsecond precision is fine for our needs.
* Move class to get the app data directory to a new StandardDirs class.
* Setup an auto-release pool at the start/end of main() to catch objects
allocated outside of the updater dialog.
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
