Update GIR files

GLib-2.0.gir

@@ -34957,7 +34957,7 @@ its type nor its content can be modified further.
 
 `GVariant` is useful whenever data needs to be serialized, for example when
 sending method parameters in D-Bus, or when saving settings using
-[class@Gio.Settings].
+[`GSettings`](../gio/class.Settings.html).
 
 When creating a new `GVariant`, you pass the data you want to store in it
 along with a string representing the type of data you wish to pass to it.
@@ -35002,7 +35002,7 @@ Serialized `GVariant` data can also be sent over the network.
 `GVariant` instances can be sent over D-Bus.  See [type@GLib.VariantType] for
 exceptions.  (However, `GVariant`’s serialization format is not the same
 as the serialization format of a D-Bus message body: use
-[class@Gio.DBusMessage], in the GIO library, for those.)
+[GDBusMessage](../gio/class.DBusMessage.html), in the GIO library, for those.)
 
 For space-efficiency, the `GVariant` serialization format does not
 automatically include the variant’s length, type or endianness,
@@ -38662,10 +38662,10 @@ type’.
 This is similar to how instances of abstract classes may not
 directly exist in other type systems, but instances of their
 non-abstract subtypes may.  For example, in GTK, no object that has
-the type of [class@Gtk.Widget] can exist (since [class@Gtk.Widget] is an
-abstract class), but a [class@Gtk.Window] can certainly be instantiated, and
-you would say that the [class@Gtk.Window] is a [class@Gtk.Widget] (since
-[class@Gtk.Window] is a subclass of [class@Gtk.Widget]).
+the type of [`GtkWidget`](https://docs.gtk.org/gtk4/class.Widget.html) can
+exist (since `GtkWidget` is an abstract class), but a [`GtkWindow`](https://docs.gtk.org/gtk4/class.Window.html)
+can certainly be instantiated, and you would say that a `GtkWindow` is a
+`GtkWidget` (since `GtkWindow` is a subclass of `GtkWidget`).
 
 Two types may not be compared by value; use [method@GLib.VariantType.equal]
 or [method@GLib.VariantType.is_subtype_of]  May be copied using
@@ -38693,7 +38693,8 @@ The above definition is recursive to arbitrary depth. `aaaaai` and
 `a(aa(ui)(qna{ya(yd)}))`. In order to not hit memory limits,
 [type@GLib.Variant] imposes a limit on recursion depth of 65 nested
 containers. This is the limit in the D-Bus specification (64) plus one to
-allow a [class@Gio.DBusMessage] to be nested in a top-level tuple.
+allow a [`GDBusMessage`](../gio/class.DBusMessage.html) to be nested in
+a top-level tuple.
 
 The meaning of each of the characters is as follows:
 
@@ -43535,15 +43536,15 @@ See your C library manual for more details about creat().</doc>
       </parameters>
     </function>
     <function-macro name="critical" c:identifier="g_critical" introspectable="0">
-      <doc xml:space="preserve">Logs a &#x2018;critical warning&#x2019; ([flags@GLib.LogLevelFlags.CRITICAL]).
+      <doc xml:space="preserve">Logs a &#x2018;critical warning&#x2019; ([flags@GLib.LogLevelFlags.LEVEL_CRITICAL]).
 
 Critical warnings are intended to be used in the event of an error
 that originated in the current process (a programmer error).
 Logging of a critical error is by definition an indication of a bug
 somewhere in the current program (or its libraries).
 
 [func@GLib.return_if_fail], [func@GLib.return_val_if_fail], [func@GLib.return_if_reached] and
-[func@GLib.return_val_if_reached] log at [flags@GLib.LogLevelFlags.CRITICAL].
+[func@GLib.return_val_if_reached] log at [flags@GLib.LogLevelFlags.LEVEL_CRITICAL].
 
 You can make critical warnings fatal at runtime by
 setting the `G_DEBUG` environment variable (see
@@ -47852,9 +47853,9 @@ environment variables:
     these messages are not printed. If you need to set the allowed
     domains at runtime, use [func@GLib.log_writer_default_set_debug_domains].
 
-`stderr` is used for levels [flags@GLib.LogLevelFlags.ERROR],
-[flags@GLib.LogLevelFlags.CRITICAL], [flags@GLib.LogLevelFlags.WARNING] and
-[flags@GLib.LogLevelFlags.MESSAGE]. `stdout` is used for
+`stderr` is used for levels [flags@GLib.LogLevelFlags.LEVEL_ERROR],
+[flags@GLib.LogLevelFlags.LEVEL_CRITICAL], [flags@GLib.LogLevelFlags.LEVEL_WARNING] and
+[flags@GLib.LogLevelFlags.LEVEL_MESSAGE]. `stdout` is used for
 the rest, unless `stderr` was requested by
 [func@GLib.log_writer_default_set_use_stderr].
 
@@ -47922,7 +47923,7 @@ This has no effect if structured logging is enabled; see
 
 When a message with any of these levels is logged the program terminates.
 You can only set the levels defined by GLib to be fatal.
-[flags@GLib.LogLevelFlags.ERROR] is always fatal.
+[flags@GLib.LogLevelFlags.LEVEL_ERROR] is always fatal.
 
 You can also make some message levels fatal at runtime by setting
 the `G_DEBUG` environment variable (see
@@ -47993,7 +47994,7 @@ This has no effect if structured logging is enabled; see
     <function name="log_set_fatal_mask" c:identifier="g_log_set_fatal_mask">
       <doc xml:space="preserve">Sets the log levels which are fatal in the given domain.
 
-[flags@GLib.LogLevelFlags.ERROR] is always fatal.
+[flags@GLib.LogLevelFlags.LEVEL_ERROR] is always fatal.
 
 This has no effect on structured log messages (using [func@GLib.log_structured] or
 [func@GLib.log_structured_array]). To change the fatal behaviour for specific log
@@ -48002,9 +48003,9 @@ messages, programs must install a custom log writer function using
 [Using Structured Logging](logging.html#using-structured-logging).
 
 This function is mostly intended to be used with
-[flags@GLib.LogLevelFlags.CRITICAL].  You should typically not set
-[flags@GLib.LogLevelFlags.WARNING], [flags@GLib.LogLevelFlags.MESSAGE], [flags@GLib.LogLevelFlags.INFO] or
-[flags@GLib.LogLevelFlags.DEBUG] as fatal except inside of test programs.</doc>
+[flags@GLib.LogLevelFlags.LEVEL_CRITICAL].  You should typically not set
+[flags@GLib.LogLevelFlags.LEVEL_WARNING], [flags@GLib.LogLevelFlags.LEVEL_MESSAGE], [flags@GLib.LogLevelFlags.LEVEL_INFO] or
+[flags@GLib.LogLevelFlags.LEVEL_DEBUG] as fatal except inside of test programs.</doc>
       <return-value transfer-ownership="none">
         <doc xml:space="preserve">the old fatal mask for the log domain</doc>
         <type name="LogLevelFlags" c:type="GLogLevelFlags"/>
@@ -48024,12 +48025,12 @@ This function is mostly intended to be used with
       <doc xml:space="preserve">Sets the log handler for a domain and a set of log levels.
 
 To handle fatal and recursive messages the @log_levels parameter
-must be combined with the [flags@GLib.LogLevelFlags.FATAL] and [flags@GLib.LogLevelFlags.RECURSION]
+must be combined with the [flags@GLib.LogLevelFlags.FLAG_FATAL] and [flags@GLib.LogLevelFlags.FLAG_RECURSION]
 bit flags.
 
-Note that since the [flags@GLib.LogLevelFlags.ERROR] log level is always fatal, if
+Note that since the [flags@GLib.LogLevelFlags.LEVEL_ERROR] log level is always fatal, if
 you want to set a handler for this log level you must combine it with
-[flags@GLib.LogLevelFlags.FATAL].
+[flags@GLib.LogLevelFlags.FLAG_FATAL].
 
 This has no effect if structured logging is enabled; see
 [Using Structured Logging](logging.html#using-structured-logging).
@@ -48068,8 +48069,8 @@ g_log_set_handler ("GLib", G_LOG_LEVEL_MASK | G_LOG_FLAG_FATAL
         <parameter name="log_levels" transfer-ownership="none">
           <doc xml:space="preserve">the log levels to apply the log handler for.
    To handle fatal and recursive messages as well, combine
-   the log levels with the [flags@GLib.LogLevelFlags.FATAL] and
-   [flags@GLib.LogLevelFlags.RECURSION] bit flags.</doc>
+   the log levels with the [flags@GLib.LogLevelFlags.FLAG_FATAL] and
+   [flags@GLib.LogLevelFlags.FLAG_RECURSION] bit flags.</doc>
           <type name="LogLevelFlags" c:type="GLogLevelFlags"/>
         </parameter>
         <parameter name="log_func" transfer-ownership="none" closure="3">
@@ -48100,8 +48101,8 @@ This has no effect if structured logging is enabled; see
         <parameter name="log_levels" transfer-ownership="none">
           <doc xml:space="preserve">the log levels to apply the log handler for.
   To handle fatal and recursive messages as well, combine
-  the log levels with the [flags@GLib.LogLevelFlags.FATAL] and
-  [flags@GLib.LogLevelFlags.RECURSION] bit flags.</doc>
+  the log levels with the [flags@GLib.LogLevelFlags.FLAG_FATAL] and
+  [flags@GLib.LogLevelFlags.FLAG_RECURSION] bit flags.</doc>
           <type name="LogLevelFlags" c:type="GLogLevelFlags"/>
         </parameter>
         <parameter name="log_func" transfer-ownership="none" scope="notified" closure="3" destroy="4">
@@ -48154,7 +48155,7 @@ There can only be one writer function. It is an error to set more than one.</doc
 
 The message will be passed through to the log writer set by the application
 using [func@GLib.log_set_writer_func]. If the message is fatal (i.e. its log level
-is [flags@GLib.LogLevelFlags.ERROR]), the program will be aborted by calling
+is [flags@GLib.LogLevelFlags.LEVEL_ERROR]), the program will be aborted by calling
 [func@GLib.BREAKPOINT] at the end of this function. If the log writer returns
 [enum@GLib.LogWriterOutput.UNHANDLED] (failure), no other fallback writers will be tried.
 See the documentation for [type@GLib.LogWriterFunc] for information on chaining
@@ -48264,7 +48265,7 @@ manually to the format string.</doc>
 
 The message will be passed through to the log writer set by the application
 using [func@GLib.log_set_writer_func]. If the
-message is fatal (i.e. its log level is [flags@GLib.LogLevelFlags.ERROR]), the program will
+message is fatal (i.e. its log level is [flags@GLib.LogLevelFlags.LEVEL_ERROR]), the program will
 be aborted at the end of this function.
 
 See [func@GLib.log_structured] for more documentation.
@@ -48431,8 +48432,8 @@ The built-in log functions are [func@GLib.log_default_handler] for the
 old-style API, and both [func@GLib.log_writer_default] and
 [func@GLib.log_writer_standard_streams] for the structured API.
 
-By default, log messages of levels [flags@GLib.LogLevelFlags.INFO] and
-[flags@GLib.LogLevelFlags.DEBUG] are sent to `stdout`, and other log messages are
+By default, log messages of levels [flags@GLib.LogLevelFlags.LEVEL_INFO] and
+[flags@GLib.LogLevelFlags.LEVEL_DEBUG] are sent to `stdout`, and other log messages are
 sent to `stderr`. This is problematic for applications that intend
 to reserve `stdout` for structured output such as JSON or XML.
 
@@ -48600,7 +48601,7 @@ defined, but will always return [enum@GLib.LogWriterOutput.UNHANDLED].</doc>
       <doc xml:space="preserve">Format a structured log message and print it to either `stdout` or `stderr`,
 depending on its log level.
 
-[flags@GLib.LogLevelFlags.INFO] and [flags@GLib.LogLevelFlags.DEBUG] messages
+[flags@GLib.LogLevelFlags.LEVEL_INFO] and [flags@GLib.LogLevelFlags.LEVEL_DEBUG] messages
 are sent to `stdout`, or to `stderr` if requested by
 [func@GLib.log_writer_default_set_use_stderr];
 all other log levels are sent to `stderr`. Only fields
@@ -55076,7 +55077,7 @@ This API may only be used with the old logging API ([func@GLib.log] without
 `G_LOG_USE_STRUCTURED` defined). It will not work with the structured logging
 API. See [Testing for Messages](logging.html#testing-for-messages).
 
-If messages at [flags@GLib.LogLevelFlags.DEBUG] are emitted, but not explicitly
+If messages at [flags@GLib.LogLevelFlags.LEVEL_DEBUG] are emitted, but not explicitly
 expected via [func@GLib.test_expect_message] then they will be ignored.</doc>
     </function-macro>
     <function name="test_assert_expected_messages_internal" c:identifier="g_test_assert_expected_messages_internal">
@@ -55294,7 +55295,7 @@ Note that you cannot use this to test [func@GLib.error] messages, since
 [func@GLib.error] intentionally never returns even if the program doesn&#x2019;t
 abort; use [func@GLib.test_trap_subprocess] in this case.
 
-If messages at [flags@GLib.LogLevelFlags.DEBUG] are emitted, but not explicitly
+If messages at [flags@GLib.LogLevelFlags.LEVEL_DEBUG] are emitted, but not explicitly
 expected via [func@GLib.test_expect_message] then they will be ignored.</doc>
       <return-value transfer-ownership="none">
         <type name="none" c:type="void"/>
@@ -60386,9 +60387,9 @@ other trusted programs violating protocol, invalid contents in
 trusted files, etc.)
 
 If attempting to deal with programmer errors (for example, incorrect function
-parameters) then you should use [flags@GLib.LogLevelFlags.CRITICAL] instead.
+parameters) then you should use [flags@GLib.LogLevelFlags.LEVEL_CRITICAL] instead.
 
-[func@GLib.warn_if_reached] and func@GLib.warn_if_fail] log at [flags@GLib.LogLevelFlags.WARNING].
+[func@GLib.warn_if_reached] and func@GLib.warn_if_fail] log at [flags@GLib.LogLevelFlags.LEVEL_WARNING].
 
 You can make warnings fatal at runtime by setting the `G_DEBUG`
 environment variable (see

Gdk-3.0.gir

@@ -14773,7 +14773,7 @@ See gdk_keymap_get_caps_lock_state().</doc>
     <constant name="MAX_TIMECOORD_AXES" value="128" c:type="GDK_MAX_TIMECOORD_AXES">
       <type name="gint" c:type="gint"/>
     </constant>
-    <constant name="MICRO_VERSION" value="40" c:type="GDK_MICRO_VERSION">
+    <constant name="MICRO_VERSION" value="41" c:type="GDK_MICRO_VERSION">
       <type name="gint" c:type="gint"/>
     </constant>
     <constant name="MINOR_VERSION" value="24" c:type="GDK_MINOR_VERSION">