GitLab

The subsequent commit will use this elsewhere in the codebase to avoid
a CRITICAL.

!149

The <math.h> header needs to be included.

Previously I suppose libtracker-sparql.h pulled this in.

!148

Bump minimum GLib version to 2.57.2.

The UI freezes for a moment when launching Settings -> Online Accounts
because g_application_register does slow I/O. After creating the
GApplication's GDBusActionGroup, it queries the list of remote actions
from the primary application instance over D-Bus to populate it.
Fortunately, it's not necessary to fill in the GDBusActionGroup for
activating a GAction. Therefore, this can be solved by directly using
a GDBusActionGroup instead of going via a launcher GApplication.

This does lose the platform data that the launcher GApplication would
have passed when invoking the remote GAction, but hopefully that
won't prove crucial.

The loss of error handling doesn't matter. g_application_register was
the only fallible step, and it could have only failed while querying
the list of actions from the primary, something that's not needed
anyway. If anything, it simplifies the code.

Fallout from 556a9f30

A subsequent commit will switch to using G_APPROX_VALUE instead of
photos_utils_equal_double. Since G_APPROX_VALUE requires specifying the
tolerance value, it would be convenient to have it defined somewhere
that's already accessible to every source file to avoid having to
#include a separate header to compare floating point values. Every
source file already #includes config.h, so that's the natural choice.

The Flatpak bundle doesn't include the gnome-control-center binary,
and the sandbox prevents it from accessing one that's part of the host
operating system or a different bundle. Therefore, it's not possible
to use g_app_info_create_from_commandline to launch the Online
Accounts panel when running as a Flatpak.

However, with a hole poked in the sandbox, it will be able to see the
org.gtk.Actions-based [1] D-Bus API offered by gnome-control-center
[2], which can be conveniently accessed through GApplication's remote
GActionGroup implementation.

This will be used by the subsequent commit.

[1] https://wiki.gnome.org/Projects/GLib/GApplication/DBusAPI
[2] gnome-control-center commit ab0576f1f00172c4
    https://bugzilla.gnome.org/show_bug.cgi?id=696054

A subsequent commit will change the location where edits are stored for
local items. In order to provide backwords compatibility with existing
edits stored at the old location, and to transparently migrate them to
the new location, it is necessary that a PhotosBaseItem sub-class be
able to return multiple pipeline locations.

All parameters that accepted a single pipeline path or URI have been
modified to accept a NULL-terminated array of paths or URIs.

The automatic mapping from an "as" GVariant to the natural GStrv C type
has been disabled for the GenerateThumbnail()[pipeline_uris] parameter
because the gdbus-codegen:ed wrapper cannot convert a NULL GStrv to its
equivalent GVariant. It uses g_variant_new_strv with the length always
set to -1, which isn't valid when the GStrv is NULL.

#87

This will be necessary to support fallback pipeline paths in a
subsequent commit.

#87

Based on code written by Petr Štětka.

#29

This is meant to represent items present on an attached device. It
specifies a separate location for thumbnails based on the details of
the underlying GVolume.

#29

#29

This is required to transparently query the state of the thumbnail
across different BaseItem sub-classes that might have different
thumbnail caches.

#29

A subsequent patch will directly use the BaseItem to query the
GFileInfo, instead of creating a GFile out of the URI. This is
required to transparently query the state of the thumbnail across
different BaseItem sub-classes that might have different thumbnail
caches.

This is a step in that direction.

#29

A subsequent patch will directly use the BaseItem to query the
GFileInfo, instead of creating a GFile out of the URI. This is
required to transparently query the state of the thumbnail across
different BaseItem sub-classes that might have different thumbnail
caches.

This is a step in that direction.

It's also better to not do the same thing, parsing the SparqlCursor in
this case, in subtly different ways through different code paths.

#29

So far, all thumbnails were located at:
  ~/.cache/gnome-photos/thumbnails/<size>-<generation>/<hash-of-URI>

