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
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.
It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
Add various (nullable) and (optional) annotations which were missing
from a variety of functions. Also port a couple of existing (allow-none)
annotations in the same files to use (nullable) and (optional) as
appropriate instead.
Secondly, add various (not nullable) annotations as needed by the new
default in gobject-introspection of marking gpointers as (nullable). See
https://bugzilla.gnome.org/show_bug.cgi?id=729660.
This includes adding some stub documentation comments for the
assertion macro error functions, which weren’t previously documented.
The new comments are purely to allow for annotations, and hence are
marked as (skip) to prevent the symbols appearing in the GIR file.
https://bugzilla.gnome.org/show_bug.cgi?id=719966
This would allow bindings to use _get_option_group() functions, which
would then allow them to use GOption parsing.
This also adds introspection annotations to
g_option_context_add_group(), g_option_context_set_main_group() and
g_option_context_get_main_group().
https://bugzilla.gnome.org/show_bug.cgi?id=743349
GMappedFile is current unintrospectable, because it's not a registered
box type. It already has reference counting functions, so there's
little reason not to box it.
This commit adds GMappedFile to the hoard of other boxes types handled
by gboxed.c
https://bugzilla.gnome.org/show_bug.cgi?id=712393
Back in the far-off twentieth century, it was normal on unix
workstations for U+0060 GRAVE ACCENT to be drawn as "‛" and for U+0027
APOSTROPHE to be drawn as "’". This led to the convention of using
them as poor-man's ‛smart quotes’ in ASCII-only text.
However, "'" is now universally drawn as a vertical line, and "`" at a
45-degree angle, making them an `odd couple' when used together.
Unfortunately, there are lots of very old strings in glib, and also
lots of new strings in which people have kept up the old tradition,
perhaps entirely unaware that it used to not look stupid.
Fix this by just using 'dumb quotes' everywhere.
https://bugzilla.gnome.org/show_bug.cgi?id=700746
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
The GValueArray type was added in a time, during the Jurassic era or so,
when GArray did not have a representable GType. The GValueArray API has
various issues as well:
- it doesn't match the other GLib array types;
- it is not reference counted;
- the structure is fully exposed on the stack, so it cannot be
extended to add reference counting;
- it cannot be forcibly resized.
The nice thing is that now we have a GArray type that can replace in
full GValueArray, so we can deprecate the latter, and reduce the
complexity in GLib, application code, and bindings.
https://bugzilla.gnome.org/show_bug.cgi?id=667228
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
Based on a patch by Giovanni Campagna <gcampagna@src.gnome.org>
From discussion, GVariantIter is not useful for bindings, but
GVariantBuilder may be.
https://bugzilla.gnome.org/show_bug.cgi?id=646635
This way we don't need to keep a custom array that we bsearch on (and
that isn't threadsafe) but can use the gtype.c machinery that is
threadsafe. And fast, too!
https://bugzilla.gnome.org/show_bug.cgi?id=554887
This eases cleaning up these functions.
One optimization in value_set_internal() was lost in the process. It
shouldn't cause too many issues when all is said and done.
https://bugzilla.gnome.org/show_bug.cgi?id=554887
* configure.in: Define an ENABLE_REGEX macro
* gobject/gboxed.c: Don't refer to g_regex_ref if ENABLE_REGEX
is not defined.
svn path=/trunk/; revision=7815
2008-06-22 Michael Natterer <mitch@imendio.com>
* *.c: remove trailing whitespace from newly added gtk-doc
comments and reformatted some where they contained overly long or
ill-formatted lines.
svn path=/trunk/; revision=7090
2008-06-22 Michael Natterer <mitch@imendio.com>
* *.c: moved includes back to the top of the files (before gtk-doc
SECTION comments). Add "config.h" in all files and move system
included before glib includes. Remove trailing whitespace from
SECTION comments and did some reformatting where lines were overly
long, no documentation content was changed.
svn path=/trunk/; revision=7089
* gobject/gboxed.c:
* gobject/gclosure.c:
* gobject/genums.c:
* gobject/gvalue.c:
Use file-names from the section file for SECTION: comments.
svn path=/trunk/; revision=7072
