Because they return the function name, not a `GIFunctionInfo` for the
function, or anything else.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
This is an API break, but libgirepository has not been in a stable
release yet, so that’s fine.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Indicate that they return an argument index, not the argument itself.
This is an API break, but libgirepository has not been in a stable GLib
release yet, so that’s fine.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
This makes it more conventional for how `GType` code is normally written.
This introduces no functional changes, but it is an API break.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Move the SECTION into the struct docs, update the documentation comment
syntax, and add `Since: 2.80` everywhere.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
For the moment, this is enough to roughly verify that the port to
`GTypeInstance` has not massively broken things. It’s not anywhere near
sufficient to qualify as a proper test suite though.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
If they’re all named after the actual library name, rather than a
contraction of it, that’s easier to remember so they can be easily
referenced elsewhere in the build system (such as when adding unit
tests).
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
It’s not intended that most people will use this, but it’s going to be
quite useful for adding unit tests — we don’t really want the unit tests
to share global state (a singleton `GIRepository`) between tests.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
This adds more type safety to libgirepository, and allows
differentiating the `GIBaseInfo` derived types using the type system.
Two new derived types had to be added (previously they were just a
collection of helper methods which worked directly on a `GIBaseInfo` and
didn’t check types): `GICallbackInfo` and `GIUnresolvedInfo`.
Further cleanups and refactoring might be needed on this, but the core
of libgirepository now uses `GTypeInstance` and appears to still work
(it’s difficult to be entirely sure because there are no unit tests
yet).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
This is an API break, but that’s fine since we haven’t frozen the
libgirepository API yet.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
This method doesn’t return a `GType`, so when the code gets ported to
`GTypeInstance` in an upcoming commit, that will become quite confusing.
Rename it to `gi_base_info_get_info_type()` instead.
This introduces no functional changes, but it is an API break.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
The `type` field will eventually disappear, so use an accessor method to
get it.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
These aren’t needed at the moment, since all the `TypeInfo` structs in
libgirepository are all aliases for each other.
An upcoming commit will change that, however, so we need to be a little
bit stricter about type safety in advance.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
These methods don’t return a `GType`, so when the code gets ported to
`GTypeInstance` in an upcoming commit, that will become quite confusing.
Rename them all to `get_type_info()` instead.
This introduces no functional changes, but it is an API break.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Move the SECTION into the struct docs, update the documentation comment
syntax, and add `Since: 2.80` everywhere.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Move the SECTION into the struct docs, update the documentation comment
syntax, and add `Since: 2.80` everywhere.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Move the SECTION into the struct docs, update the documentation comment
syntax, and add `Since: 2.80` everywhere.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Otherwise the GIR generation for libgirepository doesn’t work, as GLib
doesn’t get pulled in to provide basic types.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
They were still failing with `-Dglib_assert=false` because
`G_DISABLE_ASSERT` wasn’t being explicitly un-defined for the test.
See https://gitlab.gnome.org/GNOME/glib/-/jobs/3309889
Also while we’re there, take the opportunity to correctly set the test
suite, protocol and environment.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Now that libgirepository uses `GI_AVAILABLE_IN_*` macros, that’s what
controls symbol visibility. The `_` prefixes are redundant, and out of
keeping with the rest of GLib.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Now that libgirepository is inside glib.git, it’s guaranteed access to
all the latest APIs, so there’s no need for version checks.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Rather than a mix of structs being in `GI` and their methods being in
`g_`.
We’ve chosen not to use the `g_` namespace because a number of the
libgirepository class names are quite generic, so we’d end up with
confusing symbols like `GScopeType` and `GArgument`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
