As we start moving documentation over from gtk-doc to gi-docgen, the
gtk-doc coverage is going to go down and things are going to start
breaking. That’s OK; we don’t need to test it any more.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #3037
The files here are copied from the docs-gtk-org
branch of gtk.
This adds gi-docgen to the CI Dockerfiles and ensures the new versions
(including the OS upgrades from the previous commit) are used during CI.
Helps: #3037
We can't easily use g_autofd with g_unix_open_pipe, because its
parameter is an array of two fds that both need closing. Add an inline
convenience wrapper providing the obvious semantics.
Signed-off-by: Simon McVittie <smcv@collabora.com>
I'm not aware of any platforms where this is a problem in practice, but
it's definitely nonportable and doesn't hurt to document it.
I wonder about CHERI....
These functions can be used to initalize pointer-type variables rather
than a gsize. This is required to support CHERI-enabled platforms where
gsize cannot be used to store pointers. Follow-up changes will migrate
the uses of g_once_init that store pointers to the new API
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
The `GTK_USE_PORTAL` environment variable has started to be misused by
users, which is causing deployment issues (such as portal services
themselves ending up being forced to use portals, which is never going
to work).
Try and sidestep users’ broken configurations by renaming the
environment variable, and also separating it from the old GTK
environment variable, since the GLib one affects a lot more processes.
This environment variable is meant to be used for
debugging and development, and never in production.
GTK already renamed their environment variable in
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4829, so keeping the
`GTK_USE_PORTAL` name in GLib doesn’t make sense anyway.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #3107
This reverts commit 252bbcd207.
After further discussion in !3511, we’ve decided that there are risks
associated with this change, and it’s not the best way of addressing the
original problem.
The original motivation for the change turned out to be that
`-mms-bitfields` was not handled by `windres`, which was receiving it
from `pkg-config --cflags glib-2.0` in some projects. However, if
`windres` is claiming to accept CFLAGS then it should accept (and
ignore) `-mms-bitfields`, since the `-m` family of options are defined
in `man gcc`, just like `-I`, `-D`, etc.
There is some question that there might still be third party projects
which are built with an old enough compiler that `-mms-bitfields` is not
the compiler default. For that reason, we should either still continue
to specify `-mms-bitfields` in the `.pc` file, or add a test to assert
that third party projects are always compiled with `-mms-bitfields` set.
But adding a new test for all third-party compilations is risky (if we
get it wrong, things will break; and it’s a test which may behave
differently on different platforms), so it seems safer to just keep
`-mms-bitfields` in `.pc` for now.
Once all compilers which we require specify `-mms-bitfields` by default,
we can finally drop this flag (without adding a test for third-party
compilations).
See: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3511
This documents the practices that I’ve been trying to follow for the
last few years for managing GLib issues and merge requests, and why they
seem to work well enough.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The introspection scanner cannot deal very well with function pointers
into a plain structure. In order to document the various function
pointers in GTypeValueTable we need to create typed callbacks, and
use them to replace the anonymous function pointers inside the
structure. This not only allows us to properly document the function
pointers, but it also allows us to annotate the arguments and return
value of those function pointers.
See also: https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/400#note_1721707
Since we have a convenience method to add actions let's allow to remove
them just as easily. This makes resource cleanup as simple as initially
adding the entries.
Adds a helper to truncate UTF8 strings in the middle, allowing to make
them fit certain size constraints.
This function is modeled after similar functionality that has existed
since 2008 in nautilus and in eel before that.
It’s a bit confusing to have two files called `README`, especially given
that `README.win32.md` only contains build instructions and none of the
other overview/contribution/bug reporting information that `README.md`
contains.
It feels like these would be better organised by having one top-level
`README.md`, and pointing to the Windows build instructions from there.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
GTK lost it's '+' suffix back in 2019, according to
<https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg00000.html>
This commit can be re-generated with:
git grep -l GTK+ \
| grep -v -e ^NEWS -e ^glib/tests/collate.c \
| xargs sed -i 's/GTK+/GTK/g'
Most of the changes are in comments and documentation.
While x86_64 has enough precision in long double to do a round trip
from guint64 to long double and back, this is platform-specific, and
is a disservice to users trying to debug failing unit tests on other
architectures where it loses precision for g_assert_cmp{int,uint,hex}.
See also https://bugzilla.gnome.org/show_bug.cgi?id=788385 which
mentions having to add casts to specifically silence the compiler on
platforms where the precision loss occurs.
Meanwhile, g_assert_cmpuint() does an unsigned comparison, but outputs
signed values if the comparison fails, which is confusing.
Fix both issues by introducing a new g_assertion_message_cmpint()
function with a new 'u' numtype. For backwards compatibility, the
macros still call into the older g_assertion_message_cmpnum() when not
targetting 2.78, and that function still works when passed 'i' and 'x'
types even though code compiled for 2.78 and later will never invoke
it with numtype anything other than 'f'. Note that g_assert_cmpmem
can also take advantage of the new code, even though in practice,
comparison between two size_t values representing array lengths that
can actually be compiled is unlikely to have ever hit the precision
loss. The macros in signals.c test code does not have to worry about
versioning, since it is not part of the glib library proper.
Closes#2997
Signed-off-by: Eric Blake <eblake@redhat.com>
I’ve finally found the right place in the docs to put this stuff.
This doesn’t auto-link this section from every string in the GLib
documentation, but I think that at this point (with gtk-doc in
maintenance mode, and gi-docgen not fully applied to GLib) I don’t think
we can do any better. The perfect is the enemy of the good, and having
this stuff documented somewhere means that someone can link to it from
multiple places in future *somehow*.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #116
By default, if a host environment has the `rst2html5` application
available, builds will automatically perform some HTML documentation
generation from the documentation's glib reference content (e.g.
creating `gvariant-specification-1.0.html`). The creation of this
documentation is not required for all use cases.
This commit tweaks the building of the HTML-based GLIB specification
document to be guarded by `gtk_doc`.
Signed-off-by: James Knight <james.d.knight@live.com>
Most of the document was about traps, which have not existed since
commit 58cdf0b474, 10 years ago.
The rest of the document was about `GOBJECT_DEBUG`, and that information
would be more easily findable in the full GObject documentation — so
move it there and update it a bit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Without a timeout, some lookup requests can go on forever, typically due
to bugs in underlying systems.
This can have particularly significant effects on the Happy Eyeballs
algorithm in `GSocketClient`, which relies on multiple name lookups as
its first step.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2866
We need a way to initialise refcounted types placed in static storage,
or on the stack. Using proper macros avoids knowing the magic constant
used for grefcount and gatomicrefcount.
The documentation previously implicitly said in a few places that
interfaces are classed, but reading through the implementation of
`GType`, I don’t think they are. If they were, the registration of the
fundamental `G_TYPE_INTERFACE` in `gobject_init()` would specify
`G_TYPE_FLAG_CLASSED`. It only specifies `G_TYPE_FLAG_DERIVABLE`.
I think this makes sense, because you can’t subclass an interface.
Subclassing is a key property of being classed.
Tweak the `GType` tutorial to remove that implicit statement, and expand
the documentation for `G_TYPE_IS_CLASSED`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #252
Keep the API for ABI compatibility.
See
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2935#note_1650099
for a summary of the reasoning for this change:
- The performance of system-provided allocators has improved since
GSlice was written, and they are now similarly as performant, or more
performant, than GSlice.
- The code is unmaintained and nobody understands it.
- It doesn’t integrate with tooling and system security features which
have been written for the system `malloc()` implementation (such as
sanitisers, valgrind, etc.).
- It’s confusing for developers: should they use `g_slice_new()` or
`g_new()`?
- GSlice is faster than the libc allocator for allocating and
(particularly) freeing linked lists, but since these are a rubbish
data structure, that’s not a great thing to optimise for.
For the cases where application performance is negatively impacted by
the implementation of GSlice being dropped (and we don’t think there’ll
be many), applications can use a drop-in `malloc()` replacement which is
more suited to their particular workload. Choosing an allocator in GLib
to suit all application workloads is not possible.
Including documentation updates and cleanups by Philip Withnall.
Fixes: #1079
Historically GPtrArray made possible to compare pointers of pointers values
that it holds, however this is inconvenient in most cases as it requires
wrapper functions and not friendly castings.
So, add two functions that allow to perform the comparisons between the
pointer values that a GPtrArray holds following the same syntax that we
share everywhere in the codebase.
It allows to create a GPtrArray from a null-terminated C array computing its
size and in case performing copies of the its values using the provided
GCopyFunc.
GPtrArray is a nice interface to handle pointer arrays, however if a classic
array needs to be converted into a GPtrArray is currently needed to manually
go through all its elements and do new allocations that could be avoided.
So add g_ptr_array_new_take() which steals the data from an array of
pointers and allows to manage it using the GPtrArray API.
Add functions to steal all the keys or values from a ghash (especially
useful when it's used as a set), passing the ownership of then to a
GPtrArray container that preserves the destroy notify functions.
GPtrArray's are faster than lists and provide more flexibility, so add
APIs to get hash keys and values using these containers too.
Given that we know the size at array initialization we can optimize the
allocation quite a bit, making it faster than the API using GList both at
creation time and for consumers.
This solves problems with validating untrusted inputs from D-Bus, where
invalid numbers of added and removed menu entries, and positions, could
be specified.
Original patch from
https://bugzilla.gnome.org/show_bug.cgi?id=728733#c7, tweaked by Philip
Withnall to add a few code comments and make
`G_MENU_EXPORTER_MAX_SECTION_SIZE` public so callers can check their
inputs against it if they want. Also tweaked to use `g_warning()` instead
of the nonexistent `g_dbus_warning()`.
Fixes: #861
Some applications (eg., gnome-photos) really want a large thumbnail,
if one can be created. Simply falling back to a smaller one (probably
created by an old nautilus), without giving the application a chance
to create a bigger thumbnail, is undesirable because they will appear
fuzzy.
Therefore, at separate attribute sets for all the thumbnail sizes
that are supported in the spec: normal/large/x-large/xx-large.
The old attribute will now return by default the biggest available, as
it used to be, but also including the x-large and xx-large cases.
Co-Authored-by: Marco Trevisan <mail@3v1n0.net>
Fixes: #621
This reverts commit 19353017a7.
The freedesktop SDK, which is used by gnome-build-meta, only has Meson
0.63. Bumping GLib’s Meson dependency to 0.64 means that, at the moment,
GLib is not buildable in gnome-build-meta and hence can’t be tested in
nightly pipelines against other projects, etc.
That’s bad for testing GLib.
It’s arguably bad that we’re restricted to using an older version of
Meson than shipped by Debian Testing, but that’s a separate discussion
to be had.
Revert the Meson 0.64 dependency until the freedesktop SDK ships Meson ≥
0.64. This also means reverting the simplifications to use of
`gnome.mkenum_simple()`.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3077#note_1601064
Because Meson complains about using `configure_file(copy: true)`.
Includes improvements by Xavier Claessens.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It’s been broken since we ported to Meson and nobody has complained, so
let’s deprecate it this cycle and remove it in GLib ≥ 2.78.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2786
Sadly, in C++ there's not an universal way to get what language standard
is used to compile GLib-based programs, in fact while most compilers
relies on `__cplusplus`, MSVC is defining that, but it does not use it
to expose such information (unless `/Zc:__cplusplus` arg is used).
On the other side, MSVC reports the language standard via _MSVC_LANG [1].
This complication makes us defining some macros in a very complex way
(such as glib_typeof()), because we need to perform many checks just to
understand if a C++ compiler is used and what standard is expecting.
To avoid this, define multiple macros that can be used to figure out
what C++ standard is being used.
[1] https://docs.microsoft.com/en-us/cpp/build/reference/zc-cplusplus?view=msvc-170
This can be used to mark entire types as deprecated,
and trigger a warning when they are instantiated
and `G_ENABLE_DIAGNOSTIC=1` is set in the environment.
There's currently no convenient macros for defining
types with the new flag, but you can do:
```c
_G_DEFINE_TYPE_EXTENDED_BEGIN (GtkAppChooserWidget,
gtk_app_chooser_widget,
GTK_TYPE_WIDGET,
G_TYPE_FLAG_DEPRECATED)
...
_G_DEFINE_TYPE_EXTENDED_END ()
```
Includes a unit test by Philip Withnall.
This will make it clear what the bigger changes are between versions.
Kind of like a `NEWS` file for the specification.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This should clarify object paths and signatures a little, if anyone
needs that. This introduces no semantic changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
reStructuredText doesn’t support cross-references unless always built
with Sphinx (as I understand it). `rst2html5` doesn‘t support them.
So reword this (currently manual) cross-reference so it’s less awkward.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
I believe the specification was originally a shorter extract of
Allison’s thesis. This left a few dangling references to requirements
which were listed in a part of the thesis not included in the
specification.
Reword them slightly so they’re not quite so awkward.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The licensing for the original GVariant specification was not specified
in the original PDF.
However, CC-BY-SA-3.0 has been agreed by Allison, the sole copyright
holder, here:
https://gitlab.gnome.org/Teams/documentation/developer-www/-/merge_requests/108/#note_1586866
The diagrams were redrawn by me, so their licensing/copyright status is
clear.
Tested with `reuse lint` to ensure the data is machine-readable.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This is a verbatim conversion of the GVariant Specification from
https://people.gnome.org/~desrt/gvariant-serialisation.pdf /
https://raw.githubusercontent.com/ostreedev/gvariant-rs/master/docs/gvariant-serialisation.pdf
to reStructuredText.
This is for several reasons:
1. The canonical copy has gone offline due to people.gnome.org being
shut down.
2. GLib is the reference implementation of GVariant, so should probably
host the specification (unless someone wants to host it on
freedesktop-specs).
3. Moving it out of a PDF and into reStructuredText should allow for
amendments. The specification has a few problems, typos and
oversights in its original form, and it would be good to canonically
fix them without having to write a separate addendum document.
This conversion is verbatim, and does not change the content of the
document at all, even to fix typos and broken links (which there are a
small number of in the PDF).
This describes what I’m labelling as version 1.0 of the GVariant
serialisation format. Updates to the specification can bump this version
number, in subsequent commits.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Similar to g_source_set_static_name, this avoids
strdup overhead for debug-only information in
possibly hot code paths.
We also add a macro wrapper for g_task_set_name that
uses __builtin_constant_p to decide whether to use
g_task_set_name or g_task_set_static_name.
Given that it can be computed using an error-prone strings comparisons it
is better to provide a variable everywhere, so that we don't have the
risk of comparing values that are always false.
Inspired by libglnx's glnx_close_fd() and glnx_autofd, these let us
have the same patterns as g_clear_object() and g_autoptr(GObject), but
for file descriptors. g_clear_fd() is cross-platform, while g_autofd
is syntactic sugar requiring a supported compiler (gcc or clang).
Now that g_close() checks for EBADF as a programming error, we can
implement the equivalent of glnx_autofd as an inline function without
needing to have errno and EBADF in the header file.
g_clear_fd() is like glnx_close_fd(), but with error checking.
The private _g_clear_fd_ignore_error() function used to implement
g_autofd is a closer equivalent of glnx_close_fd().
Signed-off-by: Simon McVittie <smcv@collabora.com>
GBookmarkFile has everything for being introspectable, but it lacks a
GType, because it can't be copied. So provide a copy function that
deeply copies all the bookmark structures.
Add tests for this.
This is like our other suite of g_set_*() based APIs to simplify and
improve correctness of setters for fields, properties, and more.
This implementation specifically handles setting string values that may
point to an offset within the current string by copying before free.
strcmp() is used directly (as opposed to g_strcmp0() due to it being in
gtestutils.h as well as to increase the chance that the compiler will
hoist the implementation.
Fixes#2747
There is currently no `dllimport` attribute on any of our function,
which prevents MSVC to optimize function calls.
To fix that issue, we need to redeclare all our visibility macros for
each of our libraries, because when compiling e.g. GIO code, we need
dllimport in GLIB headers and dllexport in GIO headers. That means they
cannot use the same GLIB_AVAILABLE_* macro.
Since that's a lot of boilerplate to copy/paste after each version bump,
this MR generate all those macros using a python script.
Also simplify the meson side by using `gnu_symbol_visibility : 'hidden'`
keyword argument instead of passing the cflag manually.
This leaves only API index to add manually into glib-docs.xml when
bumping GLib version. That file cannot be generated because Meson does
not allow passing a buit file to gnome.gtkdoc()'s main_xml kwarg
unfortunately.
Building the references requires libraries with all their symbols
available. Passing `-Dgtk_doc=true` and `-Ddefault_library=static`
should be considered a configuration error.
glib_debug is an auto option. This is clever because it allows us to
guess the best default based on the build type, while also allowing an
easy way to override if the guess is not good. Sadly, the attempt to
guess based on the build type does not work well. For example, it
considers debugoptimized builds to be debug builds, but despite the
name, it is definitely a release build type (except on Windows, which
we'll ignore here). The minsize build type has the exact same problem.
The debug option is true for both build types, but this only controls
whether debuginfo is enabled, not whether debug extras are enabled.
The plain build type has a different problem: debug is off, but the
optimization option is off too, even though plain builds are distro
builds are will almost always use optimization.
I've outlined an argument for why we should make these changes here:
https://blogs.gnome.org/mcatanzaro/2022/07/15/best-practices-for-build-options/
Specifically, Rule 4 shows all the build types and whether they
correspond to release builds or debug builds. Rule 6 argues that we
should provide good defaults for plain builds.
