| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
| |
A few leftovers from the tear-out: docs and header file.
|
|
|
|
|
|
| |
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
https://bugzilla.gnome.org/show_bug.cgi?id=658864
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Our hashing of non-ASCII strings was undefined due to the fact that
'char' is signed on some platforms, unsigned on others. Always use a
signed char.
Discovered by Alexander Larsson.
https://bugzilla.gnome.org/show_bug.cgi?id=658806
|
| |
| |
| |
| |
| |
| | |
Spotted by Kean Johnston <kean.johnston@gmail.com>.
https://mail.gnome.org/archives/gtk-devel-list/2011-April/msg00010.html
|
| |
| |
| |
| |
| |
| | |
This was required to support the case where the dconf client was unable
to determine the cache directory for itself. Since we now use the XDG
runtime directory, this is redundant.
|
| |
| |
| |
| |
| |
| | |
Exit gracefully on receipt of SIGTERM, SIGHUP or SIGINT.
Require glib 2.29.90 for the API used to do this.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The dconf service can not presently be run at the system level and it
doesn't make sense to support locks on user-level databases. It also
became clear that most distributors and sysadmins would rather work
directly with text files anyway, so we supported that directly instead.
For this reason, 'set lock' support has never been properly implemented.
All the plumbing was added for it though, which means we have it
appearing on the API of the client library and documented in the help of
the commandline tool. This is misleading, since these functions do
nothing at all (and actually contain bugs anyway since their
do-nothingness was never actually tested).
For now, we rip out these functions. We can add them back later if we
decide to support this properly.
|
| |
| |
| |
| |
| |
| |
| | |
When we have a failure to deliver requests to the dconf backend, give a
g_warning().
https://bugzilla.gnome.org/show_bug.cgi?id=641768
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
G_DBUS_SIGNAL_FLAGS_NO_MATCH_RULE was introduced only in glib-2.27.3, so
this is the minimum required glib version now.
34b297bd6ab4110978709d7cf49b60d7aa1ea90d changes the minimal version to
2.27.2, but the symbol was really only introduced in 2.27.3.
Signed-off-by: Robert Schwebel <r.schwebel@pengutronix.de>
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Let dconf-editor show in the applications list. If someone installed it
then it is appropriate for them to see it.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We never consumed the value, and then we reused it, causing warnings
about uninitialised error variables. Just remove it altogether.
Caught by Matthias.
https://bugzilla.gnome.org/show_bug.cgi?id=655193
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Work around the fact that we can't send maybe types over D-Bus by
sending a blob of serialised GVariant data instead.
Abuse the fact that we're using an array to denote 'maybe' at the level
of the dconf protocol and fill that array with 2 items (which would not
otherwise be possible) to indicate this special case.
|
| |
| |
| |
| |
| | |
These should be in the same format as the system database keyfiles and
fairly similar to the GSettings keyfile backend format.
|
| |
| |
| |
| | |
Fixup from last commit.
|
| |
| |
| |
| |
| |
| |
| | |
The bash completion file is meant to be sourced and not executed
directly.
https://bugzilla.gnome.org/show_bug.cgi?id=651936
|
| |
| |
| |
| |
| |
| | |
With XDG_RUNTIME_DIR, we no longer have to be frightened about NFS.
That lets us remove the NFS checks that were causing build failures all
over the place.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Vala 0.13 (leading toward 0.14) corrects an error in the binding for
GtkTreeModel. Unfortunately, the correction is incompatible and there
is no way to have code that will work with both old and new Vala
compilers.
Rather than hard-depend on the unstable Vala release, just use two
separate declarations decided on #if VALA_0_14.
|
| |
| |
| |
| |
| |
| |
| | |
Watch for changes to DConf and update the view. This is not done in the
most elegant or efficient way, but it's simple and it works.
https://bugzilla.gnome.org/show_bug.cgi?id=649443
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
https://bugzilla.gnome.org/show_bug.cgi?id=645611
|
| | |
|
| | |
|
| |
| |
| |
| | |
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=622292
|
| |
| |
| |
| | |
Based on a patch from Fabian Deutsch <fabian.deutsch@gmx.de>
|
| | |
|
| | |
|
| |
| |
| |
| | |
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=641293
|
| |
| |
| |
| | |
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=641293
|
| |
| |
| |
| |
| |
| |
| | |
If we fail to open the database in the user's home directory then the
variable will be NULL. The refactor of the read function for lockdown
support missed this check, resulting in a rather dramatic crash on fresh
accounts.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
...of no system defaults database.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Support lockdown on the client side for GSettings.
For performance reasons only lockdown of specific keys (not entire
subpaths) is supported at the moment. This may change in the future if
we can find a way to make large numbers of related GVDB lookups
sufficiently performant.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- regenerate the file when the lock dir timestamp changes
- send the proper dbus message
- write an actual value for the lock in the GVDB
(otherwise the reader won't see it)
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Switch from code locking to data locking and hold the data lock quite a
lot more often.
We could try to be more clever about finding ways to hold locks less
often but I think it's not really worth it.
Closes #648949
|
| | |
|