All of these warnings indicate programmer error, so critical is most
appropriate here.
Exceptions: deprecation warnings are just warnings. Also, warnings that
are worded with uncertainty can remain warnings rather than criticals.
These have all been added manually, as I’ve finished all the files which
I can automatically detect.
All the license headers in this commit are for LGPL-2.1-or-later, and
all have been double-checked against the license paragraph in the file
header.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
When rendering the contents of the GLib documentation stored inside the
introspection data, a common behaviour is to take the first paragraph as
a summary of the symbol being documented.
The documentation is assumed to be in Markdown format, which means:
- paragraphs must be separated by newlines
- lines that have an indentation of four or more spaces are considered
code blocks
- lines that start with a `#` are considered titles
This means we need to slightly tweak the documentation in our sources to
ensure that it can be rendered appropriately by tools that are not
gtk-doc.
See issue: #2365
Use the new g_type_interface_instantiable_prerequisite() to check
compatibility for transform functions.
In particular, this allows interfaces (in my case GDK_TYPE_PAINTABLE) to
be transformed to/from any GObject type (in my case G_TYPE_OBJECT) using
the transform function registered to transform between any 2 objects
(g_value_object_transform_value() does a type check and uses NULL if the
types don't match).
And this in turn allows be to g_object_bind_property() a gobject-typed
generic property (GtkListItem::item) to a GtkImage::paintable.
Tests for the new functionality are included.
Use the new g_type_interface_instantiable_prerequisite() to check
compatibility for transform functions.
In particular, this allows interfaces (in my case GDK_TYPE_PAINTABLE) to
be transformed to/from any GObject type (in my case G_TYPE_OBJECT) using
the transform function registered to tranform between any 2 objects
(g_value_object_transform_value() does a type check and uses NULL if the
types don't match).
And this in turn allows be to g_object_bind_property() a gobject-typed
generic property (GtkListItem::item) to a GtkImage::paintable.
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
g_value_unset() only works with initialized value and will assert
if the GValue is zero-filled (or initialized with G_VALUE_INIT). Document
this behaviour and refer to g_value_clear() for a method that work on
both initialized and zero-filled GValue.
https://bugzilla.gnome.org/show_bug.cgi?id=755766
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
Since we are no longer using sgml mode, using /* */ to
escape block comments inside examples does not work anymore.
Switch to using line comments with //
If two GValues are transformable, it implies they are compatible,
so you do not need to check for compatibility yourself. Bump the
documentation to reflect this fact.
https://bugzilla.gnome.org/show_bug.cgi?id=707111
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
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
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
2008-08-22 Björn Lindqvist <bjourne@gmail.com>
Bug 523939 – Example program for GValue
* gobject/gvalue.c: Add code example that demonstrates GValue's
features.
svn path=/trunk/; revision=7387
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
* 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
Mon Oct 2 15:50:16 2006 Tim Janik <timj@gtk.org>
* gvalue.c (g_value_peek_pointer): reverted a change to have an
assert instead of a g_return_val_if_fail() here. libraries (and
programs) should only ever g_assert or g_error if there is no way
to carry on with the current program state. that's clearly not
the case here.
* ChangeLog: added missing changelog entry for 2003-12-30.
2005-03-14 Matthias Clasen <mclasen@redhat.com>
* abicheck.sh: Make work again.
* gsourceclosure.c: Fix a typo.
Make PLT-reduction work with gcc4, and don't include
everything in gobjectalias.h:
* gobject.symbols: Group symbols by header and source
file.
* makegobjectalias.pl: Protect definitions by the same
preprocessor symbols used to guard the headers. Move
the alias declarations to a separate file which is
produced when calling makegalias.pl -def
* Makefile.am (gobjectaliasdef.c): Add a rule to
build this file.
* *.c: Include gobjectalias.h after the other i
GLib headers, include gobjectaliasdef.c at the bottom.
2004-09-16 Matthias Clasen <mclasen@redhat.com>
Implement the same PLT reduction technique used in GTK+:
* Makefile.am: Generate gobjectalias.h from gobject.symbols.
(BUILT_SOURCES): Add gobjectalias.h.
* makegobjectalias.pl: Script to generate gobjectalias.h.
* *.c: Include gobjectalias.h
Wed Dec 17 23:29:17 2003 Matthias Clasen <maclas@gmx.de>
* gvalue.c (g_value_peek_pointer): Use g_assert() instead of
g_return_val_if_fail(), suggested by Sheldon Simms.
Tue Aug 19 04:08:14 2003 Tim Janik <timj@gtk.org>
* gvalue.c: adapt to new gbsearcharray.h code.
(g_value_register_transform_func): turn transform function
replacement into a valid operation.
* gsignal.c: adapt to new gbsearcharray.h code.
* gboxed.c: adapt to new gbsearcharray.h code.
Mon Feb 17 20:59:47 2003 Tim Janik <timj@gtk.org>
* gvalue.c (g_value_register_transform_func): don't assert the types
passed in to have value tables. this prevents dynamic types from
registering transform functions.
