The About dialog refreshes the release information relatively to
currently running version before being displayed. No check of the remote
JSON file is done, it only verifies whether any stored released
version/revision is not same (or even lower) than the actually running
version. Indeed existence of a stored release means that a newer version
exists at check time only. On later run, this stored information may
have become deprecated.
(cherry picked from commit 5c89099f75)
… oscp-router0[12].gnome.org.
The file was opened asynchronously through g_file_read_async() but the
actually reading from a GFileInputStream was actually done in the
callback, in the main thread. So it may be possible that file is
accessible but connection is very slow or non-reliable and actual
reading would block the main process. I am assuming this is what may
have happened for this reporter.
Instead let's use g_file_load_contents_async() which does the file
opening, reading and closing all in the asynchronous task, hence would
not slow down anything even if the remote resource is unavailable or
connection is very slow.
(cherry picked from commit cc16ec5f9f)
Do it even on stable builds as it can help diagnose bugs on releases.
Note that the issue we had just know with casing on the build-id would
not have been seen by such stderr output anyway. Just in case for future
issues.
I didn't realize it because the meson build was returning 'windows' for
GIMP_BUILD_PLATFORM when I cross-built with Mingw-w64. But in the
autotools, it was storing "mingw32", which would not compare with our
gimp_versions.json. Therefore in GIMP 2.10.16, the version update check
would have worked, but not the revision check.
This fixes the problem.
(cherry picked from commit a5ea6d6b9b)
I realized having the revision as a build number is the wrong idea as it
implies packagers will have to rebuild GIMP for just a revision. Yet
very often revision may just be data change or dependency fix/update
without rebuild needed (i.e. no ABI change).
Instead let's keep this package information as a file 'gimp-release'
(inspired by /etc/os-release and other /etc/*-release files of
distributions).
(cherry picked from commit 87e9ebcfad)
The idea is to be able to advertize a new revision of the same version
of GIMP. For instance, this would apply when we release a
`gimp-2-10-14-setup-3.exe` Windows installer (then we are at revision
3, provided we started at revision 0).
The revision number is obviously only relevant to a given platform and
version. Also the concept of build ID allows to differentiate various
builds for a same platform, in particular to not look at revisions of
third-party builds. The build ID can be any string. Maybe we could just
use reverse DNS build id (such as "org.gimp.GIMP_official") to identify
the official GIMP build. So in the end, we only compare revisions for an
identical (version, platform, build-id) tuple.
(cherry picked from commit 7b5fff7861)
Allows to disable the automatic update check at startup. I believe some
packagers will want such options, in particular on Linux distribution
(where they control their own release schedule and won't want GIMP to
pop new version warning up because they have been slow to update their
package).
Note that it is still possible to query version checks manually in the
about dialog, but the automatic check/popup is gone with this option.
(cherry picked from commit 315665592c)
- Clear the GError when relevant.
- Check result of json_path_compile() just in case.
- Print some error on stderr when parsing of gimp_versions.json fails
(which should never happen on releases but would help during
development).
(cherry picked from commit 8528759834)
Instead of storing versions as objects, we now store them as arrays,
because json arrays are ordered, unlike objects (the website was using
non-standard Python extension to consider the version objects ordered
but this is not proper and even more, the lib we use for GIMP does not
have a similar extension.
This simplifies a bit the code as we don't need to order the versions by
comparing their string representations.
(cherry picked from commit 1f75d2e34a)
This about dialog will complain an explicit message about the new
version and a link button to go to the download page.
(cherry picked from commit 6b237b90fd)
When an update is available, a big frame is visible, proposing to go to
the download page. Now a button is also available to explicitly request
for an update check in other cases (bypassing the wait delay for a
future startup).
(cherry picked from commit 827473fd88)
First, let's make the check happen at each startup on unstable (still
once a week on stable).
Second, make it parse gimp.org's gimp_versions.json on stable, but
testing's one on unstable and also check environment variable
GIMP_DEV_VERSIONS_JSON (unstable only) to allow setting a local path
(allowing to tweak the file and test various cases).
Unrelated to testing, some improvements:
- save a timestamp in seconds (really no need to keep microseconds
precision here).
- just in case, check that the saved timestamp is not in the future.
(cherry picked from commit b874cadfad)
This fixes the following warning when compiling with Mingw:
> warning: integer overflow in expression of type 'long int' results in '-694967296' [-Woverflow]
(cherry picked from commit bb7f229b97)
GIMP will now process the remote gimp_versions json file to look if one
is using the last version of GIMP. This initial code doesn't act up yet
on this information. This will come in further commits.
Here are the characteristics:
- Since this requires internet access, a new checkbox is available in
the Preferences dialog, allowing to disable version checks. Note that
it is enabled by default as it is an important security feature, but
it has to be deactivatable.
- The remote access is done as an async operation because we don't want
it to block the startup in any way (for whatever reason). Also it
doesn't output errors if it fails to not be a bother (you don't
technically need internet access for an image program).
- We don't check at every startup. At each successful check, we save a
timestamp to prevent too frequent useless checks (I set it the timer
to a week or more for now).
(cherry picked from commit 506a0476f4)
