This makes them consistent with the other getter methods in
`GIRepository` which return lists/arrays. It’s useful to return the
length, as that means the caller doesn’t have to work it out by
iterating over the entire array.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Otherwise there’s no obvious suitable return value to return when the
union is *not* discriminated.
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
As with previous commits, don’t use up half the return value space to
indicate an invalid index.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Rather than mixing `-1` and valid indexes, split out the indication of
whether the type is an array with a length argument from the actual
index of the length argument.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Return information about whether the type is a fixed-size array
separately from the array size, which allows us to use the full `size_t`
for the array size.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
We used to use unsigned values, while they should be big enough to old
the data we're handling here, it's cleaner and clearer if we use size_t
as type for such values, as it makes straight forward to understand what
a value should contain. It also makes these values more future proof.
We just do a safe s/gsize/size_t/ replacement here without doing any
changes to places in which different size of size_t and gsize may be
actually different and create troubles.
And rename it to `gi_repository_get_shared_libraries()`. Previously it
returned a comma-separated string, which wasn’t particularly typesafe or
machine-friendly. Now it returns the same data as an array.
This is an API break in libgirepository, but since it’s not been in a
stable release yet, that’s fine.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Review and update the documentation, making sure it’s complete,
formatted in gi-docgen format, and has all appropriate GIR annotations
and `Since:` lines.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
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 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
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
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
Add the SPDX license runes to all the files which have an obvious
copyright header already. This is a mechanical edit.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3155
