Add G_DECLARE_DERIVABLE_TYPE() and G_DECLARE_FINAL_TYPE() to allow
skipping almost all of the typical GObject boilerplate code.
These macros make some assumptions about GObject best practice that mean
that they may not be usable with older classes that have to preserve
API/ABI compatibility with a time before these practices existed.
https://bugzilla.gnome.org/show_bug.cgi?id=389585
Along the same lines as g_clear_object(), g_set_object() is a
convenience function to update a GObject pointer, handling reference
counting transparently and correctly.
Specifically, it handles the case where a pointer is set to its current
value. If handled naïvely, that could result in the object instance
being finalised. In the following code, that happens when
(my_obj == new_value) and the object has a single reference:
g_clear_object (&my_obj);
my_obj = g_object_ref (new_value);
It also simplifies boilerplate code such as set_property()
implementations, which are otherwise long and boring.
Test cases included.
https://bugzilla.gnome.org/show_bug.cgi?id=741589
Used for the commonly used case (in signal emission) where we
initialize and set a GValue for an instance
Includes a fast-path for GObject
Overall makes it 6 times faster than the previous combination
of g_value_init + g_value_set_instance
Makes signal emission around 10% faster
https://bugzilla.gnome.org/show_bug.cgi?id=731950
On initialisation, GObject guarantees to zero-fill
class/object/interface structures. Document this so people don’t spend
forever writing:
my_object->priv->some_member = NULL;
my_object->priv->some_other_member = NULL;
https://bugzilla.gnome.org/show_bug.cgi?id=729167
Since all element markup is now gone from the doc comments,
we can turn off the gtk-doc sgml mode, which means that from
now on, docbook markup is no longer allowed in doc comments.
To make this possible, we have to replace all remaining
entities in doc comments by their replacement text, & -> &
and so on.
This is really just a very crude and limited conditional breakpoint.
Update the documentation to explain conditional breakpoints in
gdb instead. Also, remove the link to refdbg, which appears dead.
https://bugzilla.gnome.org/show_bug.cgi?id=719687
As it turns out, we have examples of internal functions called
type_name_get_private() in the wild (especially among older libraries),
so we need to use a name for the per-instance private data getter
function that hopefully won't conflict with anything.
Started off by using the new instance private data macro, ended up
cleaning up the obscure, out of date, or simply broken concepts and
paragraphs.
https://bugzilla.gnome.org/show_bug.cgi?id=700035
Mark 'test', 'test-report', 'perf-report' and 'full-report' as PHONY in
docs/Makefile.am to prevent recursion of gtester into the documentation
subdirectories. Stop including Makefile.decl from these directories
since it is no longer necessary.
This will clear up the warnings about EXTRA_DIST being defined once in
gtk-doc.make and again in Makefile.decl.
Higher order languages with garbage collection can have issues releasing
a binding, as they do not control the last reference being dropped on
the binding, source, or target instances.
https://bugzilla.gnome.org/show_bug.cgi?id=698018
The way of getting the default value out of a GParamSpec is to allocate
a GValue, initialise it, then call g_param_spec_set_default() to set the
default value into that GValue.
This is exactly how we handle setting the default value for all of the
construct properties that were not explicitly passed to g_object_new().
Instead of doing the alloc/init/store on all construct properties on
every call to g_object_new(), we can cache those GValues in the private
data of the GParamSpec itself and reuse them.
This patch does not actually make that change to g_object_new() yet, but
it adds the API to GParamSpec so that a future patch to GObject can make
the change.
https://bugzilla.gnome.org/show_bug.cgi?id=698056
Since instance private data is now always at a constant offset to the
instance pointer, we can add an accessor for it that doesn't also
require an instance.
The idea is that classes can call this from their class_init and store
it in a file-scoped static variable and use that to find their private
data on instances very quickly, without a priv pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=698056
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
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
I don't see a good reason for this - if man page generation is
disabled, man pages are not produced, and things like 'make dist'
will fail. That is simpler and better.
https://bugzilla.gnome.org/show_bug.cgi?id=681336
Use $(AM_V_GEN) for generating man pages, and set some parameters
for the XSL stylesheets. Among other things, don't generate AUTHORS
and COPYRIGHT sections.
* Document how to override interfaces already implemented
in a base class, and also call those base class implementations
from a derived reimplementation.
* Don't recomend people use base_init() style functions to
initialize interface signals and properties, use default_init()
aka class_init() instead (as G_DEFINE_INTERFACE() uses).
* The above solves the interface init called multiple times
problem, so remove some needless naysaying about that.
* Document default_init() in the interface initialization discussion
* Linkify more stuff.
* Remove some crud and typos
https://bugzilla.gnome.org/show_bug.cgi?id=675504
Either g_type_register_static_simple (used by G_DEFINE_TYPE_EXTENDED)
and G_IMPLEMENT_INTERFACE use automatic variables for GTypeInfo and
GInterfaceInfo structs, while tutorials and source code often use
static variables. This commit consistently adopts the former method.
https://bugzilla.gnome.org/show_bug.cgi?id=600161
* Represents an immutable reference counted block of memory.
* This is basically the internal glib GBuffer structure exposed,
renamed, and with some additional capabilities.
* The GBytes name comes from python3's immutable 'bytes' type
* GBytes can be safely used as keys in hash tables, and have
functions for doing so: g_bytes_hash, g_bytes_equal
* GByteArray is a mutable form of GBytes, and vice versa. There
are functions for converting from one to the other efficiently:
g_bytes_unref_to_array() and g_byte_array_free_to_bytes()
* Adds g_byte_array_new_take() to support above functions
https://bugzilla.gnome.org/show_bug.cgi?id=663291
Allow passing --identifier-prefix and --symbol-prefix to glib-mkenums,
with the same meanings as in g-ir-scanner, to allow fixing up the enum
name parsing globally rather than needing to add a /<* *>/ override to
each enum.
https://bugzilla.gnome.org/show_bug.cgi?id=661797
Some links were broken due to typos, because functionality was removed
in GLib 2.0 or for various other reasons. Fix up as many of them as is
reasonable.
Commit ab0e9dbfa7 introduced some changes
to the documentation Makefiles designed to clean-up the process of
deciding which headers get scanned for the docs.
Unfortunately, the gtk-doc Makefile doesn't use HFILE_GLOB for actually
generating the docs -- only for knowing when it needs to redo the
generation. Because of this, we need to use IGNORE_HFILES or otherwise
we get hundreds of symbols in the *-unused.txt files.
Revert the changes that that commit made to the docs Makefiles (but
leave the generation of the *-public-headers.txt files in place).
The implementation of GValue is not public or documented. When
allocated on the stack, initializing a GValue is usually done as
documented with:
GValue value = { 0, };
There is lot code around (including WebKit) that added all the missing
fields, resulting in this ugly and non-obvious:
GValue value = { 0, { { 0 } } };
However, this doesn't play nice with -Wmissing-field-initializers for
example. Thus, G_VALUE_INIT.
http://bugzilla.gnome.org/show_bug.cgi?id=654793http://bugzilla.gnome.org/show_bug.cgi?id=577231
Rather than having the gtk-doc build machinery have a list of header
files to exclude, change the GLib build to dump a list of public
header files generated from the maintained Makefile.am files for
each of glib/, gobject/, gio/.
Also, for glib, always install glib-unix.h, even on non-Unix
platforms, for the same reason we install gwin32.h even on Unix.
https://bugzilla.gnome.org/show_bug.cgi?id=651745
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>
Since using the function pointer version muddles the memory management
requirements of language bindings, we should implement a GClosure-based
variant on top of g_object_bind_property_full().
https://bugzilla.gnome.org/show_bug.cgi?id=622278
GBinding is a simple, opaque object that represents a binding between a
property on a GObject instance (source) and property on another GObject
instance (target).
https://bugzilla.gnome.org/show_bug.cgi?id=348080
g_object_notify_by_pspec() will emit the "notify" signal on the given
pspec, short-circuiting the hash table lookup needed by
g_object_notify(). The suggested and documented way of using
g_object_notify_by_pspec() is similar to the way of emitting signals
with their ID.
Emission tests (with no handler attached to the notify signal) show a
10-15% speedup over using g_object_notify().
https://bugzilla.gnome.org/show_bug.cgi?id=615425
