The housekeeping plugin's D-Bus name changed in GNOME 3.24, not 3.26,
which was shipped in Fedora 26. Confusing!

Fallout from 4a7e2c77

The /org/gnome/SettingsDaemon/Housekeeping D-Bus object got moved to
the org.gnome.SettingsDaemon.Housekeeping bus name when the
gnome-settings-daemon plugins were split into their own processes in
GNOME 3.26.

Support for older GNOME versions have been retained to allow new
Flatpaks to run on older host OSes.

Single precision floating point is all that's needed. It is wasteful to
promote calculations to double precision through the use of such
literals. This can have significant performance impact on architectures
like ARM.

The brightness and contrast of the green and blue channels were not
being adjusted for 8 bits per channel inputs.

Single precision floating point is all that's needed. It is wasteful to
promote calculations to double precision through the use of such
literals. This can have significant performance impact on architectures
like ARM.

It broke the string freeze. Since this isn't part of the actual
bug-fix, it's better to just back it out.

This reverts commit 9aee8a47.

There is no guarantee that the GtkRevealer will asynchronously animate
before emitting notify::child-revealed. There is no known breakage,
since there is no LoadMoreButton anymore. This is a pre-emptive fix.

Fallout from 470c05cd

https://bugzilla.gnome.org/show_bug.cgi?id=785376

There is no guarantee that the GtkRevealer will asynchronously animate
before emitting notify::child-revealed. When it doesn't, the SpinnerBox
remains visible, and obstructs the hyperlink in EmptyResultsBox from
receiving the mouse event, or interferes with ToolCrop's GdkCursor.

Fallout from 73e32473

https://bugzilla.gnome.org/show_bug.cgi?id=785376

This will make it easier to develop and test the "empty state" logic.

https://bugzilla.gnome.org/show_bug.cgi?id=785376

Just because photos_utils_file_query_info has succeeded it doesn't mean
that a thumbnail is present. If it's absent, the path is NULL and it
led to:
  GLib-GIO-CRITICAL **: g_file_new_for_path: assertion 'path != NULL'
    failed

The OpenCL code paths are not that well tested across multiple GPU
drivers, and can generate faulty output. Moreover, until there's
OpenCL coverage for all the operations that are used it's not going to
have the expected performance boost due to memory transfers between
the CPU and GPU. In fact, today, for many cases using the GPU is
measurably, sometimes significantly so, slower than the CPU.

Increasing the number of threads beyond the number of physical CPU
cores doesn't yield any measurable performance improvements. In fact,
in some cases, a small drop was noted. Presumably because of memory
bandwidth limits.

It seems logical to keep the GEGL initialization and sanity check in
the same file.

The following patches are going to set GEGL's threads property during
initialization. This will make it easier to ensure that the same
configuration is used by the application and the thumbnailer.

Commit 8047f788 decoupled the loading of the Pipeline from the
rest of the BaseItem. The presence of a pipeline doesn't imply the
existence of a buffer source, edit graph, etc..

Therefore, discarding all edits from the overview, without loading the
BaseItem, would lead to:
  CRITICAL **: photos_base_item_pipeline_save_async: assertion
    'priv->edit_graph != NULL' failed

This prevented the thumbnail from getting updated and the revert
wouldn't be persistent.

Since saving a Pipeline doesn't even require a fully loaded BaseItem,
it is enough to just remove this anachronistic and overzealous
assertion.

Fallout from 8047f788

https://bugzilla.gnome.org/show_bug.cgi?id=788715

Commit 8047f788 decoupled the loading of the Pipeline from the
rest of the BaseItem. The presence of a pipeline doesn't imply the
existence of a buffer source, edit graph, etc..

Therefore, discarding all edits from the overview, without loading the
BaseItem, would lead to processing a GEGL graph without any input and:
  GEGL-WARNING **: Output of gegl:nop 'proxynop-output' 0x7f741c026900
    has no format

Processing a BaseItem after changing its Pipeline is only necessary if
the rest of the BaseItem is loaded. Hence it is better to just skip it
in this case.

Note that the thumbnail is updated when the Pipeline is saved, which
also doesn't require loading the BaseItem. The thumbnailer takes care
of that.

Fallout from 8047f788

https://bugzilla.gnome.org/show_bug.cgi?id=788715

https://bugzilla.gnome.org/show_bug.cgi?id=788715

Since the final background image can now be different from the
original, it is copied to ~/.config/gnome-photos/backgrounds. The first
part of the filename is a timestamp. It will prevent multiple
renditions of the same original item from colliding with each other,
and will make it easier for us to cull old backgrounds files in future.

https://bugzilla.gnome.org/show_bug.cgi?id=788042

https://bugzilla.gnome.org/show_bug.cgi?id=788042

A following patch will add a method to save a BaseItem to a specific
file, as opposed to a generated filename inside a specified directory.
Renaming this method makes its purpose more explicit and prevents any
future ambiguity.

https://bugzilla.gnome.org/show_bug.cgi?id=788042

Don't mix private and public methods.

/share/tracker/miners/org.freedesktop.Tracker1.Miner.Files.service is a
symlink that points to the filesystem miner's D-Bus service file.
A working symlink is necessary for tracker_miner_manager_get_status
to work. Otherwise, it leads to this on startup:
  Tracker-WARNING **: Error parsing miner .desktop file: No such file
    or directory

Therefore, only delete tracker-store's D-Bus service file, but not
that of the filesystem miner.

Fallout from 1d64c6bd

Original patch from Gwyn Ciesla for Fedora.

This patch was mistakenly removed because our version of the patch
has a commit message that claimed:
  "Add pkg-config file to LibRaw"

In reality, it merely fixes some of the flags in the existing pkgconfig
file shipped by LibRaw.

This reverts part of 21a07e09

Thanks to commit 38301fee it is no longer needed since
gnome-photos-3.24.3.