Much like GBindingGroup, the GSignalGroup object allows you to connect many
signal connections for an object and connect/disconnect/block/unblock them
as a group.
This is useful when using many connections on an object to ensure that they
are properly removed when changing state or disposing a third-party
object.
This has been used for years in various GNOME projects and makes sense to
have upstream instead of multiple copies.
Originally, GBindingGroup started with Builder as a way to simplify all
of the third-degree object bindings necessary around Model-Controller
objects such as TextBuffer/TextView.
Over time, it has grown to be useful in a number of scenarios outside
of Builder and has been copied into a number of projects such as GNOME
Text Editor, GtkSourceView, libdazzle, and more.
It makes sense at this point to unify on a single implementation and
include that upstream in GObject directly alongside GBinding.
This works in the same way as g_variant_take_ref(), and for the same
reason.
Updated and Rebased by Nitin Wartkar <nitinwartkar58@gmail.com>
Closes#1112
http://isvolatileusefulwiththreads.in/c/
It’s possible that the variables here are only marked as volatile
because they’re arguments to `g_once_*()`. Those arguments will be
modified in a subsequent commit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #600
This function returns the most specific instantiatable type
that is a prerequisite for a given interface.
This type is necessary in particular when dealing with GValues
because a GValue contains an instance of a type.
This commit includes tests for the new API.
Rather than using a mixture of ‘instantiable’ and ‘instantiatable’
everywhere, standardise on the term which is already in the public API.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Add a set of new URI parsing and generating functions, including a new
parsed-URI type GUri. Move all the code from gurifuncs.c into guri.c,
reimplementing some of those functions (and
g_string_append_uri_encoded()) in terms of the new code.
Fixes:
https://gitlab.gnome.org/GNOME/glib/issues/110
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
This adds support to be able to explicitely stored interned strings into
G_TYPE_STRING GValue.
This is useful for cases where the user:
* *knows* the string to be stored in the GValue is canonical
* Wants to know whther the string stored is canonical
This allows:
* zero-cost GValue copy (the content is guaranteed to be unique and exist
throughout the process life)
* zero-cost string equality checks (if both string GValue are interned, you just
need to check the pointers for equality or not, instead of doing a strcmp).
Fixes#2109
The glib-mkenums program allows generating code to handle enums/flags
with very different purposes. One of its purposes could be generating
per-enum/flag methods to be exposed in a library API, and while doing
that, it would be nice to have a way to specify in which API version
the enum/flag was introduced, so that the same version could be shown
in the generated API methods.
E.g. From the following code:
/**
* QmiWmsMessageProtocol:
* @QMI_WMS_MESSAGE_PROTOCOL_CDMA: CDMA.
* @QMI_WMS_MESSAGE_PROTOCOL_WCDMA: WCDMA.
*
* Type of message protocol.
*
* Since: 1.0
*/
typedef enum { /*< since=1.0 >*/
QMI_WMS_MESSAGE_PROTOCOL_CDMA = 0x00,
QMI_WMS_MESSAGE_PROTOCOL_WCDMA = 0x01
} QmiWmsMessageProtocol;
The template would allow us to generate a method documented like this,
including the Since tag with the value given in the mkenums 'since' tag.
/**
* qmi_wms_message_protocol_get_string:
* @val: a QmiWmsMessageProtocol.
*
* Gets the nickname string for the #QmiWmsMessageProtocol specified at @val.
*
* Returns: (transfer none): a string with the nickname, or %NULL if not found. Do not free the returned value.
* Since: 1.0
*/
const gchar *qmi_wms_message_protocol_get_string (QmiWmsMessageProtocol val);
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Making this validation code public allows projects to validate a
GParamSpec name before creating it. While hard-coded GParamSpec don't
need this, we can't afford crashing the main program for dynamically
generated GParamSpec from user-created data.
In such case, we will need to validate the param names and return errors
instead of trying to create a GParamSpec with invalid names.
Includes modifications from Philip Withnall and Emmanuele Bassi to
rearrange the new function addition and split it into one function for
GParamSpecs and one for GSignals.
We're using Meson for GLib itself, and we recommend people to use it
for their own projects, so it would be good to have our documentation
present examples on how to use Meson with our tools.
We're using Meson for GLib itself, and we recommend people to use it
for their own projects, so it would be good to have our documentation
present examples on how to use Meson with our tools.
Let's move the template example into its own section while we're at it,
since it's referenced by both Meson and Autotools examples.
Fixes: #1783
This has the side effect of always rebuilding the doc at each build when
gtk_doc option is enabled (not by default). Most importantly, this will
enable doc check on our CI.
There is (at most) a single GType that is instantiable and a
prerequisite for an interface. This function returns that type.
This type is necessary in particular when dealing with GValues because a
GValue contains an instance of a type.
Add the private members referred to in the property setting/getting
example, and a finalize function for them, to make the tutorial code
more self-contained.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1858
The class has used `G_DECLARE_FINAL_TYPE` for a while now, so doesn’t
have a `priv` struct. Private members are declared inline.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1858
This means that if you compile with `-Wswitch-enum`, the compiler will
warn you about properties which you’ve forgotten to handle in
`set_property()` or `get_property()`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1858
It allows to disconnect a signal handler from GObject instance and at the same
time to nullify the signal handler.
Provided also a macro for handler type conversion.
Some of these have a negative master/slave connotation, and they add no
value. Change or drop them.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Those lists were getting very long. We can’t quite entirely automate the
list generation since Meson doesn’t have a range() function, but we can
at least combine three of them into one.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
So long, and thanks for everything. We’re a Meson-only shop now.
glib-2-58 will remain the last stable GLib release series which is
buildable using autotools.
We continue to install autoconf macros for autotools-using projects
which depend on GLib; they are stable API.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
They should either be generated at build time, or ignored completely,
depending on the presence of --[enable|disable]-man.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The tool was ported to Python, but we should not mention the programming
language used, in case we port it to some other language in the distant
future.
Weak-pointers are currently lacking g_set_object() & g_clear_object()
helpers equivalent. New functions (and macros, both are provided) are
convenient in many case, especially for the property's notify-on-set
pattern:
if (g_set_weak_pointer (...))
g_object_notify (...)
Inspired by Christian Hergert's original implementation for
gnome-builder.
https://bugzilla.gnome.org/show_bug.cgi?id=749527
The example code defines an interface with three methods. The preceding text
reads 'This interface defines two methods'. This appears to be because the
example code was changed without updating the surrounding text.
https://bugzilla.gnome.org/show_bug.cgi?id=790830
We should show how to properly use glib-mkenums with Autotools, in
the hope that fewer people will be caught cargo-culting rules written
in the late '90s.
https://bugzilla.gnome.org/show_bug.cgi?id=788948
We should show how to properly use glib-genmarshal with Autotools, in
the hope that fewer people will be caught cargo-culting rules written
in the late '90s.
https://bugzilla.gnome.org/show_bug.cgi?id=788948
By default, only build man pages and gtk-doc if the build-deps were
found. To force-enable, pass -Dwith-docs=yes and -Dwith-man=yes.
Also use a foreach loop for man pages instead of listing them all
manually
We're in the process or rewriting other tools in Python to reduce the
number of dependencies of GLib.
Additionally, making glib-genmarshal a Python script reduces the
complexity when cross-compiling, as we don't need a native build to
generate the marshallers.
https://bugzilla.gnome.org/show_bug.cgi?id=784528
It's unnecessary, and only adds visual noise; we have been fairly
inconsistent in the past, but the semi-colon-less version clearly
dominates in the code base.
https://bugzilla.gnome.org/show_bug.cgi?id=669355
Currently the doc is incomplete when builddir!=srcdir
(e.g. debian package) because glibconfig.h is generared from
configure.ac and is thus missing from srcdir. This leads to
missing doc for symbols like G_GINT64_FORMAT.
https://bugzilla.gnome.org/show_bug.cgi?id=734469
Change it to a running example of a file viewer application with a file
class and various derived classes and related interfaces. Hopefully the
reader can relate to this a little better than to their maman.
https://bugzilla.gnome.org/show_bug.cgi?id=753935
Remove some outdated references to an old example, and add a row in the
table of steps in object initialization for the GObjectClass.constructed
virtual method.
https://bugzilla.gnome.org/show_bug.cgi?id=754855
• Remove copies of function declarations from the explanation — if
people want those, they can follow links to the reference manual.
• Add markup to make C code more defined.
• Remove use of first person and irrelevant name dropping.
https://bugzilla.gnome.org/show_bug.cgi?id=744060
So that first-time users don’t fall into the trap of reading about the
gory memory layout details of GType and GObject when all they wanted to
do was derive a class.
https://bugzilla.gnome.org/show_bug.cgi?id=744060
