Add g_option_context_parse_strv() that obeys the normal memory conventions for
dealing with a strv instead of assuming that we're dealing with the 'argv'
parameter to main().
This will help for using GOptionContext with GApplication.
https://bugzilla.gnome.org/show_bug.cgi?id=721947
The names of the month (and abbreviations) are specific to the Windows
system locale, so we need to use SetThreadLocale() to set the locale of
the running program to en-US so that it will parse "March" and "Sept" etc.
correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=719344
Windows will not allow one to write to a temp file opened by g_mkstemp()
by opening another fd associated with it before one closes the fd that
is returned by g_mkstemp(), which will cause the test_save test to fail.
Fix this by using a variable to store the fd from g_mkstemp() and checking
it, and call close() on that variable before attempting to call
g_key_file_save_to_file() on the temp file as that will attempt to open
another fd (which would not work) associated with that temp file.
https://bugzilla.gnome.org/show_bug.cgi?id=719344
Fix some races introduced in be2c7b83c4a9c9d3aa76b1499c27ab19e0f4e470
while keeping the property that multiple handlers for the same unix
signal all get dispatched.
Also fix the behaviour of the source checking for pending signals when
it's created. No matter what we do here (clear the pending flag or not)
there is something that can go wrong.
If we clear the flag, we may prevent other sources from being
dispatched. If we don't clear it, we may end up dispatching the same
source twice (if we manage to dispatch it from its own thread before the
GLib worker has a chance to run).
Instead, run the full dispatch procedure when a new source is added. It
actually doesn't matter what thread this runs in since the lock is held.
https://bugzilla.gnome.org/show_bug.cgi?id=711090
The existing tests were accidentally using the same test data
twice. Fix that, and add another set of tests that exercise
the filename collation special cases.
g_time_val_from_iso8601 was attempting to parse strings
having only a date, but failed to actually set the timeval
despite returning TRUE. Since the docs state that the function
only parses strings containing a date and a time, just return
FALSE in this case.
Also remove an incomplete testcase for this behaviour that was
just checking the boolean return value, but not timeval.
This was a feature intended from the very beginning that somehow never
got written. It's a way to replace these sort of error messages out of
the GVariant parser:
1-2,10-15:unable to find a common type
with something in the style of the Vala compiler:
unable to find a common type:
[1, 2, 3, 'str']
^ ^^^^^
https://bugzilla.gnome.org/show_bug.cgi?id=715028
Most GErrors, such as GSomethingError, have a function to get
their quark that looks like g_something_error_quark(),
so bindings (such as gtkmm) would expect GVariantParseError
to have g_variant_parse_error_quark(). Instead this had
g_variant_parser_get_error_quark().
This deprecates the old function and adds the correct one,
making life easier for gtkmm (and maybe others).
https://bugzilla.gnome.org/show_bug.cgi?id=708212
Change g_test_run() to return 1 on failure (rather than the number of
failed tests), and 77 if all tests are skipped (since automake and
some other test harnesses recognize that status code).
Previously g_test_run() returned the number of failed tests, but this
behavior was not documented, and at any rate, prior to 2.39,
g_test_run() would normally not return at all if an error occurred.
https://bugzilla.gnome.org/show_bug.cgi?id=720263
