To simplify the logic, I created an `is_update` variable. This makes the code
much more understandable (and also simplify the redundant or over-complicated
imbricated `if` blocks).
The fix part is that the update check would have never happened for anyone
leaving the "Show Welcome Dialog" option checked, whereas we only want to bypass
the update check for new installations or updates.
Allows users to quickly configure themes and other
"controversial" options when first installed.
Also allows the welcome dialogue to appear on start,
depending on user preference.
On Windows, the title bar can be set to light or dark mode via DwmSetWindowAttribute ().
This adds code to update the main title bar and dialogue title bars based on the current theme.
The main title bar uses "prefer-dark-theme", while the dialogue title bars
uses the color of the widget background to assume the correct color.
We were using GIMP_UNSTABLE extensively to differentiate development
from stable code. But there is actually another level of development
code. Basically GIMP_UNSTABLE tells you are on the development branch,
e.g. for current branches, that you are on 2.99.* versions (vs. 2.10).
This depends on the minor version oddness.
GIMP_RELEASE will tell you if it's a release or a in-between-releases
code. This works with the micro version which must be even on release.
Any odd number means you are basically using random git code.
There can be any combination of GIMP_RELEASE and GIMP_UNSTABLE. For
instance 2.99.12 is a release of the unstable branch, whereas 2.10.33 is
development code of the stable branch.
I use this first in the update code as we were using GIMP_UNSTABLE for
both concepts but it made it harder to test. Now:
* GIMP_DEV_VERSIONS_JSON environment variable is only available on
development code, not on release (whether stable or unstable).
* The weekly check limitation is also only for releases (dev code just
check at every startup to quickly detect issues and regressions).
* Whether to look on testing website or public website json file depends
on the code being a release or not.
* Finally only whether to check "DEVELOPMENT" or "STABLE" sections in
the json file depends on whether we are on stable or unstable
branches.
This was not working due to a missing port in glib.
Potentially could be contributed upstream to GLib.
(cherry picked from commit b391f9f5c8)
Conflicts fixed:
app/gimp-update.c
The "revision" field in the json file is supposed to be int. But I just
realized that it was set as string a few times, e.g. in Windows
installer revision 1 of GIMP 2.10.32. As a consequence, the revision 0
build was not able to detect the new revision.
I have now fixed the data in gimp-web repo (commit e7690e36), yet just
in case this ever happens again, I make the parsing code more robust by
accepting string revision, then properly converted to int.
… in the gimp-release file.
This will be useful to disable the update check for the Windows Store
even though we use the same build as the installer. All it will take
will be to append the line `check-update=false` to the file
`share/gimp/2.10/gimp-release` and it will behave as though the update
check is disabled (even though it is actually built-in).
Thinking again, this is simply the version of the config files, mapping
to the application version. Even though it's not really a user-visible
string (except in config files themselves), I find this a much more
elegant name than the ugly "last-run-version" (which is not even true
anymore once startup passed; it's only the last-run version info at very
beginning of the startup process).
This will be used by the update check to verify you are running a new
version since last time. In the future, it might even allow to handle
some types of config migrations if ever we update some things in-between
micro releases. Until now, we could only detect minor updates through
the config folder name (and even this was limited as the config folder
can be specified, in which case we would not even know what version the
files were for).
Maybe we could start also warning in cases of downgrading too, which can
break some configuration files (though there is not much we can do about
it other than warn as there is no time machine!).
Last point: if the new config value "last-run-version" doesn't exist, it
simply means the config folder was run for a GIMP before this point in
time/commit. So we just show the welcome dialog.
Stable versions (i.e. minor version number even, e.g. 2.10.22) will only
look for higher stable releases. But for unstable versions, we will want
to look up the development releases too. So for instance GIMP 2.99.2
will warn if the development version 2.99.4 has been released, but also
if the stable version 3.0.0 has been released (whatever is the highest,
which is the stable version in this example).
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.
… 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.
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.
(cherry picked from commit dd4cec577d)
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.
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).
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.
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.
- 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).
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.
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).
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.
This fixes the following warning when compiling with Mingw:
> warning: integer overflow in expression of type 'long int' results in '-694967296' [-Woverflow]
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).
Jehan