If GLIB_VERSION_MIN_REQUIRED or GLIB_VERSION_MAX_ALLOWED was defined
to a future value, we were essentially treating it as
GLIB_VERSION_0_0. Fix to treat it as being in the future instead.
https://bugzilla.gnome.org/show_bug.cgi?id=674898
The docs for GString should really mention GByteArray, and what makes
it different. Drop the comparison to Java which is dated and actually
inaccurate (because StringBuffer operates on Unicode).
While we're here, add g_string_free_to_bytes(), which further
complements the spread of GBytes-based API. For example, one can
create a buffer using GString, then send it off via
g_output_stream_write_bytes().
https://bugzilla.gnome.org/show_bug.cgi?id=677064
For a D-Bus property with name "Type" (fairly common), we used to
generate a GObject property with name "type-" and C accessors
get_type_() (to avoid clashing with the GType getter), set_type_()
(for symmetri).
However, the rules for GObject property names are fairly rigid and
specifically prohibit names ending in a dash.
Therefore change things so the chosen GObject property name is "type"
but preserve the naming rules for the C getter and setter (for the
same reasons: avoiding name clashing and symmetri).
This change does break the API of generated code (but only on the
GObject property level, the C symbols are not changed) but strictly
speaking the behavior was undefined since "type-" was an invalid
GObject property name.
Also add a test case for this.
Bug 679473.
https://bugzilla.gnome.org/show_bug.cgi?id=679473
Signed-off-by: David Zeuthen <zeuthen@gmail.com>
This avoids warnings when creating idiomatic value tables, like:
static const GTypeValueTable _clutter_shader_float_value_table = {
clutter_value_init_shader_float,
clutter_value_free_shader_float,
clutter_value_copy_shader_float,
clutter_value_peek_pointer,
"ip",
clutter_value_collect_shader_float,
"pp",
clutter_value_lcopy_shader_float
};
Because the strings are literals. And, really: nobody should be using
allocated values for the collection and lcopy strings.
https://bugzilla.gnome.org/show_bug.cgi?id=671545
The Since tag for these was saying 2.28 but it was actually added in
2.31. It looks like all of the Since tags list stable version numbers
so this patch bumps that up to 2.32.
https://bugzilla.gnome.org/show_bug.cgi?id=679258
Since PCRE 8.00 it supports a variant of PCRE_NOTEMPTY that works
similarly except that it only applies to the start of the matched string
but permits empty matches further in.
g_regex_get_compile_get_compile_flags() and g_regex_get_match_flags()
were leaking PCRE flags that don't exist in the corresponding
public GRegexCompileFlags and GRegexMatchFlags; this change masks
these internal flags.
These flags override the compile option at match time. They use PCRE_BSR_ANYCRLF
and PCRE_BSR_UNICODE, resp., which make \R match only CR, LF and CRLF, or any
Unicode newline character or character sequences, resp.
When using the system PCRE, and it was compiled with incompatible options,
the code was returning from inside a g_once_init_enter/leave block without
calling g_once_init_leave().
Most changes were just replacing usage of "has_key" with "in".
Also updated the sorting function which was simplified and
changed to a "key" function instead of "cmp" (which is no longer
supported in python3. Verified everything builds with
python 2.7 and 3.
https://bugzilla.gnome.org/show_bug.cgi?id=678066
After fixing bug 674452 this test case now reliably fails, as "ABC abc" is text
and definitively not PowerPoint. It previously worked as g_content_type_guess()
was reading beyond the boundary of the data due to specifying -1 as data
length.
Update that test case to expect a PO template instead, and add two more with a
definitive PO template syntax and some binary data. We do not currently have a
MIME magic for PowerPoint, so we cannot actually detect it with certainty, but
at least make sure that the returned MIME type is correct.
https://bugzilla.gnome.org/show_bug.cgi?id=678941
We need to ignore the defaults.list item only when there
was a mimetype handler found in a previous mimetype, not
if one was found for the same mimetype as the one that
is listed in defaults.list (same for the new-style defaults).
There was an issue when looking up the default handler
for a type where a supertype was listed in defaults.list.
We would pick the default for the parent type even if
there was a handler for the more specific type.
In the case of the new-style defaults marking (
"Default Applications" in mimeapps.list) we were already
checking for a more specific handler befor using a default,
but we also need to do a similar check for the defaults.list
case.
https://bugzilla.gnome.org/show_bug.cgi?id=678944
