These were some changes to the keyfile settings backend that were being
made as the new GSettingsBackendChangeset API was being worked on.
Since there is now back-compat for old backends, these changes are not
needed. Additionally, nacho is currently working in this area.
Refactor GSettingsBackend to prefer GSettingsBackendChangeset over
GTree. Add a new write API based on changesets.
Change our own internal users of this API (really:
GDelayedSettingsBackend) to use changesets instead of trees.
While we're at it, introduce a 'read_value' API that takes a
read_through parameter that is a GQueue of changesets. This is how
dconf works internally and the other backends will be adapted to that
soon. Also add a 'read_simple' API that will useful for trivial
backends like memory and keyfile as an alternative to implementing the
full-blown 'read_value' API.
We still leave in place support for backends that implement the old
API. If the new vfuncs have not been implemented then we will shim over
to the old functions (possibly converting to a tree in the process).
We don't want enums in this header (which is not part of the public API
of GLib) to end up with GObject types.
Move the header file out of the list of public glib headers so that
these enums are not generated.
This is an import of the DConfChangeset API. It will eventually be used
as the primary way of communicating changesets between GSettings and
various GSettingsBackend implementations.
It will also be useful in simplifying the implementation of several
GSettingsBackend implementations contained within GLib as well as some
new ones being authored outside of it.
GSettingsBackend has always more or less represented a 'dconf-like'
database structure, which is why DConfChangeset is a generally useful
thing to have as part of the GSettingsBackend API.
Add helpers for checking if a string is a valid GSettingsBackend
[path|key|dir].
These helpers match equivalent functions found in dconf and will be used
for assertion checking when adding GSettingsBackendChangeset.
GSettingsBackend is not part of the public API of GLib, so its
g_autoptr() declarations should not be included in the public headers.
Move them into gsettingsbackend.h.
GApplication has accepted any valid bus name as an application ID since
before the time of D-Bus activation. This includes bus names with '-'.
Several applications have even attempted support bus activation with
these names, going as far as installing D-Bus service files, without
realising that they are silently falling back to fork()/exec() on
account of the name containing a dash.
The reason for the problem is that D-Bus object paths cannot contain
dashes. We solved this problem privately in an unspecified way inside
of GApplication but substituting '_' in this case, but never made this
part of the Desktop Entry Specification.
The fact that these apps with '-' in the desktop file names aren't
actually using D-Bus activation is beside the point: their intent here
was clear. Let's avoid forcing them to rename their desktop files again
by simply accepting '-' in desktop file names and munging the path in
the way that GApplication did so historically.
The new path escaping code here has been copied more or less verbatim
from GApplication's own code for the same purpose, with only the removal
of one irrelevant part.
An update to the desktop entry specification will follow.
https://bugzilla.gnome.org/show_bug.cgi?id=764754
Some packages might have some parts that are built for certain build
configs, meaning that they could have .pc files of their own, such as
Pango, where PangoFT2 is optionally built. Allow such an option if
needed.
Also remove some trailing whitespaces.
Inserts a paragraph in the start of the description
explaining briefly the concept of GVariant as a
variant datatypes using examples and explaining
a few use cases where GVariant can be useful.
https://bugzilla.gnome.org/show_bug.cgi?id=748806
The current statfs() compilation tests all fail because statfs() expects
the first argument to be non-null. Pass a dummy path instead of NULL to
satisfy the compiler.
https://bugzilla.gnome.org/show_bug.cgi?id=764574
This was confusing some static analysis. Through canonicalize_filename()
at construction time, we guaranteed that ->filename is canonical and
absolute, so g_path_skip_root() should never fail.
https://bugzilla.gnome.org/show_bug.cgi?id=731988
This ensures that the generated file is always the same (not dependent
on the build machine's environment), making the build reproducible.
Thanks to Jérémy Bobbio <lunar@debian.org> for the Debian bug report and
patch.
https://bugzilla.gnome.org/show_bug.cgi?id=763617
find_file_in_data_dirs() doesn’t actually clear output_path to NULL on
failure, so this prevents a use-after-free on that (fd == -1) error
path.
Spotted by Coverity (CID: #1352981).
Laszlo Ersek said: "The length check is off by one (in the safe direction); it
should be (nchars >= 2). The processing should be active for the wide string
L"\r\n" -- resulting in the empty wide string --, I believe."
Reported-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=762202
