In some cases, signal arguments have to be collected, even if there are i
no signal handlers connected (e.g. for GVariant parameters, where collection
consumes a floating variant).
Based on a patch by Christian Persch.
Bug #643624.
These are the updates to the autotools files to
ensure the expansion of the GIO, GLib and GObject
project files (*.vcxproj, *.vcxproj.filters) and to
enable the distribution of the VS2010 project files
The actual VS2010 project files will follow shortly
I couldn't tell from reading the documentation whether I had to pass in
an uninitialized value, or a value initialized to the exact type, or
something else. It turns out (from reading the source) that you have to
pass in an initialized value, but you can use any type to which the
property's actual type can be transformed.
So, let's document this.
The code section guarded with toggle_refs_mutex includes a call to
g_object_unref(), which may call toggle_refs_notify(). As the latter
tries to acquire the same mutex, glib locks up.
https://bugzilla.gnome.org/show_bug.cgi?id=632884
Previously, dumping a GValue holding a GStrv just yielded "((GStrv *)
0xDEADBEEF)". I think it'd be more useful to dump a Python list-style
representation of the GStrv's contents, if it's not NULL.
Fixes: <https://bugzilla.gnome.org/show_bug.cgi?id=629192>
Since we added g_object_notify_by_pspec(), an efficient way to install
and notify properties relies on storing the GParamSpec pointers inside
a static arrays, like we do for signal identifiers.
Instead of multiple calls to g_object_class_install_property(), we
should have a single function to take the static array of GParamSpecs
and iterate it.
https://bugzilla.gnome.org/show_bug.cgi?id=626919
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
This should fix bug #628952.
Don't include glib/gdatasetprivate.h directly. Especially don't define
GLIB_COMPILATION when doing that, as that causes breakage on Windows
because of the variable dllimport/dllexport stuff in gtypes.h that
checks GLIB_COMPILATION. That macro really should be defined only when
compiling code that goes into the libglib DLL. Otherwise the compiler
thinks that variables that should be imported from libglib are
actually defined in the code being compiled.
Just call g_atomic_pointer_get() as such, don't bother with
G_DATALIST_GET_FLAGS.
Signed-off-by: Tor Lillqvist <tml@iki.fi>
