`P_()` is for pspec strings — it gave us the option to split them out to
a separate translation domain. `_()` is for normal strings.
Spotted by Sophie Herold: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3411#note_1733329
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Nicks and blurbs don't have any practical use for gio/gobject libraries.
Leaving tests untouched since this features is still used by other libraries.
Closes#2991
Previously these properties would have been documented using the strings
from the pspec, but those will be removed in the following commit. Re-add
the documentation using those strings, but as gi-docgen documentation
comments.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #2991
The `#include <langinfo.h>` in `gdatetime.c` is currently predicated on
`HAVE_LANGINFO_TIME`, but it’s needed for all the `HAVE_LANGINFO_*`
features.
It seems the code implicitly assumes that `HAVE_LANGINFO_TIME` will be
true if any other `HAVE_LANGINFO_*` macros are true. While I haven’t
seen this assumption be broken in practice, it seems prudent to
explicitly encode that in the configure tests. It’s easy enough to do.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This was pointed out in the review for !3696 but owing to a mistake by
me, the fix was not included in the version of the MR which was merged.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3119
I wrote the changes before clarifying the copyright status of my
contract with the GNOME Foundation, and forgot to update them.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3119
It was previously set (by default) to `C`, so this commit doesn’t change
the locale behaviour of the tests, but does ensure that messages printed
by the tests are correctly formatted in UTF-8 rather than transliterated
to ASCII.
That makes interpreting test output easier.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
The `%E` modifier causes dates to be formatted using an alternative era
representation for years. This doesn’t do anything for most dates, but
in locales such as Thai and Japanese it causes years to be printed using
era names.
In Thai, this means the Thai solar calendar
(https://en.wikipedia.org/wiki/Thai_solar_calendar). In Japanese, this
means Japanese era names
(https://en.wikipedia.org/wiki/Japanese_era_name).
The `%E` modifier syntax follows what’s supported in glibc — see
nl_langinfo(3).
Supporting this is quite involved, as it means loading the `ERA`
description from libc and parsing it.
Unit tests are included.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Fixes: #3119
GDBus has always supported matching strings with arg0 matching
(`G_DBUS_SIGNAL_FLAGS_MATCH_ARG0_PATH`). In D-Bus 1.5, support was added
to the spec for also matching object paths. This got forgotten about and
was never added to GDBus, meaning that
`G_DBUS_SIGNAL_FLAGS_MATCH_ARG0_PATH` won’t match against a signal arg0
of type `o`.
Fix that, and add a unit test.
To do so, we need to add a new `g_dbus_message_get_arg0_path()` API to
complement the existing `g_dbus_message_get_arg0()` API. The approach of
letting `g_dbus_message_get_arg0()` return an object-path *or* a string
would not work, as it’s also called in the implementation of
`G_DBUS_SIGNAL_FLAGS_MATCH_ARG0_NAMESPACE`, which must only match
string-typed arg0 values and not object-path-typed ones.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3183
Technically we can’t rely on it being kept alive by the `message->body`
pointer, unless we can guarantee that the `GVariant` is always
serialised. That’s not necessarily the case, so keep a separate ref on
the arg0 value at all times.
This avoids a potential use-after-free.
Spotted by Thomas Haller in
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3720#note_1924707.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3183
Point people to the official PCRE documentation instead, which is going
to be more up to date. This saves us periodically having to copy in and
reformat the PCRE documentation.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
We haven’t made any backwards-incompatible changes since GLib 2.2 in
2002. It’s probably not very useful to tell people about those any more.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
They were previously `xi:include`d into some of the GDBus documentation,
but since the GDBus documentation was ported to Markdown that’s no
longer possible, so the object manager example docs now serve no
purpose.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Move them to a separate page as they don’t really have a ‘class’ struct
each to hang docs off.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Move it to a separate page, with a massive great list of all the misc
utils. Not a great documentation page, but equivalent to what we had
before, and it can be improved in future.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
All this API is internal to GLib, so the section was never actually
exposed in the public API documentation. Keep the documentation, just
don’t tag it as a SECTION.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Move it to a separate documentation file, since most of what’s covered
isn’t introspectable.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Move it to a separate page so the difference between `g_rand_*()` and
`g_random_*()` can be explained.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
It was one paragraph which mentioned `GHookList` and `GHook`, both of
which have their own adequate documentation sections.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Move it to a separate page so more detail can be provided about all the
groups of API.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037