Commit 282366c326 unnecessarily (skip)ed all the GParamSpec constructors like
g_param_spec_bool(). Make those introspectable by dropping the (skip) and
adding proper transfer annotations.
Keep g_param_spec_value_array() skipped as GValueArray is deprecated.
With visibility now under the control of __declspec(dllexport) we no
longer need to build .def files or use them for building our various
.dll files.
.def files used to be installed (even though it is only really useful
when creating the .dll or .lib file). Don't do that anymore either.
The Makefiles still contain rules to create a .lib file for use with
Visual Studio and these rules require .def files. There are special
requirements to using these rules (like having installed and setup
Microsoft tools for use during the build) and therefore the problem of
creating a .def file for use with them is left open to anyone willing to
make the effort. Many options are available depending on which
toolchain is in use (dlltool, pexport, gendef, dumpbin.exe, just to name
a few).
If we can find a free tool for creating .lib files in the future, we
should probably revisit this issue and add proper support back to our
build system.
This macro simply evaluates the "extern" unless it has been explicitly
defined to something else.
All of the version macros (including the unversioned deprecation markers
and GLIB_AVAILABLE_IN_ALL) now include _GLIB_EXTERN as part of their
definition.
G_INLINE has also been modified to use _GLIB_EXTERN where appropriate.
This macro should never be used outside of the gmacros.h/gversonmacros.h
headers.
The effect of this patch is that "extern" has now been added to all
functions declared in installed headers. Strictly speaking, this is
something we should have had all along...
GLIB_VAR and GOBJECT_VAR have also been modified to use _GLIB_EXTERN on
non-Windows, instead of "extern" which they were using before. The
eventual goal is to use the normal version/deprecation macros on
exported variables and drop GLIB_VAR but we need to see how this will
work on Windows before we go ahead with that.
https://bugzilla.gnome.org/show_bug.cgi?id=688681
Add the GLIB_AVAILABLE_IN_ALL annotation to all old functions (that
haven't already been annotated with the GLIB_AVAILABLE_IN_* macros or a
deprecation macro).
If we discover in the future that we cannot use only one macro on
Windows, it will be an easy sed patch to fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=688681
Add a check to prevent adding an interface to a class that has already
had its class_init done.
This is an incompatible change but it is suspected that there are not
many users of this functionality. Two known exceptions are pygobject
(fixed in bug 686149) and our own testsuite (affected tests have been
temporarily disabled by this patch).
Once we confirm that nobody else is using this functionality we can
remove a rather large amount of code for dealing with this case.
https://bugzilla.gnome.org/show_bug.cgi?id=687659
GValueArray as a whole is deprecated in favor of GArray (with GValue
elements); warnings like "'g_value_array_get_nth' is deprecated: Use
'g_array_index' instead" are confusing because they suggest that the
GArray functions can be used with GValueArrays. Make them say "Use
'GArray' instead" instead.
https://bugzilla.gnome.org/show_bug.cgi?id=690970
Add a check to prevent adding an interface to a class that has already
had its class_init done.
This is an incompatible change but it is suspected that there are not
many users of this functionality. Two known exceptions are pygobject
(fixed in bug 686149) and our own testsuite (affected tests have been
temporarily disabled by this patch).
Once we confirm that nobody else is using this functionality we can
remove a rather large amount of code for dealing with this case.
https://bugzilla.gnome.org/show_bug.cgi?id=687659
When g_type_class_get_private is called without calling
g_type_add_class_private first, a g_warning is issued, but
the name of the function to call is wrong:
g_type_class_add_class_private.
https://bugzilla.gnome.org/show_bug.cgi?id=690348
In 2.34, g_compute_checksum_for_bytes() was added, but this patch
allows binding users to use the incremental update API; this is
significantly more efficient than reading entire files into memory.
https://bugzilla.gnome.org/show_bug.cgi?id=689982
This lets you cache type lookup information and then know when
the cache information is out of date. In particular, we want this
in order to be able to cache g_type_from_name() lookups in the Gtk+
theme machinery.
https://bugzilla.gnome.org/show_bug.cgi?id=689847
At least GDBus had code that had "_object" as a parameter to one of
its functions, but this clashes with the GObject macro
G_OBJECT_WARN_INVALID_PROPERTY_ID() which created a local "_object".
Since many of us cargo cult around copies of objects, let's be
defensive here and use local variable names less likely to clash with
application code.
https://bugzilla.gnome.org/show_bug.cgi?id=689377
The gobject tools (glib-genmarshal and gobject-query) were linking
against libgthread. Stop that.
Also, remove the gthread_INCLUDES internal automake substitution.
This reverts commit 028d4a03f2.
I thought that we would be able to get away with this incompatible
change but it appears to impact far too much existing code. The only
thing we can do is revert.
https://bugzilla.gnome.org/show_bug.cgi?id=688596
Add a check to prevent adding an interface to a class that has already
had its class_init done.
This is an incompatible change but it is suspected that there are not
many users of this functionality. Two known exceptions are pygobject
(fixed in bug 686149) and our own testsuite (affected tests have been
temporarily disabled by this patch).
Once we confirm that nobody else is using this functionality we can
remove a rather large amount of code for dealing with this case.
https://bugzilla.gnome.org/show_bug.cgi?id=687659
Basically due to a combination of va_args semantics around
signed/unsigned ints, this test case fails on ppc64. At the moment,
we have as yet to find any real-world consumer with such a large
enumeration value.
Unfortunately, the possible fixes for this are extremely invasive;
we would have to define a new enum API.
Given both of these facts, we believe it makes the most sense at the
current time to simply not test this. If we at a later time determine
there is such a real-world consumer, we can look at doing the
necessary fixes.
https://bugzilla.gnome.org/show_bug.cgi?id=686662
Very many testcases, some GLib tools (resource compiler, etc) and
GApplication were calling g_type_init().
Remove those uses, as they are no longer required.
https://bugzilla.gnome.org/show_bug.cgi?id=686161
Move the guts of g_type_init() into a ctor and turn g_type_init() itself
into a do-nothing function.
g_type_init_with_debug_flags() now ignores its arguments, but it has
always been possible to achieve the same effect via environment
variables.
https://bugzilla.gnome.org/show_bug.cgi?id=686161
If the closure is invalidated we drop the ref on the signal handler
node, but if the signal is currently being dispatched, the ref could be
held elsewhere.
Flag that we no longer have an outstanding invalidation handler so that
we don't try to unregister ourselves when the other ref drops.
Add a testcase that catches this situation.
Move the constructed() call to happen after all of the properties are
set (not just the construct properties).
This is an incompatible change but we are making it under the belief
that it should be safe. If this change impacts you in a negative way
please comment on the bug.
https://bugzilla.gnome.org/show_bug.cgi?id=685733
Modify gsignal to automatically disconnect a GClosure that becomes
invalid (in the g_closure_invalidate() sense).
Previously, when g_signal_connect_object() was used with a GObject as
the user_data and that object was destroyed, the handler would no longer
be called but the signal handler was itself was not disconnected (ie:
the bookkeeping data was kept around).
The main effect of this patch is that these signal handlers will now
be automatically disconnected (and fully freed).
The documentation for g_signal_connect_object() has anticipated this
change for over 10 years and has advised the following workaround when
disconnecting signal handlers connected with g_signal_connect_object():
if (g_signal_handler_is_connected (instance, id))
g_signal_handler_disconnect (instance, id);
If your code follows this practice then it will continue to work.
If your code never disconnects the signal handler then it was wasting
memory before (and this commit fixes that).
If your code unconditionally disconnects the signal handler then you
will start to see (harmless) g_critical() warnings about this and you
should fix them.
https://bugzilla.gnome.org/show_bug.cgi?id=118536