A subsequent series of commits will add support for importing content
from attached devices, and it will be nice to separate out those
thumbnails a bit. Cameras adhering to DCF [1] can use the same URI to
refer to different images over time, regardless of whether it is the
same device or not. Manufacturers use the same URI naming scheme for
all their products, so it is likely that two different devices made by
the same manufacturer will have two distinct images at the same URI.
Given enough time, once various counters have wrapped around, it will
happen with images taken by the same camera too.

Therefore, it is desirable to not put all those thumbnails in the same
bucket, and have some degree of separation. This means that
ThumbnailFactory can't continue to determine the location for
everything, and should instead let the BaseItem sub-classes specify
where their thumbnails should be placed.

[1] https://en.wikipedia.org/wiki/Design_rule_for_Camera_File_system

#29

Having the license notice of each file match the licenses of the final
binaries reduces confusion. Otherwise one has to know how the code is
linked together, and the licenses involved, in order to explain the
dichotomy. It also makes it easy to borrow GPLv3+ and LGPLv3+ licensed
code from GEGL and GIMP.

Commit 78ea329f explains why the final binaries must be under
GNU General Public License version 3 or later.

gtk_widget_get_screen never returns NULL.

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

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

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

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

Assert the post-condition in the function itself, instead of having
each caller do so.

A subsequent commit will add support for zooming with touch gestures.
This added flexibility readies the GActions for that.

The current zooming interface provided by the zoom-in/out GActions is
based on the notion of incremental steps. Each step represents one
press/release of an accelerator key or mouse button, or one notch on
the mouse's scroll wheel. A new zoom value is calculated for each step.

However, touch gestures are different. The content needs to stick to
the touch points while the gesture is active. This means that the ratio
of the new and initial zoom values should be equal to the ratio of the
distance between the touch points and their initial distance. This is
unlike the notion of discrete steps where the content would jump to
the next zoom level.

Commit 9590011f had hacked in the ability to encode the origin
of the zoom event by using positive and negative arguments. This has
been made more explicit by having a separate enumerated value for it.

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

... by turning it into a GObject.

The other option was to implement a boxed type with its own reference
counting using g_atomic_*. However, there is no proof that using a
GObject will measurably affect performance and we get the reference
counting for free.

This paves the way for reduced memory fragmentation, by removing the
need to copy the sparql and tag fields of a PhotosQuery.

It is not idiomatic for strings to transfer ownership when passed as
input arguments to functions, unless the function is explitly named
as such. eg., "take" functions.

Transferring the ownership of the SPARQL string to the PhotosQuery
struct did afford us some conveniences. eg., not having to free the
string. However, in a following patch, PhotosQuery is going to be
converted into a GObject. It will be even more non-idiomatic to
retain the current behaviour, and a future port to g_auto* will take
care of the extra lines of code needed to free the string.

That leaves the possibility of memory fragmentation caused by the
extra copy. However, one can't say if that's a real issue without
actual measurements. We don't really create that many PhotosQuery
instances. In any case, this will be assuaged in the following patch
where PhotosQuery instances will be made reference counted. That will
remove the need to copy the sparql and tag fields, and reduce
fragmentation.

This will enable more human-readable logging of the Tracker queries by
annotating the SPARQL strings with a description of who initiated them
and under what circumstances.

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

As a nice side-effect, search is always global now. Earlier, searching
inside a collection that was itself obtained through a search, would
only fetch results from that collection itself. That's not the right
behaviour because search is always meant to be global.

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

These will be used to scroll a zoomed image in PhotosImageView.

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

This lets us use the GAction accelerators instead of a custom event
listener and keeps the code in sync with gnome-documents.

Original patch from Cosimo Cecchi for gnome-documents.

Now that we are shipping nightly Flatpaks, it is important to know
the latest commit ID that is part of the build. Otherwise, it will be
hard to separate one nightly Flatpak from another.

It doesn't look nice with the letterboxed thumbnail grid.

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

A grid of letterboxed thumbnails only looks good if all, or almost all,
the thumbnails are big enough to touch at least one pair of the grid's
edges. Sadly, sometimes, a thumbnail can be slightly smaller than the
requested size. eg., server-generated thumbnails for remote items.

Therefore, let's scale up those thumbnails that are within 75% of the
requested size. It won't cause any discernible loss of quality and will
make the grid look nicer.

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

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