For quite some time the recommended usage of GSettings and dconf has
been to use paths like /org/gnome/example/. Use of /apps/ has spilled
over from GConf and is continuing to make its way into a number of
applications as they port.
glib-compile-schemas will now warn about these types of paths being
used. This generates a lot of noise, but hopefully it will reduce the
number of ported applications making this mistake.
It's important to have strict rules for handling of whitespace in
translated strings in GSettings schema files so that the tools
extracting the messages will end up with the same messages as the
runtime calling gettext().
The rules are designed to be simple and unambiguous yet cover most
normal uses in a convenient way.
Those rules are as follows (with rationale):
- for <default> tags, the text content has its leading and trailing
whitespace stripped off, but internal whitespace is not modified in
any way.
This allows for slightly more flexible use of whitespace without
causing that whitespace to appear in the strings for translation.
- for <summary> and <description> tags, the content is split into
paragraphs. Paragraphs are separated by two or more sequential
newline characters. Each paragraph has its leading and trailing
whitespace removed and all other whitespace is normalised to a
single ascii space character. Finally, the paragraphs are rejoined,
inserting exactly two newlines between them.
This allows for longer explanations (particularly in the description
tag) using a natural format that, when normalised, will display
nicely in toolkits.
This patch implements the rules for <default> tags. The schema compiler
currently ignores <summary> and <description> tags.
The fact that we return 0 here makes it clear that this
is not considered an error, so it makes sense to not
write these messages to stderr.
Proposed by Antoine Jacoutot,
https://bugzilla.gnome.org/show_bug.cgi?id=650882
_GNU_SOURCE must be defined before including any other (system)
header, so defining it in glib-unix.h (and hoping no one has included
anything else before that) is wrong. And the "#define _USE_GNU"
workaround for this problem in gnetworkingprivate.h is even wronger
(and still prone to failure anyway due to single-include guards).
Fix this by defining _GNU_SOURCE in config.h when building against
glibc. In theory this is bad because new releases of glibc may include
symbols that conflict with glib symbols, which could then cause
compile failures. However, most people only see new releases of glibc
when they upgrade their distro, at which point they also generally get
new releases of gcc, which have new warnings/errors to clean up
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=649201
For child schemas, verify that the named schema actually exists and
issue a warning if not. This error in schema files will cause runtime
errors when iterating over the list of child schemas and attempting to
instantiate each one.
This will move from being merely a warning to a hard error in the
future.
Bug #646039.
Don't store the "none" value for flags into the compiled schema file.
"none" should never appear as a value -- no flags set is indicated by an
empty array.
Ensure that the strinfo is output in little-endian byte order on big
endian machines.
GSettings is now passing all of its tests on PowerPC.
Bug #630968 is closed.
Implement the second feature requested in the bug: silently ignore
override files that attempt to override schemas that are not currently
installed.
Also, support 'strictness' being optional for other errors when parsing
override files (ie: inability to open the file, unknown key name, parse
errors, out of range). We don't completely back out the file in this
case — as that is difficult with the current implementation — but just
ignore the override for the single key.
Implement the first of two features requested in the bug: when
encountering a broken .xml schema file, back out the changes in that
file and continue to parse other files.
This prevents a single broken .xml file from messing up GSettings for
everyone else.
Add a --strict option to get the old behaviour. Use this from the test
cases.
- can not extend schemas that already have paths
- can not form list of schemas that already have paths
- the path of a list schema, if given, must end with ':/'
