* GCancellable can be "cancelled" more than once if
g_cancellable_reset() is called.
* Don't assume that because the "cancelled" signal fired
it won't fire again.
https://bugzilla.gnome.org/show_bug.cgi?id=680111
g_async_initable_real_init_finish() was previously handling all
GSimpleAsyncResults, even if they weren't created by
g_async_initable_real_init_async(), and libnm-glib accidentally relied
on that behavior. So remove the g_simple_async_result_is_valid()
check.
Many (if not "almost all") programs that spawn other programs via
g_spawn_sync() or the like simply want to check whether or not the
child exited successfully, but doing so requires use of
platform-specific functionality and there's actually a fair amount of
boilerplate involved.
This new API will help drain a *lot* of mostly duplicated code in
GNOME, from gnome-session to gdm. And we can see that some bits even
inside GLib were doing it wrong; for example checking the exit status
on Unix, but ignoring it on Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=679691
Rather than doing a two step first-check-the-GAsyncResult-subtype-then-
check-the-tag, add a GAsyncResult-level method so that you can do them
both at once, simplifying the code for "short-circuit" async return
values where the vmethod never gets called.
https://bugzilla.gnome.org/show_bug.cgi?id=661767
Finish deprecating the "handle GSimpleAsyncResult errors in the
wrapper function" idiom (and protect against future GSimpleAsyncResult
deprecation warnings) by adding a "legacy" GAsyncResult method
to do it in those classes/methods where it had been traditionally
done.
(This applies only to wrapper methods; in cases where an _async
vmethod explicitly uses GSimpleAsyncResult, its corresponding _finish
vmethod still uses g_simple_async_result_propagate_error.)
https://bugzilla.gnome.org/show_bug.cgi?id=667375https://bugzilla.gnome.org/show_bug.cgi?id=661767
Originally, the standard idiom with GSimpleAsyncResult was to handle
all errors in the _finish wrapper function, so that vmethods only had
to deal with successful results. But this means that chaining up to a
parent _finish vmethod won't work correctly. Fix this by also checking
for errors in all the relevant vmethods. (We have to redundantly check
in both the vmethod and the wrapper to preserve compatibility.)
https://bugzilla.gnome.org/show_bug.cgi?id=667375https://bugzilla.gnome.org/show_bug.cgi?id=661767
The "mainloop_barrier" in copy_async_thread() is unnecessary, since
the g_simple_async_result_complete_in_idle() will be queued after all
of the g_io_scheduler_job_send_to_mainloop_async()s, and sources with
the same priority will run in the order in which they were queued.
https://bugzilla.gnome.org/show_bug.cgi?id=661767
The in commit b79fbc5c3f for fixing
-Wstrict-aliasing warnings was a little too brutal, make it a bit
better.
Signed-off-by: David Zeuthen <zeuthen@gmail.com>
Prevent attempts to access keys ending with slashes that exist in the
schema file as references to child schemas.
Also: don't emit change signals for these same keys.
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>
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
g_content_type_guess() requires specifying a valid data length. Fixes a
segfault when running the test.
Also add an explicit check for this and return XDG_MIME_TYPE_UNKNOWN when
data_size is specified as -1, to avoid crashing.
https://bugzilla.gnome.org/show_bug.cgi?id=674452
Sometimes the poll duration in the /socket/timed_wait test is slightly lower
than the requested 100000, causing failures like
ERROR:/build/buildd/glib2.0-2.33.2/./gio/tests/socket.c:619:test_timed_wait:
assertion failed (poll_duration > = 100000): (99240 >= 100000)
FAIL
Adjust the test to also allow some jitter in the "too small" direction, similar
to the already existing span for "slightly too large".
https://bugzilla.gnome.org/show_bug.cgi?id=678881
In general, code using g_slist_delete_link() is broken, because it
potentially requires an O(n) traversal. Just switch to GList in this
case.
The performance hit here was exacerbated by the fact that we were
holding a mutex that needed to be accessed by all threads.
https://bugzilla.gnome.org/show_bug.cgi?id=678576
make sure the proxy threads are in the "waiting for a connection"
state when we do the final cleanup, or else there are race conditions
involving which thread processes the GCancellable cancellation first.
The bash-completion code nowadays expects completion files to
be installed in /usr/share/bash-completion/completions, and
expects them to be named like the command they are completing
for.
https://bugzilla.gnome.org/show_bug.cgi?id=677782
