Import Upstream version 2.72.4

This commit is contained in:
evinadmin 2023-07-04 11:23:22 +02:00
commit 4ef3ff9793
2003 changed files with 1332420 additions and 0 deletions

16
docs/reference/.gitignore vendored Normal file
View file

@ -0,0 +1,16 @@
*-decl-list.txt
*-decl.txt
*-unused.txt
*-undocumented.txt
*-undeclared.txt
*.args
*.hierarchy
*.interfaces
*.prerequisites
*.signals
*.stamp
html
xml
*.bak
version.xml
*.1

7
docs/reference/AUTHORS Normal file
View file

@ -0,0 +1,7 @@
Damon Chaplin <damon@karuna.freeserve.co.uk> and others.
See:
http://www.gtk.org/rdp/status.html
for a complete list.

30
docs/reference/COPYING Normal file
View file

@ -0,0 +1,30 @@
This work may be reproduced and distributed in whole or in part, in
any medium, physical or electronic, so as long as this copyright
notice remains intact and unchanged on all copies. Commercial
redistribution is permitted and encouraged, but you may not
redistribute, in whole or in part, under terms more restrictive than
those under which you received it. If you redistribute a modified or
translated version of this work, you must also make the source code to
the modified or translated version available in electronic form
without charge. However, mere aggregation as part of a larger work
shall not count as a modification for this purpose.
All code examples in this work are placed into the public domain,
and may be used, modified and redistributed without restriction.
BECAUSE THIS WORK IS LICENSED FREE OF CHARGE, THERE IS NO
WARRANTY FOR THE WORK, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
OTHER PARTIES PROVIDE THE WORK "AS IS" WITHOUT WARRANTY OF ANY
KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. SHOULD THE WORK PROVE DEFECTIVE, YOU ASSUME
THE COST OF ALL NECESSARY REPAIR OR CORRECTION.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY
AND/OR REDISTRIBUTE THE WORK AS PERMITTED ABOVE, BE LIABLE TO YOU
FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE
WORK, EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.

0
docs/reference/NEWS Normal file
View file

3
docs/reference/gio/.gitignore vendored Normal file
View file

@ -0,0 +1,3 @@
*.1
gio-overrides.txt
tmpl

View file

@ -0,0 +1,36 @@
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
# Copyright (C) 2018 Collabora Inc.
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# This library is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# Lesser General Public License for more details.
#
# You should have received a copy of the GNU Lesser General
# Public License along with this library; if not, see <http://www.gnu.org/licenses/>.
#
# Author: Xavier Claessens <xavier.claessens@collabora.com>
import os
import sys
if len(sys.argv) < 3:
print(
"Usage: {} <output file> <input file 1> ...".format(
os.path.basename(sys.argv[0])
)
)
sys.exit(1)
with open(sys.argv[1], "w") as outfile:
for fname in sys.argv[2:]:
with open(fname) as infile:
for line in infile:
outfile.write(line)

View file

@ -0,0 +1,352 @@
<refentry id="gapplication-tool" lang="en">
<refentryinfo>
<title>gapplication</title>
<productname>GIO</productname>
<authorgroup>
<author>
<contrib>Developer</contrib>
<firstname>Ryan</firstname>
<surname>Lortie</surname>
</author>
</authorgroup>
</refentryinfo>
<refmeta>
<refentrytitle>gapplication</refentrytitle>
<manvolnum>1</manvolnum>
<refmiscinfo class="manual">User Commands</refmiscinfo>
</refmeta>
<refnamediv>
<refname>gapplication</refname>
<refpurpose>D-Bus application launcher</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>gapplication</command>
<arg choice="plain">help</arg>
<arg choice="opt"><replaceable>COMMAND</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gapplication</command>
<arg choice="plain">version</arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gapplication</command>
<arg choice="plain">list-apps</arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gapplication</command>
<arg choice="plain">launch</arg>
<arg choice="plain"><replaceable>APPID</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gapplication</command>
<arg choice="plain">launch</arg>
<arg choice="plain"><replaceable>APPID</replaceable></arg>
<arg choice="opt" rep="repeat"><replaceable>FILE</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gapplication</command>
<arg choice="plain">list-actions</arg>
<arg choice="plain"><replaceable>APPID</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gapplication</command>
<arg choice="plain">action</arg>
<arg choice="plain"><replaceable>APPID</replaceable></arg>
<arg choice="plain"><replaceable>ACTION</replaceable></arg>
<arg choice="opt"><replaceable>PARAMETER</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>
<command>gapplication</command> is a commandline implementation of the client-side of the
<interfacename>org.freedesktop.Application</interfacename> interface as specified by the freedesktop.org
Desktop Entry Specification.
</para>
<para>
<command>gapplication</command> can be used to start applications that have
<varname>DBusActivatable</varname> set to <literal>true</literal> in their <filename>.desktop</filename>
files and can be used to send messages to already-running instances of other applications.
</para>
<para>
It is possible for applications to refer to <command>gapplication</command> in the <varname>Exec</varname>
line of their <filename class='extension'>.desktop</filename> file to maintain backwards compatibility
with implementations that do not directly support <varname>DBusActivatable</varname>.
</para>
<para>
<command>gapplication</command> ships as part of <application>GLib</application>.
</para>
</refsect1>
<refsect1>
<title>Commands</title>
<refsect2>
<title>Global commands</title>
<variablelist>
<varlistentry>
<term>
<command>help</command>
<arg choice="opt"><replaceable>COMMAND</replaceable></arg>
</term>
<listitem>
<para>
Displays a short synopsis of the available commands or provides detailed help on a specific
command.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>version</command>
</term>
<listitem>
<para>
Prints the GLib version whence <command>gapplication</command> came.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>list-apps</command>
</term>
<listitem>
<para>
Prints a list of all application IDs that are known to support D-Bus activation. This list is
generated by scanning <filename class='extension'>.desktop</filename> files as per the current
<envar>XDG_DATA_DIRS</envar>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>launch</command>
<arg choice="plain"><replaceable>APPID</replaceable></arg>
<arg choice="opt" rep="repeat"><replaceable>FILE</replaceable></arg>
</term>
<listitem>
<para>
Launches an application.
</para>
<para>
The first parameter is the application ID in the familiar "reverse DNS" style (eg:
'<literal>org.gnome.app</literal>') without the <filename class='extension'>.desktop</filename>
suffix.
</para>
<para>
Optionally, if additional parameters are given, they are treated as the names of files to open and
may be filenames or URIs. If no files are given then the application is simply activated.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>list-actions</command>
<arg choice="plain"><replaceable>APPID</replaceable></arg>
</term>
<listitem>
<para>
List the actions declared in the application's <filename class='extension'>.desktop</filename>
file. The parameter is the application ID, as above.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>action</command>
<arg choice="plain"><replaceable>APPID</replaceable></arg>
<arg choice="plain"><replaceable>ACTION</replaceable></arg>
<arg choice="opt"><replaceable>PARAMETER</replaceable></arg>
</term>
<listitem>
<para>
Invokes the named action (in the same way as would occur when activating an action specified in
the <filename class='extension'>.desktop</filename> file).
</para>
<para>
The application ID (as above) is the first parameter. The action name follows.
</para>
<para>
Optionally, following the action name can be one parameter, in GVariant format, given as a single
argument. Make sure to use sufficient quoting.
</para>
</listitem>
</varlistentry>
</variablelist>
</refsect2>
</refsect1>
<refsect1>
<title>Examples</title>
<refsect2>
<title>From the commandline</title>
<para>
Launching an application:
</para>
<programlisting>
gapplication launch org.example.fooview
</programlisting>
<para>
Opening a file with an application:
</para>
<programlisting>
gapplication launch org.example.fooview ~/file.foo
</programlisting>
<para>
Opening many files with an application:
</para>
<programlisting>
gapplication launch org.example.fooview ~/foos/*.foo
</programlisting>
<para>
Invoking an action on an application:
</para>
<programlisting>
gapplication action org.example.fooview create
</programlisting>
<para>
Invoking an action on an application, with an action:
</para>
<programlisting>
gapplication action org.example.fooview show-item '"item_id_828739"'
</programlisting>
</refsect2>
<refsect2>
<title>
From the <varname>Exec</varname> lines of a <filename class='extension'>.desktop</filename> file
</title>
<para>
The commandline interface of <command>gapplication</command> was designed so that it could be used
directly from the <varname>Exec</varname> line of a <filename class='extension'>.desktop</filename>
file.
</para>
<para>
You might want to do this to allow for backwards compatibility with implementations of the specification
that do not understand how to do D-Bus activation, without having to install a separate utility program.
</para>
<para>
Consider the following example:
</para>
<programlisting>
[Desktop Entry]
Version=1.1
Type=Application
Name=Foo Viewer
DBusActivatable=true
MimeType=image/x-foo;
Exec=gapplication launch org.example.fooview %F
Actions=gallery;create;
[Desktop Action gallery]
Name=Browse Gallery
Exec=gapplication action org.example.fooview gallery
[Desktop Action create]
Name=Create a new Foo!
Exec=gapplication action org.example.fooview create
</programlisting>
</refsect2>
<refsect2>
<title>From a script</title>
<para>
If installing an application that supports D-Bus activation you may still want to put a file in
<filename class='directory'>/usr/bin</filename> so that your program can be started from a terminal.
</para>
<para>
It is possible for this file to be a shell script. The script can handle arguments such as --help and
--version directly. It can also parse other command line arguments and convert them to uses of
<command>gapplication</command> to activate the application, open files, or invoke actions.
</para>
<para>
Here is a simplified example, as may be installed in <filename>/usr/bin/fooview</filename>:
</para>
<programlisting>
#!/bin/sh
case "$1" in
--help)
echo "see 'man fooview' for more information"
;;
--version)
echo "fooview 1.2"
;;
--gallery)
gapplication action org.example.fooview gallery
;;
--create)
gapplication action org.example.fooview create
;;
-*)
echo "unrecognised commandline argument"
exit 1
;;
*)
gapplication launch org.example.fooview "$@"
;;
esac
</programlisting>
</refsect2>
</refsect1>
<refsect1>
<title>See also</title>
<para>
<ulink url='http://standards.freedesktop.org/desktop-entry-spec/latest/'>Desktop Entry Specification</ulink>,
<citerefentry>
<refentrytitle>gdbus</refentrytitle>
<manvolnum>1</manvolnum>
</citerefentry>,
<citerefentry>
<refentrytitle>xdg-open</refentrytitle>
<manvolnum>1</manvolnum>
</citerefentry>,
<citerefentry>
<refentrytitle>desktop-file-validate</refentrytitle>
<manvolnum>1</manvolnum>
</citerefentry>
</para>
</refsect1>
</refentry>

File diff suppressed because it is too large Load diff

View file

@ -0,0 +1 @@
gdbus-object-manager-example-overrides.txt

View file

@ -0,0 +1,19 @@
<?xml version="1.0"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
<!ENTITY % local.common.attrib "xmlns:xi CDATA #FIXED 'http://www.w3.org/2003/XInclude'">
]>
<book lang="en" xmlns:xi="http://www.w3.org/2003/XInclude">
<part>
<title>GDBus ObjctManager Example</title>
<chapter>
<title>Interfaces</title>
<xi:include href="xml/ExampleAnimal.xml"/>
<xi:include href="xml/ExampleCat.xml"/>
<xi:include href="xml/ExampleObject.xml"/>
<xi:include href="xml/ExampleObjectManagerClient.xml"/>
</chapter>
</part>
<xi:include href="xml/annotation-glossary.xml"><xi:fallback /></xi:include>
</book>

View file

@ -0,0 +1,161 @@
<SECTION>
<FILE>ExampleAnimal</FILE>
<TITLE>ExampleAnimal</TITLE>
ExampleAnimal
ExampleAnimalIface
example_animal_interface_info
example_animal_override_properties
example_animal_call_poke
example_animal_call_poke_finish
example_animal_call_poke_sync
example_animal_complete_poke
example_animal_emit_jumped
example_animal_get_mood
example_animal_get_foo
example_animal_get_bar
example_animal_dup_mood
example_animal_dup_foo
example_animal_dup_bar
example_animal_set_mood
example_animal_set_foo
example_animal_set_bar
ExampleAnimalProxy
ExampleAnimalProxyClass
example_animal_proxy_new
example_animal_proxy_new_finish
example_animal_proxy_new_sync
example_animal_proxy_new_for_bus
example_animal_proxy_new_for_bus_finish
example_animal_proxy_new_for_bus_sync
ExampleAnimalSkeleton
ExampleAnimalSkeletonClass
example_animal_skeleton_new
<SUBSECTION Standard>
example_animal_get_type
example_animal_proxy_get_type
example_animal_skeleton_get_type
ExampleAnimalSkeletonPrivate
ExampleAnimalProxyPrivate
EXAMPLE_TYPE_ANIMAL
EXAMPLE_TYPE_ANIMAL_PROXY
EXAMPLE_TYPE_ANIMAL_SKELETON
EXAMPLE_ANIMAL
EXAMPLE_ANIMAL_GET_IFACE
EXAMPLE_ANIMAL_PROXY
EXAMPLE_ANIMAL_PROXY_CLASS
EXAMPLE_ANIMAL_PROXY_GET_CLASS
EXAMPLE_ANIMAL_SKELETON
EXAMPLE_ANIMAL_SKELETON_CLASS
EXAMPLE_ANIMAL_SKELETON_GET_CLASS
EXAMPLE_IS_ANIMAL
EXAMPLE_IS_ANIMAL_PROXY
EXAMPLE_IS_ANIMAL_PROXY_CLASS
EXAMPLE_IS_ANIMAL_SKELETON
EXAMPLE_IS_ANIMAL_SKELETON_CLASS
</SECTION>
<SECTION>
<FILE>ExampleCat</FILE>
<TITLE>ExampleCat</TITLE>
ExampleCat
ExampleCatIface
example_cat_interface_info
example_cat_override_properties
ExampleCatProxy
ExampleCatProxyClass
example_cat_proxy_new
example_cat_proxy_new_finish
example_cat_proxy_new_sync
example_cat_proxy_new_for_bus
example_cat_proxy_new_for_bus_finish
example_cat_proxy_new_for_bus_sync
ExampleCatSkeleton
ExampleCatSkeletonClass
example_cat_skeleton_new
<SUBSECTION Standard>
example_cat_get_type
example_cat_proxy_get_type
example_cat_skeleton_get_type
ExampleCatProxyPrivate
ExampleCatSkeletonPrivate
EXAMPLE_TYPE_CAT
EXAMPLE_TYPE_CAT_PROXY
EXAMPLE_TYPE_CAT_SKELETON
EXAMPLE_CAT
EXAMPLE_CAT_GET_IFACE
EXAMPLE_CAT_PROXY
EXAMPLE_CAT_PROXY_CLASS
EXAMPLE_CAT_PROXY_GET_CLASS
EXAMPLE_CAT_SKELETON
EXAMPLE_CAT_SKELETON_CLASS
EXAMPLE_CAT_SKELETON_GET_CLASS
EXAMPLE_IS_CAT
EXAMPLE_IS_CAT_PROXY
EXAMPLE_IS_CAT_PROXY_CLASS
EXAMPLE_IS_CAT_SKELETON
EXAMPLE_IS_CAT_SKELETON_CLASS
</SECTION>
<SECTION>
<FILE>ExampleObject</FILE>
<TITLE>ExampleObject</TITLE>
ExampleObject
ExampleObjectIface
example_object_get_animal
example_object_get_cat
example_object_peek_animal
example_object_peek_cat
ExampleObjectProxy
ExampleObjectProxyClass
example_object_proxy_new
ExampleObjectSkeleton
ExampleObjectSkeletonClass
example_object_skeleton_new
example_object_skeleton_set_animal
example_object_skeleton_set_cat
<SUBSECTION Standard>
example_object_get_type
example_object_proxy_get_type
example_object_skeleton_get_type
ExampleObjectProxyPrivate
ExampleObjectSkeletonPrivate
EXAMPLE_IS_OBJECT
EXAMPLE_IS_OBJECT_PROXY
EXAMPLE_IS_OBJECT_PROXY_CLASS
EXAMPLE_IS_OBJECT_SKELETON
EXAMPLE_IS_OBJECT_SKELETON_CLASS
EXAMPLE_OBJECT
EXAMPLE_OBJECT_GET_IFACE
EXAMPLE_OBJECT_PROXY
EXAMPLE_OBJECT_PROXY_CLASS
EXAMPLE_OBJECT_PROXY_GET_CLASS
EXAMPLE_OBJECT_SKELETON
EXAMPLE_OBJECT_SKELETON_CLASS
EXAMPLE_OBJECT_SKELETON_GET_CLASS
EXAMPLE_TYPE_OBJECT
EXAMPLE_TYPE_OBJECT_PROXY
EXAMPLE_TYPE_OBJECT_SKELETON
</SECTION>
<SECTION>
<FILE>ExampleObjectManagerClient</FILE>
<TITLE>ExampleObjectManagerClient</TITLE>
ExampleObjectManagerClient
ExampleObjectManagerClientClass
example_object_manager_client_get_proxy_type
example_object_manager_client_new
example_object_manager_client_new_finish
example_object_manager_client_new_sync
example_object_manager_client_new_for_bus
example_object_manager_client_new_for_bus_finish
example_object_manager_client_new_for_bus_sync
<SUBSECTION Standard>
example_object_manager_client_get_type
EXAMPLE_IS_OBJECT_MANAGER_CLIENT
EXAMPLE_IS_OBJECT_MANAGER_CLIENT_CLASS
EXAMPLE_OBJECT_MANAGER_CLIENT
EXAMPLE_OBJECT_MANAGER_CLIENT_CLASS
EXAMPLE_OBJECT_MANAGER_CLIENT_GET_CLASS
EXAMPLE_TYPE_OBJECT_MANAGER_CLIENT
ExampleObjectManagerClientPrivate
</SECTION>

View file

@ -0,0 +1,11 @@
gdbus_object_manager_example_doc = gnome.gtkdoc('gdbus-object-manager-example',
main_xml : 'gdbus-object-manager-example-docs.xml',
namespace : 'example',
dependencies : [libgdbus_example_objectmanager_dep],
src_dir : 'gio/tests/gdbus-object-manager-example',
scan_args : gtkdoc_common_scan_args + [
'--rebuild-types',
],
install : false,
)

View file

@ -0,0 +1,429 @@
<refentry id="gdbus" lang="en">
<refentryinfo>
<title>gdbus</title>
<productname>GIO</productname>
<authorgroup>
<author>
<contrib>Developer</contrib>
<firstname>David</firstname>
<surname>Zeuthen</surname>
<email>zeuthen@gmail.com</email>
</author>
</authorgroup>
</refentryinfo>
<refmeta>
<refentrytitle>gdbus</refentrytitle>
<manvolnum>1</manvolnum>
<refmiscinfo class="manual">User Commands</refmiscinfo>
</refmeta>
<refnamediv>
<refname>gdbus</refname>
<refpurpose>Tool for working with D-Bus objects</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>gdbus</command>
<arg choice="plain">introspect</arg>
<group>
<arg choice="plain">--system</arg>
<arg choice="plain">--session</arg>
<arg choice="plain">--address <replaceable>address</replaceable></arg>
</group>
<arg choice="plain">--dest <replaceable>bus_name</replaceable></arg>
<arg choice="plain">--object-path <replaceable>/path/to/object</replaceable></arg>
<group>
<arg choice="plain">--xml</arg>
</group>
<group>
<arg choice="plain">--recurse</arg>
</group>
<group>
<arg choice="plain">--only-properties</arg>
</group>
</cmdsynopsis>
<cmdsynopsis>
<command>gdbus</command>
<arg choice="plain">monitor</arg>
<group>
<arg choice="plain">--system</arg>
<arg choice="plain">--session</arg>
<arg choice="plain">--address <replaceable>address</replaceable></arg>
</group>
<arg choice="plain">--dest <replaceable>bus_name</replaceable></arg>
<group>
<arg choice="plain">--object-path <replaceable>/path/to/object</replaceable></arg>
</group>
</cmdsynopsis>
<cmdsynopsis>
<command>gdbus</command>
<arg choice="plain">call</arg>
<group>
<arg choice="plain">--system</arg>
<arg choice="plain">--session</arg>
<arg choice="plain">--address <replaceable>address</replaceable></arg>
</group>
<arg choice="plain">--dest <replaceable>bus_name</replaceable></arg>
<arg choice="plain">--object-path <replaceable>/path/to/object</replaceable></arg>
<arg choice="plain">--method <replaceable>org.project.InterfaceName.MethodName</replaceable></arg>
<group>
<arg choice="plain">--timeout <replaceable>seconds</replaceable></arg>
<arg choice="plain">--interactive</arg>
</group>
<arg choice="plain">ARG1</arg>
<arg choice="plain" rep="repeat">ARG2</arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gdbus</command>
<arg choice="plain">emit</arg>
<group>
<arg choice="plain">--system</arg>
<arg choice="plain">--session</arg>
<arg choice="plain">--address <replaceable>address</replaceable></arg>
</group>
<arg choice="plain">--object-path <replaceable>/path/to/object</replaceable></arg>
<arg choice="plain">--signal <replaceable>org.project.InterfaceName.SignalName</replaceable></arg>
<group>
<arg choice="plain">--dest <replaceable>unique_bus_name</replaceable></arg>
</group>
<arg choice="plain">ARG1</arg>
<arg choice="plain" rep="repeat">ARG2</arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gdbus</command>
<arg choice="plain">wait</arg>
<group>
<arg choice="plain">--system</arg>
<arg choice="plain">--session</arg>
<arg choice="plain">--address <replaceable>address</replaceable></arg>
</group>
<arg choice="plain">--activate <replaceable>bus_name</replaceable></arg>
<group>
<arg choice="plain">--timeout <replaceable>seconds</replaceable></arg>
</group>
<arg choice="plain"><replaceable>bus_name</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gdbus</command>
<arg choice="plain">help</arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>
<command>gdbus</command> is a simple tool for working with D-Bus objects.
</para>
</refsect1>
<refsect1>
<title>Commands</title>
<variablelist>
<varlistentry>
<term><option>introspect</option></term>
<listitem><para>
Prints out interfaces and property values for a remote object.
For this to work, the owner of the object needs to implement the
<literal>org.freedesktop.DBus.Introspectable</literal> interface.
If the <option>--xml</option> option is used, the returned
introspection XML is printed, otherwise a parsed pretty
representation is printed.
The <option>--recurse</option> option can be used to
introspect children (and their children and so on) and the
<option>--only-properties</option> option can be used to
only print the interfaces with properties.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>monitor</option></term>
<listitem><para>
Monitors one or all objects owned by the owner of
<replaceable>bus_name</replaceable>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>call</option></term>
<listitem><para>
Invokes a method on a remote object. Each argument to pass to the
method must be specified as a serialized
<link linkend="GVariant"><type>GVariant</type></link> except that strings do
not need explicit quotes. The return values are printed out as
serialized <link linkend="GVariant"><type>GVariant</type></link>
values.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>emit</option></term>
<listitem><para>
Emits a signal. Each argument to include in the signal must be specified as a serialized
<link linkend="GVariant"><type>GVariant</type></link> except that strings do
not need explicit quotes.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>wait</option></term>
<listitem><para>
Waits until <replaceable>bus_name</replaceable> is owned by some
process on the bus. If the <option>--activate</option> is specified,
that bus name will be auto-started first. It may be the same as the
bus name being waited for, or different.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>help</option></term>
<listitem><para>
Prints help and exit.
</para></listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Bash Completion</title>
<para>
<command>gdbus</command> ships with a bash completion script to
complete commands, destinations, bus names, object paths and
interface/method names.
</para>
</refsect1>
<refsect1>
<title>Examples</title>
This shows how to introspect an object - note that the value of each
property is displayed:
<programlisting>
$ gdbus introspect --system \
--dest org.freedesktop.NetworkManager \
--object-path /org/freedesktop/NetworkManager/Devices/0
node /org/freedesktop/NetworkManager/Devices/0 {
interface org.freedesktop.DBus.Introspectable {
methods:
Introspect(out s data);
};
interface org.freedesktop.DBus.Properties {
methods:
Get(in s interface,
in s propname,
out v value);
Set(in s interface,
in s propname,
in v value);
GetAll(in s interface,
out a{sv} props);
};
interface org.freedesktop.NetworkManager.Device.Wired {
signals:
PropertiesChanged(a{sv} arg_0);
properties:
readonly b Carrier = false;
readonly u Speed = 0;
readonly s HwAddress = '00:1D:72:88:BE:97';
};
interface org.freedesktop.NetworkManager.Device {
methods:
Disconnect();
signals:
StateChanged(u arg_0,
u arg_1,
u arg_2);
properties:
readonly u DeviceType = 1;
readonly b Managed = true;
readwrite o Ip6Config = '/';
readwrite o Dhcp4Config = '/';
readwrite o Ip4Config = '/';
readonly u State = 2;
readwrite u Ip4Address = 0;
readonly u Capabilities = 3;
readonly s Driver = 'e1000e';
readwrite s Interface = 'eth0';
readonly s Udi = '/sys/devices/pci0000:00/0000:00:19.0/net/eth0';
};
};
</programlisting>
<para>
The <option>--recurse</option> and <option>--only-properties</option> options can be useful when wanting to inspect all objects owned by a particular process:
</para>
<programlisting>
$ gdbus introspect --system --dest org.freedesktop.UPower --object-path / --recurse --only-properties
node / {
node /org {
node /org/freedesktop {
node /org/freedesktop/UPower {
interface org.freedesktop.UPower {
properties:
readonly b IsDocked = true;
readonly b LidForceSleep = false;
readonly b LidIsPresent = false;
readonly b LidIsClosed = false;
readonly b OnLowBattery = false;
readonly b OnBattery = false;
readonly b CanHibernate = true;
readonly b CanSuspend = true;
readonly s DaemonVersion = '0.9.10';
};
node /org/freedesktop/UPower/Policy {
};
node /org/freedesktop/UPower/Wakeups {
interface org.freedesktop.UPower.Wakeups {
properties:
readonly b HasCapability = true;
};
};
};
};
};
};
</programlisting>
<para>
In a similar fashion, the <option>introspect</option> command can be
used to learn details about the <literal>Notify</literal> method:
</para>
<programlisting>
[...]
interface org.freedesktop.Notifications {
methods:
GetServerInformation(out s return_name,
out s return_vendor,
out s return_version,
out s return_spec_version);
GetCapabilities(out as return_caps);
CloseNotification(in u id);
Notify(in s app_name,
in u id,
in s icon,
in s summary,
in s body,
in as actions,
in a{sv} hints,
in i timeout,
out u return_id);
};
[...]
</programlisting>
<para>
With this information, it's easy to use the <option>call</option>
command to display a notification
</para>
<programlisting>
$ gdbus call --session \
--dest org.freedesktop.Notifications \
--object-path /org/freedesktop/Notifications \
--method org.freedesktop.Notifications.Notify \
my_app_name \
42 \
gtk-dialog-info \
"The Summary" \
"Here's the body of the notification" \
[] \
{} \
5000
(uint32 12,)
</programlisting>
<para>
Call a method with file handle argument:
</para>
<programlisting>
$ gdbus call --session \
--dest org.example.foo \
--object-path /org/example/foo \
--method SendFDs \
1 \
10 \
10&lt;file.foo
</programlisting>
<para>
Monitoring all objects on a service:
</para>
<programlisting>
$ gdbus monitor --system --dest org.freedesktop.ConsoleKit
Monitoring signals from all objects owned by org.freedesktop.ConsoleKit
The name org.freedesktop.ConsoleKit is owned by :1.15
/org/freedesktop/ConsoleKit/Session2: org.freedesktop.ConsoleKit.Session.ActiveChanged (false,)
/org/freedesktop/ConsoleKit/Seat1: org.freedesktop.ConsoleKit.Seat.ActiveSessionChanged ('',)
/org/freedesktop/ConsoleKit/Session2: org.freedesktop.ConsoleKit.Session.ActiveChanged (true,)
/org/freedesktop/ConsoleKit/Seat1: org.freedesktop.ConsoleKit.Seat.ActiveSessionChanged ('/org/freedesktop/ConsoleKit/Session2',)
</programlisting>
<para>
Monitoring a single object on a service:
</para>
<programlisting>
$ gdbus monitor --system --dest org.freedesktop.NetworkManager --object-path /org/freedesktop/NetworkManager/AccessPoint/4141
Monitoring signals on object /org/freedesktop/NetworkManager/AccessPoint/4141 owned by org.freedesktop.NetworkManager
The name org.freedesktop.NetworkManager is owned by :1.5
/org/freedesktop/NetworkManager/AccessPoint/4141: org.freedesktop.NetworkManager.AccessPoint.PropertiesChanged ({'Strength': &lt;byte 0x5c&gt;},)
/org/freedesktop/NetworkManager/AccessPoint/4141: org.freedesktop.NetworkManager.AccessPoint.PropertiesChanged ({'Strength': &lt;byte 0x64&gt;},)
/org/freedesktop/NetworkManager/AccessPoint/4141: org.freedesktop.NetworkManager.AccessPoint.PropertiesChanged ({'Strength': &lt;byte 0x5e&gt;},)
/org/freedesktop/NetworkManager/AccessPoint/4141: org.freedesktop.NetworkManager.AccessPoint.PropertiesChanged ({'Strength': &lt;byte 0x64&gt;},)
</programlisting>
<para>
Emitting a signal:
</para>
<programlisting>
$ gdbus emit --session --object-path /foo --signal org.bar.Foo "['foo', 'bar', 'baz']"
</programlisting>
<para>
Emitting a signal to a specific process:
</para>
<programlisting>
$ gdbus emit --session --object-path /bar --signal org.bar.Bar someString --dest :1.42
</programlisting>
<para>
Waiting for a well-known name to be owned on the bus; this will
<emphasis>not</emphasis> auto-start the service:
</para>
<programlisting>
$ gdbus wait --session org.bar.SomeName
</programlisting>
<para>
Auto-starting then waiting for a well-known name to be owned on the bus:
</para>
<programlisting>
$ gdbus wait --session --activate org.bar.SomeName
</programlisting>
<para>
Auto-starting a different service, then waiting for a well-known name to be
owned on the bus. This is useful in situations where
<replaceable>SomeName</replaceable> is not directly activatable:
</para>
<programlisting>
$ gdbus wait --session --activate org.bar.PrerequisiteName org.bar.SomeName
</programlisting>
<para>
Waiting for a well-known name and giving up after 30 seconds. By default,
the timeout is disabled; or set <option>--timeout</option> to 0 to disable it:
</para>
<programlisting>
$ gdbus wait --session --timeout 30 org.bar.SomeName
</programlisting>
</refsect1>
<refsect1>
<title>Bugs</title>
<para>
Please send bug reports to either the distribution bug tracker
or the upstream bug tracker at
<ulink url="https://gitlab.gnome.org/GNOME/glib/issues/new"/>.
</para>
</refsect1>
<refsect1>
<title>See Also</title>
<para>
<citerefentry>
<refentrytitle>dbus-send</refentrytitle><manvolnum>1</manvolnum>
</citerefentry>
</para>
</refsect1>
</refentry>

View file

@ -0,0 +1,3 @@
<chapter id='unix-support'>
<!--FIXME: fill this with unix APIs that cannot build on Windows -->
</chapter>

View file

@ -0,0 +1,6 @@
<chapter id='win32-support'>
<title>Win32 support</title>
<xi:include href="xml/gwin32registrykey.xml"/>
<xi:include href="xml/gwin32inputstream.xml"/>
<xi:include href="xml/gwin32outputstream.xml"/>
</chapter>

View file

@ -0,0 +1,406 @@
<?xml version="1.0"?>
<!DOCTYPE book PUBLIC '-//OASIS//DTD DocBook XML V4.5//EN'
'http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd' [
<!ENTITY % local.common.attrib "xmlns:xi CDATA #FIXED 'http://www.w3.org/2003/XInclude'">
<!ENTITY version SYSTEM "version.xml">
]>
<book lang="en" id="gio" xmlns:xi="http://www.w3.org/2003/XInclude">
<title>GIO Reference Manual</title>
<bookinfo>
<title>GIO Reference Manual</title>
<releaseinfo>
for GIO &version;
The latest version of this documentation can be found on-line at
<ulink role="online-location" url="https://developer.gnome.org/gio/unstable/">https://developer.gnome.org/gio/unstable/</ulink>.
</releaseinfo>
</bookinfo>
<xi:include href="xml/overview.xml"/>
<part>
<title>API Reference</title>
<chapter id="file_ops">
<title>File Operations</title>
<xi:include href="xml/gfile.xml"/>
<xi:include href="xml/gfileattribute.xml"/>
<xi:include href="xml/gfileinfo.xml"/>
<xi:include href="xml/gfileenumerator.xml"/>
<xi:include href="xml/gioerror.xml"/>
<xi:include href="xml/gmountoperation.xml"/>
</chapter>
<chapter id="file_mon">
<title>File System Monitoring</title>
<xi:include href="xml/gfilemonitor.xml"/>
</chapter>
<chapter id="utils">
<title>File-related Utilities</title>
<xi:include href="xml/gfilenamecompleter.xml"/>
</chapter>
<chapter id="async">
<title>Asynchronous I/O</title>
<xi:include href="xml/gcancellable.xml"/>
<xi:include href="xml/gasyncresult.xml"/>
<xi:include href="xml/gtask.xml"/>
<xi:include href="xml/gioscheduler.xml"/>
<xi:include href="xml/gsimpleasyncresult.xml"/>
</chapter>
<chapter id="conversion">
<title>Data conversion</title>
<xi:include href="xml/gconverter.xml"/>
<xi:include href="xml/gcharsetconverter.xml"/>
<xi:include href="xml/gzlibcompressor.xml"/>
<xi:include href="xml/gzlibdecompressor.xml"/>
</chapter>
<chapter id="streaming">
<title>Streaming I/O</title>
<xi:include href="xml/gseekable.xml"/>
<xi:include href="xml/ginputstream.xml"/>
<xi:include href="xml/goutputstream.xml"/>
<xi:include href="xml/giostream.xml"/>
<xi:include href="xml/gsimpleiostream.xml"/>
<xi:include href="xml/gfileinputstream.xml"/>
<xi:include href="xml/gfileoutputstream.xml"/>
<xi:include href="xml/gfileiostream.xml"/>
<xi:include href="xml/gfiledescriptorbased.xml"/>
<xi:include href="xml/gfilterinputstream.xml"/>
<xi:include href="xml/gfilteroutputstream.xml"/>
<xi:include href="xml/gmemoryinputstream.xml"/>
<xi:include href="xml/gmemoryoutputstream.xml"/>
<xi:include href="xml/gbufferedinputstream.xml"/>
<xi:include href="xml/gbufferedoutputstream.xml"/>
<xi:include href="xml/gdatainputstream.xml"/>
<xi:include href="xml/gdataoutputstream.xml"/>
<xi:include href="xml/gunixinputstream.xml"/>
<xi:include href="xml/gunixoutputstream.xml"/>
<xi:include href="xml/gconverterinputstream.xml"/>
<xi:include href="xml/gconverteroutputstream.xml"/>
<xi:include href="xml/gpollableinputstream.xml"/>
<xi:include href="xml/gpollableoutputstream.xml"/>
<xi:include href="xml/gpollableutils.xml"/>
</chapter>
<chapter id="types">
<title>File types and applications</title>
<xi:include href="xml/gcontenttype.xml"/>
<xi:include href="xml/gappinfo.xml"/>
<xi:include href="xml/gappinfomonitor.xml"/>
<xi:include href="xml/gdesktopappinfo.xml"/>
</chapter>
<chapter id="volume_mon">
<title>Volumes and Drives</title>
<xi:include href="xml/gvolumemonitor.xml"/>
<xi:include href="xml/gvolume.xml"/>
<xi:include href="xml/gmount.xml"/>
<xi:include href="xml/gdrive.xml"/>
<xi:include href="xml/gunixmounts.xml"/>
</chapter>
<chapter id="icons">
<title>Icons</title>
<xi:include href="xml/gicon.xml"/>
<xi:include href="xml/gfileicon.xml"/>
<xi:include href="xml/gbytesicon.xml"/>
<xi:include href="xml/gloadableicon.xml"/>
<xi:include href="xml/gthemedicon.xml"/>
<xi:include href="xml/gemblemedicon.xml"/>
<xi:include href="xml/gemblem.xml"/>
</chapter>
<chapter id="failable_initialization">
<title>Failable Initialization</title>
<xi:include href="xml/ginitable.xml"/>
<xi:include href="xml/gasyncinitable.xml"/>
</chapter>
<chapter id="subprocesses">
<title>Subprocesses</title>
<xi:include href="xml/gsubprocess.xml"/>
<xi:include href="xml/gsubprocesslauncher.xml"/>
</chapter>
<chapter id="networking">
<title>Low-level network support</title>
<xi:include href="xml/gsocket.xml"/>
<xi:include href="xml/gdatagrambased.xml"/>
<xi:include href="xml/ginetaddress.xml"/>
<xi:include href="xml/ginetaddressmask.xml"/>
<xi:include href="xml/gsocketaddress.xml"/>
<xi:include href="xml/ginetsocketaddress.xml"/>
<xi:include href="xml/gunixsocketaddress.xml"/>
<xi:include href="xml/gnativesocketaddress.xml"/>
<xi:include href="xml/gsocketcontrolmessage.xml"/>
<xi:include href="xml/gunixfdlist.xml"/>
<xi:include href="xml/gunixfdmessage.xml"/>
<xi:include href="xml/gcredentials.xml"/>
<xi:include href="xml/gunixcredentialsmessage.xml"/>
<xi:include href="xml/gproxy.xml"/>
<xi:include href="xml/gproxyaddress.xml"/>
<xi:include href="xml/gnetworking.xml"/>
</chapter>
<chapter id="highlevel-socket">
<title>High-level network functionality</title>
<xi:include href="xml/gsocketclient.xml"/>
<xi:include href="xml/gsocketconnection.xml"/>
<xi:include href="xml/gunixconnection.xml"/>
<xi:include href="xml/gtcpconnection.xml"/>
<xi:include href="xml/gtcpwrapperconnection.xml"/>
<xi:include href="xml/gsocketlistener.xml"/>
<xi:include href="xml/gsocketservice.xml"/>
<xi:include href="xml/gthreadedsocketservice.xml"/>
<xi:include href="xml/gnetworkmonitor.xml"/>
</chapter>
<chapter id="tls">
<title>TLS (SSL) support</title>
<xi:include href="xml/gtls.xml"/>
<xi:include href="xml/gtlscertificate.xml"/>
<xi:include href="xml/gtlsconnection.xml"/>
<xi:include href="xml/gtlsclientconnection.xml"/>
<xi:include href="xml/gtlsserverconnection.xml"/>
<xi:include href="xml/gdtlsconnection.xml"/>
<xi:include href="xml/gdtlsclientconnection.xml"/>
<xi:include href="xml/gdtlsserverconnection.xml"/>
<xi:include href="xml/gtlsbackend.xml"/>
<xi:include href="xml/gtlsdatabase.xml"/>
<xi:include href="xml/gtlsfiledatabase.xml"/>
<xi:include href="xml/gtlsinteraction.xml"/>
<xi:include href="xml/gtlspassword.xml"/>
</chapter>
<chapter id="resolver">
<title>DNS resolution</title>
<xi:include href="xml/gresolver.xml"/>
<xi:include href="xml/gproxyresolver.xml"/>
<xi:include href="xml/gsimpleproxyresolver.xml"/>
<xi:include href="xml/gsocketconnectable.xml"/>
<xi:include href="xml/gsocketaddressenumerator.xml"/>
<xi:include href="xml/gproxyaddressenumerator.xml"/>
<xi:include href="xml/gnetworkaddress.xml"/>
<xi:include href="xml/gnetworkservice.xml"/>
<xi:include href="xml/gsrvtarget.xml"/>
</chapter>
<chapter id="gdbus-lowlevel">
<title>Low-level D-Bus Support</title>
<xi:include href="xml/gdbusutils.xml"/>
<xi:include href="xml/gdbusaddress.xml"/>
<xi:include href="xml/gdbusintrospection.xml"/>
<xi:include href="xml/gdbuserror.xml"/>
<xi:include href="xml/gdbusmessage.xml"/>
<xi:include href="xml/gdbusconnection.xml"/>
<xi:include href="xml/gdbusmethodinvocation.xml"/>
<xi:include href="xml/gdbusserver.xml"/>
<xi:include href="xml/gdbusauthobserver.xml"/>
</chapter>
<chapter id="gdbus-convenience">
<title>High-level D-Bus Support</title>
<xi:include href="xml/gdbusnameowning.xml"/>
<xi:include href="xml/gdbusnamewatching.xml"/>
<xi:include href="xml/gdbusinterface.xml"/>
<xi:include href="xml/gdbusinterfaceskeleton.xml"/>
<xi:include href="xml/gdbusproxy.xml"/>
<xi:include href="xml/gdbusobject.xml"/>
<xi:include href="xml/gdbusobjectskeleton.xml"/>
<xi:include href="xml/gdbusobjectproxy.xml"/>
<xi:include href="xml/gdbusobjectmanager.xml"/>
<xi:include href="xml/gdbusobjectmanagerserver.xml"/>
<xi:include href="xml/gdbusobjectmanagerclient.xml"/>
</chapter>
<chapter id="settings">
<title>Settings</title>
<xi:include href="xml/gsettings.xml"/>
<xi:include href="xml/gsettingsbackend.xml"/>
<xi:include href="xml/gsettingsschema.xml"/>
</chapter>
<chapter id="resources">
<title>Resources</title>
<xi:include href="xml/gresource.xml"/>
</chapter>
<chapter id='permissions'>
<title>Permissions</title>
<xi:include href="xml/gpermission.xml"/>
<xi:include href="xml/gsimplepermission.xml"/>
</chapter>
<chapter id='data-models'>
<title>Data Models</title>
<xi:include href="xml/glistmodel.xml"/>
<xi:include href="xml/gliststore.xml"/>
</chapter>
<chapter id="application">
<title>Application support</title>
<xi:include href="xml/gapplication.xml"/>
<xi:include href="xml/gapplicationcommandline.xml"/>
<xi:include href="xml/gactiongroup.xml"/>
<xi:include href="xml/gactionmap.xml"/>
<xi:include href="xml/gsimpleactiongroup.xml"/>
<xi:include href="xml/gaction.xml"/>
<xi:include href="xml/gsimpleaction.xml"/>
<xi:include href="xml/gpropertyaction.xml"/>
<xi:include href="xml/gremoteactiongroup.xml"/>
<xi:include href="xml/gactiongroupexporter.xml"/>
<xi:include href="xml/gdbusactiongroup.xml"/>
<xi:include href="xml/gdebugcontroller.xml"/>
<xi:include href="xml/gdebugcontrollerdbus.xml"/>
<xi:include href="xml/gmemorymonitor.xml"/>
<xi:include href="xml/gmenumodel.xml"/>
<xi:include href="xml/gmenu.xml"/>
<xi:include href="xml/gmenuexporter.xml"/>
<xi:include href="xml/gdbusmenumodel.xml"/>
<xi:include href="xml/gnotification.xml"/>
<xi:include href="xml/gpowerprofilemonitor.xml"/>
</chapter>
<chapter id="extending">
<title>Extending GIO</title>
<xi:include href="xml/gvfs.xml"/>
<xi:include href="xml/giomodule.xml"/>
<xi:include href="xml/extensionpoints.xml"/>
</chapter>
<chapter id="tools">
<title>GIO Tools</title>
<xi:include href="gio-querymodules.xml"/>
<xi:include href="gsettings.xml"/>
<xi:include href="glib-compile-schemas.xml"/>
<xi:include href="glib-compile-resources.xml"/>
<xi:include href="gdbus.xml"/>
<xi:include href="xml/gdbus-codegen.xml"/>
<xi:include href="gresource.xml"/>
<xi:include href="gapplication.xml"/>
<xi:include href="gio.xml"/>
</chapter>
<chapter id="testing">
<title>GIO Testing</title>
<xi:include href="xml/gtestdbus.xml"/>
</chapter>
<xi:include href="gio-docs-platform.xml"/>
</part>
<part id="migrating">
<title>Migrating to GIO</title>
<xi:include href="xml/migrating-posix.xml"/>
<xi:include href="xml/migrating-gnome-vfs.xml"/>
<xi:include href="xml/migrating-gconf.xml"/>
<xi:include href="xml/migrating-gdbus.xml"/>
</part>
<chapter id="gio-hierarchy">
<title>Object Hierarchy</title>
<xi:include href="xml/tree_index.sgml"/>
</chapter>
<index id="api-index-full">
<title id="index-all">Index</title>
<xi:include href="xml/api-index-full.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-deprecated" role="deprecated">
<title>Index of deprecated symbols</title>
<xi:include href="xml/api-index-deprecated.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-18" role="2.18">
<title>Index of new symbols in 2.18</title>
<xi:include href="xml/api-index-2.18.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-20" role="2.20">
<title>Index of new symbols in 2.20</title>
<xi:include href="xml/api-index-2.20.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-22" role="2.22">
<title>Index of new symbols in 2.22</title>
<xi:include href="xml/api-index-2.22.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-24" role="2.24">
<title>Index of new symbols in 2.24</title>
<xi:include href="xml/api-index-2.24.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-26" role="2.26">
<title>Index of new symbols in 2.26</title>
<xi:include href="xml/api-index-2.26.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-28" role="2.28">
<title>Index of new symbols in 2.28</title>
<xi:include href="xml/api-index-2.28.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-30" role="2.30">
<title>Index of new symbols in 2.30</title>
<xi:include href="xml/api-index-2.30.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-32" role="2.32">
<title>Index of new symbols in 2.32</title>
<xi:include href="xml/api-index-2.32.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-34" role="2.34">
<title>Index of new symbols in 2.34</title>
<xi:include href="xml/api-index-2.34.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-36" role="2.36">
<title>Index of new symbols in 2.36</title>
<xi:include href="xml/api-index-2.36.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-38" role="2.38">
<title>Index of new symbols in 2.38</title>
<xi:include href="xml/api-index-2.38.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-40" role="2.40">
<title>Index of new symbols in 2.40</title>
<xi:include href="xml/api-index-2.40.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-42" role="2.42">
<title>Index of new symbols in 2.42</title>
<xi:include href="xml/api-index-2.42.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-44" role="2.44">
<title>Index of new symbols in 2.44</title>
<xi:include href="xml/api-index-2.44.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-46" role="2.46">
<title>Index of new symbols in 2.46</title>
<xi:include href="xml/api-index-2.46.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-48" role="2.48">
<title>Index of new symbols in 2.48</title>
<xi:include href="xml/api-index-2.48.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-50" role="2.50">
<title>Index of new symbols in 2.50</title>
<xi:include href="xml/api-index-2.50.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-52" role="2.52">
<title>Index of new symbols in 2.52</title>
<xi:include href="xml/api-index-2.52.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-54" role="2.54">
<title>Index of new symbols in 2.54</title>
<xi:include href="xml/api-index-2.54.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-56" role="2.56">
<title>Index of new symbols in 2.56</title>
<xi:include href="xml/api-index-2.56.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-58" role="2.58">
<title>Index of new symbols in 2.58</title>
<xi:include href="xml/api-index-2.58.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-60" role="2.60">
<title>Index of new symbols in 2.60</title>
<xi:include href="xml/api-index-2.60.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-62" role="2.62">
<title>Index of new symbols in 2.62</title>
<xi:include href="xml/api-index-2.62.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-64" role="2.64">
<title>Index of new symbols in 2.64</title>
<xi:include href="xml/api-index-2.64.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-66" role="2.66">
<title>Index of new symbols in 2.66</title>
<xi:include href="xml/api-index-2.66.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-68" role="2.68">
<title>Index of new symbols in 2.68</title>
<xi:include href="xml/api-index-2.68.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-70" role="2.70">
<title>Index of new symbols in 2.70</title>
<xi:include href="xml/api-index-2.70.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-72" role="2.72">
<title>Index of new symbols in 2.72</title>
<xi:include href="xml/api-index-2.72.xml"><xi:fallback /></xi:include>
</index>
<xi:include href="xml/annotation-glossary.xml"><xi:fallback /></xi:include>
</book>

View file

@ -0,0 +1,45 @@
<refentry id="gio-querymodules" lang="en">
<refentryinfo>
<title>glib-compile-schemas</title>
<productname>GIO</productname>
<authorgroup>
<author>
<contrib>Developer</contrib>
<firstname>Alexander</firstname>
<surname>Larsson</surname>
</author>
</authorgroup>
</refentryinfo>
<refmeta>
<refentrytitle>gio-querymodules</refentrytitle>
<manvolnum>1</manvolnum>
<refmiscinfo class="manual">User Commands</refmiscinfo>
</refmeta>
<refnamediv>
<refname>gio-querymodules</refname>
<refpurpose>GIO module cache creation</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>gio-querymodules</command>
<arg choice="req" rep="repeat">DIRECTORY</arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1><title>Description</title>
<para><command>gio-querymodules</command> creates a
<filename>giomodule.cache</filename> file in the listed directories.
This file lists the implemented extension points for each module
that has been found. It is used by GIO at runtime to avoid opening
all modules just to find out which extension points they are implementing.
</para>
<para>
GIO modules are usually installed in the <filename>gio/modules</filename>
subdirectory of libdir.
</para>
</refsect1>
</refentry>

File diff suppressed because it is too large Load diff

View file

@ -0,0 +1,112 @@
<SECTION>
<FILE>gwin32inputstream</FILE>
<TITLE>GWin32InputStream</TITLE>
GWin32InputStream
g_win32_input_stream_new
g_win32_input_stream_set_close_handle
g_win32_input_stream_get_close_handle
g_win32_input_stream_get_handle
<SUBSECTION Standard>
GWin32InputStreamClass
G_WIN32_INPUT_STREAM
G_IS_WIN32_INPUT_STREAM
G_TYPE_WIN32_INPUT_STREAM
G_WIN32_INPUT_STREAM_CLASS
G_IS_WIN32_INPUT_STREAM_CLASS
G_WIN32_INPUT_STREAM_GET_CLASS
<SUBSECTION Private>
g_win32_input_stream_get_type
GWin32InputStreamPrivate
</SECTION>
<SECTION>
<FILE>gwin32outputstream</FILE>
<TITLE>GWin32OutputStream</TITLE>
GWin32OutputStream
g_win32_output_stream_new
g_win32_output_stream_set_close_handle
g_win32_output_stream_get_close_handle
g_win32_output_stream_get_handle
<SUBSECTION Standard>
GWin32OutputStreamClass
G_WIN32_OUTPUT_STREAM
G_IS_WIN32_OUTPUT_STREAM
G_TYPE_WIN32_OUTPUT_STREAM
G_WIN32_OUTPUT_STREAM_CLASS
G_IS_WIN32_OUTPUT_STREAM_CLASS
G_WIN32_OUTPUT_STREAM_GET_CLASS
<SUBSECTION Private>
g_win32_output_stream_get_type
GWin32OutputStreamPrivate
</SECTION>
<SECTION>
<FILE>gwin32registrykey</FILE>
<SUBSECTION>
GWin32RegistrySubkeyIter
g_win32_registry_subkey_iter_copy
g_win32_registry_subkey_iter_free
g_win32_registry_subkey_iter_assign
<SUBSECTION>
GWin32RegistryValueIter
g_win32_registry_value_iter_copy
g_win32_registry_value_iter_free
g_win32_registry_value_iter_assign
<SUBSECTION>
GWin32RegistryKey
g_win32_registry_key_new
g_win32_registry_key_new_w
g_win32_registry_key_get_child
g_win32_registry_key_get_child_w
<SUBSECTION>
g_win32_registry_subkey_iter_init
g_win32_registry_subkey_iter_clear
g_win32_registry_subkey_iter_n_subkeys
g_win32_registry_subkey_iter_next
g_win32_registry_subkey_iter_get_name
g_win32_registry_subkey_iter_get_name_w
<SUBSECTION>
g_win32_registry_value_iter_init
g_win32_registry_value_iter_clear
g_win32_registry_value_iter_n_values
g_win32_registry_value_iter_next
GWin32RegistryValueType
g_win32_registry_value_iter_get_value_type
g_win32_registry_value_iter_get_name
g_win32_registry_value_iter_get_name_w
g_win32_registry_value_iter_get_data
g_win32_registry_value_iter_get_data_w
<SUBSECTION>
g_win32_registry_key_get_value
g_win32_registry_key_get_value_w
g_win32_registry_key_get_path
g_win32_registry_key_get_path_w
GWin32RegistryKeyWatchCallbackFunc
GWin32RegistryKeyWatcherFlags
g_win32_registry_key_watch
g_win32_registry_key_has_changed
g_win32_registry_key_erase_change_indicator
<SUBSECTION Standard>
GWin32RegistryKeyClass
<SUBSECTION Private>
GWin32RegistryKeyPrivate
g_win32_registry_key_get_type
g_win32_registry_subkey_iter_get_type
g_win32_registry_value_iter_get_type
G_TYPE_WIN32_REGISTRY_KEY
G_WIN32_REGISTRY_KEY
G_WIN32_REGISTRY_KEY_CLASS
G_IS_WIN32_REGISTRY_KEY
G_IS_WIN32_REGISTRY_KEY_CLASS
G_WIN32_REGISTRY_KEY_GET_CLASS
G_TYPE_WIN32_REGISTRY_SUBKEY_ITER
G_TYPE_WIN32_REGISTRY_VALUE_ITER
</SECTION>

805
docs/reference/gio/gio.xml Normal file
View file

@ -0,0 +1,805 @@
<?xml version="1.0"?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<refentry id="gio">
<refentryinfo>
<title>gio</title>
<productname>GIO</productname>
<authorgroup>
<author>
<contrib>Developer</contrib>
<firstname>Matthias</firstname>
<surname>Clasen</surname>
<email>mclasen@redhat.com</email>
</author>
</authorgroup>
</refentryinfo>
<refmeta>
<refentrytitle>gio</refentrytitle>
<manvolnum>1</manvolnum>
<refmiscinfo class="manual">User Commands</refmiscinfo>
</refmeta>
<refnamediv>
<refname>gio</refname>
<refpurpose>GIO commandline tool</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>gio</command>
<arg choice="plain">help</arg>
<arg choice="opt"><replaceable>COMMAND</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gio</command>
<arg choice="plain">version</arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gio</command>
<arg choice="plain">cat</arg>
<arg choice="plain" rep="repeat"><replaceable>LOCATION</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gio</command>
<arg choice="plain">copy</arg>
<arg choice="opt" rep="repeat"><replaceable>OPTION</replaceable></arg>
<arg choice="plain" rep="repeat"><replaceable>SOURCE</replaceable></arg>
<arg choice="plain"><replaceable>DESTINATION</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gio</command>
<arg choice="plain">info</arg>
<arg choice="opt" rep="repeat"><replaceable>OPTION</replaceable></arg>
<arg choice="plain" rep="repeat"><replaceable>LOCATION</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gio</command>
<arg choice="plain">launch</arg>
<arg choice="plain"><replaceable>DESKTOP-FILE</replaceable></arg>
<arg choice="opt" rep="repeat"><replaceable>FILE-ARG</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gio</command>
<arg choice="plain">list</arg>
<arg choice="opt" rep="repeat"><replaceable>OPTION</replaceable></arg>
<arg choice="opt" rep="repeat"><replaceable>LOCATION</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gio</command>
<arg choice="plain">mime</arg>
<arg choice="plain"><replaceable>MIMETYPE</replaceable></arg>
<arg choice="opt"><replaceable>HANDLER</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gio</command>
<arg choice="plain">mkdir</arg>
<arg choice="opt" rep="repeat"><replaceable>OPTION</replaceable></arg>
<arg choice="plain" rep="repeat"><replaceable>LOCATION</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gio</command>
<arg choice="plain">monitor</arg>
<arg choice="opt" rep="repeat"><replaceable>OPTION</replaceable></arg>
<arg choice="opt" rep="repeat"><replaceable>LOCATION</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gio</command>
<arg choice="plain">mount</arg>
<arg choice="opt" rep="repeat"><replaceable>OPTION</replaceable></arg>
<arg choice="opt" rep="repeat"><replaceable>LOCATION</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gio</command>
<arg choice="plain">move</arg>
<arg choice="opt" rep="repeat"><replaceable>OPTION</replaceable></arg>
<arg choice="plain" rep="repeat"><replaceable>SOURCE</replaceable></arg>
<arg choice="plain"><replaceable>DESTINATION</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gio</command>
<arg choice="plain">open</arg>
<arg choice="plain" rep="repeat"><replaceable>LOCATION</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gio</command>
<arg choice="plain">rename</arg>
<arg choice="plain"><replaceable>LOCATION</replaceable></arg>
<arg choice="plain"><replaceable>NAME</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gio</command>
<arg choice="plain">remove</arg>
<arg choice="opt" rep="repeat"><replaceable>OPTION</replaceable></arg>
<arg choice="plain" rep="repeat"><replaceable>LOCATION</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gio</command>
<arg choice="plain">save</arg>
<arg choice="opt" rep="repeat"><replaceable>OPTION</replaceable></arg>
<arg choice="plain"><replaceable>DESTINATION</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gio</command>
<arg choice="plain">set</arg>
<arg choice="opt" rep="repeat"><replaceable>OPTION</replaceable></arg>
<arg choice="plain"><replaceable>LOCATION</replaceable></arg>
<arg choice="plain"><replaceable>ATTRIBUTE</replaceable></arg>
<arg choice="plain" rep="repeat"><replaceable>VALUE</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gio</command>
<arg choice="plain">trash</arg>
<arg choice="opt" rep="repeat"><replaceable>OPTION</replaceable></arg>
<arg choice="opt" rep="repeat"><replaceable>LOCATION</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gio</command>
<arg choice="plain">tree</arg>
<arg choice="opt" rep="repeat"><replaceable>OPTION</replaceable></arg>
<arg choice="opt" rep="repeat"><replaceable>LOCATION</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para><command>gio</command> is a utility that makes many of the GIO
features available from the commandline. In doing so, it provides
commands that are similar to traditional utilities, but let you
use GIO locations instead of local files: for example you can use
something like <filename>smb://server/resource/file.txt</filename>
as a location.</para>
<para>Plain filenames which contain a colon will be interpreted as URIs
with an unknown protocol. To avoid this, prefix them with a path such as
<filename>./</filename>, or with the <literal>file:</literal> protocol.</para>
</refsect1>
<refsect1>
<title>Commands</title>
<variablelist>
<varlistentry>
<term>
<command>help</command>
<arg choice="opt"><replaceable>COMMAND</replaceable></arg>
</term>
<listitem>
<para>Displays a short synopsis of the available commands or provides
detailed help on a specific command.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>version</command>
</term>
<listitem>
<para>Prints the GLib version to which <command>gio</command>
belongs.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>cat</command>
<arg choice="plain" rep="repeat"><replaceable>LOCATION</replaceable></arg>
</term>
<listitem>
<para>Concatenates the given files and prints them to the standard
output.</para>
<para>The <command>cat</command> command works just like the traditional <command>cat</command> utility.</para>
<para>Note: just pipe through <command>cat</command> if you need its formatting options
like <option>-n</option>, <option>-T</option> or other.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>copy</command>
<arg choice="opt" rep="repeat"><replaceable>OPTION</replaceable></arg>
<arg choice="plain" rep="repeat"><replaceable>SOURCE</replaceable></arg>
<arg choice="plain"><replaceable>DESTINATION</replaceable></arg>
</term>
<listitem>
<para>Copies one or more files from <replaceable>SOURCE</replaceable>
to <replaceable>DESTINATION</replaceable>. If more than one source
is specified, the destination must be a directory.</para>
<para>The <command>copy</command> command is similar to the traditional <command>cp</command> utility.</para>
<refsect3>
<title>Options</title>
<variablelist>
<varlistentry>
<term><option>-T</option>, <option>--no-target-directory</option></term>
<listitem><para>Dont copy into <replaceable>DESTINATION</replaceable> even if it is a directory.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-p</option>, <option>--progress</option></term>
<listitem><para>Show progress.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-i</option>, <option>--interactive</option></term>
<listitem><para>Prompt for confirmation before overwriting files.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--preserve</option></term>
<listitem><para>Preserve all attributes of copied files.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-b</option>, <option>--backup</option></term>
<listitem><para>Create backups of existing destination files.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-P</option>, <option>--no-dereference</option></term>
<listitem><para>Never follow symbolic links.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--default-permissions</option></term>
<listitem><para>Use the default permissions of the current process for the destination file, rather than copying the permissions of the source file.</para></listitem>
</varlistentry>
</variablelist>
</refsect3>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>info</command>
<arg choice="opt" rep="repeat"><replaceable>OPTION</replaceable></arg>
<arg choice="plain" rep="repeat"><replaceable>LOCATION</replaceable></arg>
</term>
<listitem>
<para>Shows information about the given locations.</para>
<para>The <command>info</command> command is similar to the traditional <command>ls</command> utility.</para>
<refsect3>
<title>Options</title>
<variablelist>
<varlistentry>
<term><option>-w</option>, <option>--query-writable</option></term>
<listitem><para>List writable attributes.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-f</option>, <option>--filesystem</option></term>
<listitem><para>Show information about the filesystem that the given
locations reside on.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-a</option> <option>--attributes=<replaceable>ATTRIBUTES</replaceable></option></term>
<listitem><para>The attributes to get.</para>
<para>Attributes can be specified with their GIO name, e.g.
<literal>standard::icon</literal>, or just by namespace, e.g. <literal>unix</literal>, or by <literal>*</literal>,
which matches all attributes. Several attributes or groups
of attributes can be specified, separated by comma.</para>
<para>By default, all attributes are listed.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-n</option>, <option>--nofollow-symlinks</option></term>
<listitem><para>Dont follow symbolic links.</para></listitem>
</varlistentry>
</variablelist>
</refsect3>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>launch</command>
<arg choice="plain"><replaceable>DESKTOP-FILE</replaceable></arg>
<arg choice="opt" rep="repeat"><replaceable>FILE-ARG</replaceable></arg>
</term>
<listitem>
<para>Launch a desktop file from any location given.</para>
<para>The <command>launch</command> command extends the behavior of the <command>open</command> command by allowing
any desktop file to be launched, not only those registered as file handlers.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>list</command>
<arg choice="opt" rep="repeat"><replaceable>OPTION</replaceable></arg>
<arg choice="opt" rep="repeat"><replaceable>LOCATION</replaceable></arg>
</term>
<listitem>
<para>Lists the contents of the given locations. If no location is
given, the contents of the current directory are shown.</para>
<para>The <command>list</command> command is similar to the traditional <command>ls</command> utility.</para>
<refsect3>
<title>Options</title>
<variablelist>
<varlistentry>
<term><option>-a</option> <option>--attributes=<replaceable>ATTRIBUTES</replaceable></option></term>
<listitem><para>The attributes to get.</para>
<para>Attributes can be specified with their GIO name, e.g.
<literal>standard::icon</literal>, or just by namespace, e.g. <literal>unix</literal>, or by <literal>*</literal>,
which matches all attributes. Several attributes or groups
of attributes can be specified, separated by comma.</para>
<para>By default, all attributes are listed.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-h</option>, <option>--hidden</option></term>
<listitem><para>Show hidden files.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-l</option>, <option>--long</option></term>
<listitem><para>Use a long listing format.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-n</option>, <option>--nofollow-symlinks</option></term>
<listitem><para>Dont follow symbolic links.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-d</option>, <option>--print-display-names</option></term>
<listitem><para>Print display names.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-u</option>, <option>--print-uris</option></term>
<listitem><para>Print full URIs.</para></listitem>
</varlistentry>
</variablelist>
</refsect3>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>mime</command>
<arg choice="plain"><replaceable>MIMETYPE</replaceable></arg>
<arg choice="opt"><replaceable>HANDLER</replaceable></arg>
</term>
<listitem>
<para>If no handler is given, the <command>mime</command> command lists the
registered and recommended applications for the mimetype.
If a handler is given, it is set as the default handler for
the mimetype.</para>
<para>Handlers must be specified by their desktop file name,
including the extension. Example: <literal>org.gnome.gedit.desktop</literal>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>mkdir</command>
<arg choice="opt" rep="repeat"><replaceable>OPTION</replaceable></arg>
<arg choice="plain" rep="repeat"><replaceable>LOCATION</replaceable></arg>
</term>
<listitem>
<para>Creates directories.</para>
<para>The <command>mkdir</command> command is similar to the traditional <command>mkdir</command> utility.</para>
<refsect3>
<title>Options</title>
<variablelist>
<varlistentry>
<term><option>-p</option>, <option>--parent</option></term>
<listitem><para>Create parent directories when necessary.</para></listitem>
</varlistentry>
</variablelist>
</refsect3>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>monitor</command>
<arg choice="opt" rep="repeat"><replaceable>OPTION</replaceable></arg>
<arg choice="opt" rep="repeat"><replaceable>LOCATION</replaceable></arg>
</term>
<listitem>
<para>Monitors files or directories for changes, such as creation
deletion, content and attribute changes, and mount and unmount
operations affecting the monitored locations.</para>
<para>The <command>monitor</command> command uses the GIO file monitoring APIs to do
its job. GIO has different implementations for different platforms.
The most common implementation on Linux uses inotify.</para>
<refsect3>
<title>Options</title>
<variablelist>
<varlistentry>
<term><option>-d</option>, <option>--dir=<replaceable>LOCATION</replaceable></option></term>
<listitem><para>Monitor the given location as a directory. Normally,
the file type is used to determine whether to monitor a file or directory.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-f</option>, <option>--file=<replaceable>LOCATION</replaceable></option></term>
<listitem><para>Monitor the given location as a file. Normally,
the file type is used to determine whether to monitor a file or directory.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-D</option>, <option>--direct=<replaceable>LOCATION</replaceable></option></term>
<listitem><para>Monitor the file directly. This allows changes made via hardlinks to be captured.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-s</option>, <option>--silent=<replaceable>LOCATION</replaceable></option></term>
<listitem><para>Monitor the file directly, but dont report changes.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-n</option>, <option>--no-moves</option></term>
<listitem><para>Report moves and renames as simple deleted/created events.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-m</option>, <option>--mounts</option></term>
<listitem><para>Watch for mount events.</para></listitem>
</varlistentry>
</variablelist>
</refsect3>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>mount</command>
<arg choice="opt" rep="repeat"><replaceable>OPTION</replaceable></arg>
<arg choice="opt" rep="repeat"><replaceable>LOCATION</replaceable></arg>
</term>
<listitem>
<para>Provides commandline access to various aspects of GIOs mounting
functionality.</para>
<para>Mounting refers to the traditional concept of arranging multiple
file systems and devices in a single tree, rooted at <filename>/</filename>. Classical
mounting happens in the kernel and is controlled by the mount utility.
GIO expands this concept by introducing mount daemons that can make
file systems available to GIO applications without kernel
involvement.</para>
<para>GIO mounts can require authentication, and the <command>mount</command> command
may ask for user IDs, passwords, and so on, when required.</para>
<refsect3>
<title>Options</title>
<variablelist>
<varlistentry>
<term><option>-m</option>, <option>--mountable</option></term>
<listitem><para>Mount as mountable.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-d</option>, <option>--device=<replaceable>ID</replaceable></option></term>
<listitem><para>Mount volume with device file, or other identifier.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-u</option>, <option>--unmount</option></term>
<listitem><para>Unmount the location.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-e</option>, <option>--eject</option></term>
<listitem><para>Eject the location.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-t</option>, <option>--stop=<replaceable>DEVICE</replaceable></option></term>
<listitem><para>Stop drive with device file.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-s</option>, <option>--unmount-scheme=<replaceable>SCHEME</replaceable></option></term>
<listitem><para>Unmount all mounts with the given scheme.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-f</option>, <option>--force</option></term>
<listitem><para>Ignore outstanding file operations when unmounting or ejecting.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-a</option>, <option>--anonymous</option></term>
<listitem><para>Use an anonymous user when authenticating.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-l</option>, <option>--list</option></term>
<listitem><para>List all GIO mounts.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-o</option>, <option>--monitor</option></term>
<listitem><para>Monitor mount-related events.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-i</option>, <option>--detail</option></term>
<listitem><para>Show extra information.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>--tcrypt-pim</option></term>
<listitem><para>The numeric PIM when unlocking a VeraCrypt volume.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>--tcrypt-hidden</option></term>
<listitem><para>Mount a TCRYPT hidden volume.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>--tcrypt-system</option></term>
<listitem><para>Mount a TCRYPT system volume.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect3>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>move</command>
<arg choice="opt" rep="repeat"><replaceable>OPTION</replaceable></arg>
<arg choice="plain" rep="repeat"><replaceable>SOURCE</replaceable></arg>
<arg choice="plain"><replaceable>DESTINATION</replaceable></arg>
</term>
<listitem>
<para>Moves one or more files from <replaceable>SOURCE</replaceable>
to <replaceable>DESTINATION</replaceable>. If more than one source
is specified, the destination must be a directory.</para>
<para>The <command>move</command> command is similar to the traditional <command>mv</command> utility.</para>
<refsect3>
<title>Options</title>
<variablelist>
<varlistentry>
<term><option>-T</option>, <option>--no-target-directory</option></term>
<listitem><para>Dont copy into <replaceable>DESTINATION</replaceable> even if it is a directory.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-p</option>, <option>--progress</option></term>
<listitem><para>Show progress.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-i</option>, <option>--interactive</option></term>
<listitem><para>Prompt for confirmation before overwriting files.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-b</option>, <option>--backup</option></term>
<listitem><para>Create backups of existing destination files.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-C</option>, <option>--no-copy-fallback</option></term>
<listitem><para>Dont use copy and delete fallback.</para></listitem>
</varlistentry>
</variablelist>
</refsect3>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>open</command>
<arg choice="plain" rep="repeat"><replaceable>LOCATION</replaceable></arg>
</term>
<listitem>
<para>Opens files with the default application that is registered
to handle files of this type.</para>
<para>GIO obtains this information from the shared-mime-info
database, with per-user overrides stored in
<filename><envar>$XDG_DATA_HOME</envar>/applications/mimeapps.list</filename>.</para>
<para>The <command>mime</command> command can be used to change the default handler for
a mimetype.</para>
<para>Environment variables will not be set on the application, as it
may be an existing process which is activated to handle the new file.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>rename</command>
<arg choice="plain"><replaceable>LOCATION</replaceable></arg>
<arg choice="plain"><replaceable>NAME</replaceable></arg>
</term>
<listitem>
<para>Renames a file.</para>
<para>The <command>rename</command> command is similar to the traditional <command>rename</command> utility.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>remove</command>
<arg choice="opt" rep="repeat"><replaceable>OPTION</replaceable></arg>
<arg choice="plain" rep="repeat"><replaceable>LOCATION</replaceable></arg>
</term>
<listitem>
<para>Deletes each given file.</para>
<para>This command removes files irreversibly. If you want a reversible
way to remove files, see the <command>trash</command> command.</para>
<para>Note that not all URI schemes that are supported by GIO may
allow deletion of files.</para>
<para>The <command>remove</command> command is similar to the traditional <command>rm</command> utility.</para>
<refsect3>
<title>Options</title>
<variablelist>
<varlistentry>
<term><option>-f</option>, <option>--force</option></term>
<listitem><para>Ignore non-existent and non-deletable files.</para></listitem>
</varlistentry>
</variablelist>
</refsect3>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>save</command>
<arg choice="opt" rep="repeat"><replaceable>OPTION</replaceable></arg>
<arg choice="plain"><replaceable>DESTINATION</replaceable></arg>
</term>
<listitem>
<para>Reads from standard input and saves the data to the given
location.</para>
<para>This is similar to just redirecting output to a file using
traditional shell syntax, but the <command>save</command> command allows saving to
location that GIO can write to.</para>
<refsect3>
<title>Options</title>
<variablelist>
<varlistentry>
<term><option>-b</option>, <option>--backup</option></term>
<listitem><para>Back up existing destination files.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-c</option>, <option>--create</option></term>
<listitem><para>Only create the destination if it doesnt exist yet.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-a</option>, <option>--append</option></term>
<listitem><para>Append to the end of the file.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-p</option>, <option>--private</option></term>
<listitem><para>When creating, restrict access to the current user.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-u</option>, <option>--unlink</option></term>
<listitem><para>When replacing, replace as if the destination did not exist.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-v</option>, <option>--print-etag</option></term>
<listitem><para>Print the new ETag in the end.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-e</option>, <option>--etag=<replaceable>ETAG</replaceable></option></term>
<listitem><para>The ETag of the file that is overwritten.</para></listitem>
</varlistentry>
</variablelist>
</refsect3>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>set</command>
<arg choice="plain"><replaceable>LOCATION</replaceable></arg>
<arg choice="plain"><replaceable>ATTRIBUTE</replaceable></arg>
<arg choice="plain" rep="repeat"><replaceable>VALUE</replaceable></arg>
</term>
<listitem>
<para>Sets a file attribute on a file.</para>
<para>File attributes can be specified with their GIO name, e.g
<literal>standard::icon</literal>. Note that not all GIO file attributes are writable.
Use the <option>--query-writable</option> option of the <command>info</command> command to list
writable file attributes.</para>
<para>If the <replaceable>TYPE</replaceable> is unset,
<replaceable>VALUE</replaceable> does not have to be specified.
If the <replaceable>TYPE</replaceable> is <literal>stringv</literal>, multiple values can be given.</para>
<refsect3>
<title>Options</title>
<variablelist>
<varlistentry>
<term><option>-t</option>, <option>--type=<replaceable>TYPE</replaceable></option></term>
<listitem><para>Specifies the type of the attribute. Supported
types are <literal>string</literal>, <literal>stringv</literal>,
<literal>bytestring</literal>, <literal>boolean</literal>,
<literal>uint32</literal>, <literal>int32</literal>,
<literal>uint64</literal>, <literal>int64</literal> and <literal>unset</literal>.</para>
<para>If the type is not specified, <literal>string</literal> is assumed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-n</option>, <option>--nofollow-symlinks</option></term>
<listitem><para>Dont follow symbolic links.</para></listitem>
</varlistentry>
</variablelist>
</refsect3>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>trash</command>
<arg choice="opt" rep="repeat"><replaceable>OPTION</replaceable></arg>
<arg choice="opt" rep="repeat"><replaceable>LOCATION</replaceable></arg>
</term>
<listitem>
<para>Sends files or directories to the Trashcan or restore them from
Trashcan. This can be a different folder depending on where the file
is located, and not all file systems support this concept. In the common
case that the file lives inside a users home directory, the trash folder is
<filename><envar>$XDG_DATA_HOME</envar>/Trash</filename>.</para>
<para>Note that moving files to the trash does not free up space on
the file system until the Trashcan is emptied. If you are interested
in deleting a file irreversibly, see the <command>remove</command> command.</para>
<para>Inspecting and emptying the Trashcan is normally supported by
graphical file managers such as Nautilus, but you can also see the
trash with the command: <command>gio trash --list</command> or
<command>gio list trash://</command>.</para>
<refsect3>
<title>Options</title>
<variablelist>
<varlistentry>
<term><option>-f</option>, <option>--force</option></term>
<listitem><para>Ignore non-existent and non-deletable files.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--empty</option></term>
<listitem><para>Empty the trash.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--list</option></term>
<listitem><para>List files in the trash with their original locations</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--restore</option></term>
<listitem><para>Restore a file from trash to its original location. A URI beginning
with <literal>trash://</literal> is expected here. If the original
directory doesn't exist, it will be recreated.</para></listitem>
</varlistentry>
</variablelist>
</refsect3>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>tree</command>
<arg choice="opt" rep="repeat"><replaceable>OPTION</replaceable></arg>
<arg choice="opt" rep="repeat"><replaceable>LOCATION</replaceable></arg>
</term>
<listitem>
<para>Lists the contents of the given locations recursively, in a
tree-like format. If no location is given, it defaults to the current
directory.</para>
<para>The <command>tree</command> command is similar to the traditional <command>tree</command> utility.</para>
<refsect3>
<title>Options</title>
<variablelist>
<varlistentry>
<term><option>-h</option>, <option>--hidden</option></term>
<listitem><para>Show hidden files.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-l</option>, <option>--follow-symlinks</option></term>
<listitem><para>Follow symbolic links.</para></listitem>
</varlistentry>
</variablelist>
</refsect3>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Exit status</title>
<para>On success 0 is returned, a non-zero failure code otherwise.</para>
</refsect1>
<refsect1>
<title>See Also</title>
<para>
<citerefentry>
<refentrytitle>cat</refentrytitle>
<manvolnum>1</manvolnum>
</citerefentry>,
<citerefentry>
<refentrytitle>cp</refentrytitle>
<manvolnum>1</manvolnum>
</citerefentry>,
<citerefentry>
<refentrytitle>ls</refentrytitle>
<manvolnum>1</manvolnum>
</citerefentry>,
<citerefentry>
<refentrytitle>mkdir</refentrytitle>
<manvolnum>1</manvolnum>
</citerefentry>,
<citerefentry>
<refentrytitle>mv</refentrytitle>
<manvolnum>1</manvolnum>
</citerefentry>,
<citerefentry>
<refentrytitle>rm</refentrytitle>
<manvolnum>1</manvolnum>
</citerefentry>,
<citerefentry>
<refentrytitle>tree</refentrytitle>
<manvolnum>1</manvolnum>
</citerefentry>.
</para>
</refsect1>
</refentry>

View file

@ -0,0 +1,254 @@
<refentry id="glib-compile-resources" lang="en">
<refentryinfo>
<title>glib-compile-schemas</title>
<productname>GIO</productname>
<authorgroup>
<author>
<contrib>Developer</contrib>
<firstname>Alexander</firstname>
<surname>Larsson</surname>
</author>
</authorgroup>
</refentryinfo>
<refmeta>
<refentrytitle>glib-compile-resources</refentrytitle>
<manvolnum>1</manvolnum>
<refmiscinfo class="manual">User Commands</refmiscinfo>
</refmeta>
<refnamediv>
<refname>glib-compile-resources</refname>
<refpurpose>GLib resource compiler</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>glib-compile-resources</command>
<arg choice="opt" rep="repeat">OPTION</arg>
<arg choice="req">FILE</arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1><title>Description</title>
<para><command>glib-compile-resources</command> reads the resource description from
<replaceable>FILE</replaceable> and the files that it references
and creates a binary resource bundle that is suitable for use with the
<link linkend="GResource"><type>GResource</type></link> API.
The resulting bundle is then written out as-is, or as C source for linking into
an application.
</para>
<para>
The XML resource files normally have the filename extension <filename>.gresource.xml</filename>.
For a detailed description of the XML file format, see the
<link linkend="GResource"><type>GResource</type></link> documentation.
</para>
</refsect1>
<refsect1><title>Options</title>
<variablelist>
<varlistentry>
<term><option>-h</option>, <option>--help</option></term>
<listitem><para>
Print help and exit
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--version</option></term>
<listitem><para>
Print program version and exit
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--target=<replaceable>TARGET</replaceable></option></term>
<listitem><para>
Store the compiled resources in the file <replaceable>TARGET</replaceable>.
If not specified a filename based on the <replaceable>FILE</replaceable>
basename is used.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--sourcedir=<replaceable>DIRECTORY</replaceable></option></term>
<listitem><para>
The files referenced in <replaceable>FILE</replaceable> are loaded from
this directory. If not specified, the current directory is used.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--generate</option></term>
<listitem><para>
Write the output file in the format selected for by its filename extension:
<variablelist>
<varlistentry>
<term><literal>.c</literal></term>
<listitem><para>C source</para></listitem>
</varlistentry>
<varlistentry>
<term><literal>.h</literal></term>
<listitem><para>C header</para></listitem>
</varlistentry>
<varlistentry>
<term><literal>.gresource</literal></term>
<listitem><para>resource bundle</para></listitem>
</varlistentry>
</variablelist>
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--generate-source</option></term>
<listitem><para>
Instead of a writing the resource bundle in binary form create a C source file
that contains the resource bundle. This can then be compiled into an
application for easy access.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--generate-header</option></term>
<listitem><para>
Generate a header file for use with C code generated by
<option>--generate-source</option>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--generate-dependencies</option></term>
<listitem><para>
Prints the list of files that the resource bundle references to standard output.
This can be used to track dependencies in the build system. For example, the
following make rule would mark <replaceable>test.gresource</replaceable> as
depending on all the files that <replaceable>test.gresource.xml</replaceable>
includes, so that is is automatically rebuilt if any of them change:
<programlisting>
test.gresource: test.gresource.xml $(shell $(GLIB_COMPILE_RESOURCES) --generate-dependencies test.gresource.xml)
</programlisting>
Note that this may or may not be portable to non-GNU <command>make</command>.
</para>
<para>
Also see <option>--dependency-file</option>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>--c-name</option></term>
<listitem><para>
Specify the prefix used for the C identifiers in the code generated by
<option>--generate-source</option> and <option>--generate-header</option>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--manual-register</option></term>
<listitem><para>
By default code generated by <option>--generate-source</option> uses automatic
initialization of the resource. This works on most systems by using the
compiler support for constructors. However, some (uncommon) compilers may not
support this, you can then specify <option>--manual-register</option>,
which will generate custom register and unregister functions that your code
can manually call at initialization and uninitialization time.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--internal</option></term>
<listitem><para>
By default code generated by <option>--generate-source</option> declares all
initialization functions as <type>extern</type>. So they are exported
unless this is prevented by a link script or other means. Since libraries
usually want to use the functions only internally it can be more useful to
declare them as
<link linkend="G-GNUC-INTERNAL:CAPS"><literal>G_GNUC_INTERNAL</literal></link>
which is what <option>--internal</option> does.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--external-data</option></term>
<listitem><para>
By default code generated by <option>--generate-source</option> embeds the
resource data as a string literal. When <option>--external-data</option>
is given, the data is only declared in the generated C file, and the data
has to be linked externally.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--dependency-file=<replaceable>FILE</replaceable></option></term>
<listitem><para>
Write dependencies in the same style as gcc -M -MF to the given file.
If <option>FILE</option> is -, the dependencies are written to the standard
output. Unlike <option>--generate-dependencies</option>, this option can be
combined with other <option>--generate</option> options to generate dependencies
as a side-effect of generating sources.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--generate-phony-targets</option></term>
<listitem><para>
When creating a dependency file with <option>--dependency-file</option>
include phony targets in the same style as gcc -MP. This would typically
be used with <literal>make</literal>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--compiler=<replaceable>NAME</replaceable></option></term>
<listitem><para>
Generate code that is going to target the given compiler <replaceable>NAME</replaceable>.
The current two compiler modes are "gcc", for all GCC-compatible toolchains; and "msvc",
for the Microsoft Visual C Compiler. If this option isn't set, then the default will be
taken from the <envar>CC</envar> environment variable.
</para></listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1><title>Environment</title>
<variablelist>
<varlistentry>
<term><envar>XMLLINT</envar></term>
<listitem><para>
The full path to the <command>xmllint</command> executable. This is used to
preprocess resources with the <literal>xml-stripblanks</literal> preprocessing
option. If this environment variable is not set, <command>xmllint</command> is
searched for in the <envar>PATH</envar>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><envar>GDK_PIXBUF_PIXDATA</envar></term>
<listitem><para>
Deprecated since gdk-pixbuf 2.32, as <type>GResource</type> supports embedding
modern image formats without conversion.
</para><para>
The full path to the <command>gdk-pixbuf-pixdata</command> executable. This is
used to preprocess resources with the <literal>to-pixdata</literal> preprocessing
option. If this environment variable is not set, <command>gdk-pixbuf-pixdata</command>
is searched for in the <envar>PATH</envar>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><envar>JSON_GLIB_FORMAT</envar></term>
<listitem><para>
The full path to the <command>json-glib-format</command> executable. This is used
to preprocess resources with the <literal>json-stripblanks</literal> preprocessing
option. If this environment variable is not set, <command>json-glib-format</command>
is searched for in the <envar>PATH</envar>.
</para></listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>

View file

@ -0,0 +1,118 @@
<refentry id="glib-compile-schemas" lang="en">
<refentryinfo>
<title>glib-compile-schemas</title>
<productname>GIO</productname>
<authorgroup>
<author>
<contrib>Developer</contrib>
<firstname>Ryan</firstname>
<surname>Lortie</surname>
</author>
</authorgroup>
</refentryinfo>
<refmeta>
<refentrytitle>glib-compile-schemas</refentrytitle>
<manvolnum>1</manvolnum>
<refmiscinfo class="manual">User Commands</refmiscinfo>
</refmeta>
<refnamediv>
<refname>glib-compile-schemas</refname>
<refpurpose>GSettings schema compiler</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>glib-compile-schemas</command>
<arg choice="opt" rep="repeat">OPTION</arg>
<arg choice="req">DIRECTORY</arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1><title>Description</title>
<para><command>glib-compile-schemas</command> compiles all the GSettings XML
schema files in <replaceable>DIRECTORY</replaceable> into a binary file
with the name <filename>gschemas.compiled</filename> that can be used
by <link linkend="GSettings"><type>GSettings</type></link>. The XML schema
files must have the filename extension <filename>.gschema.xml</filename>.
For a detailed description of the XML file format, see the
<link linkend="GSettings"><type>GSettings</type></link> documentation.
</para>
<para>
At runtime, GSettings looks for schemas in the
<filename>glib-2.0/schemas</filename> subdirectories of all directories
specified in the <envar>XDG_DATA_DIRS</envar> environment variable. The
usual location to install schema files is
<filename>/usr/share/glib-2.0/schemas</filename>.
</para>
<para>
In addition to schema files, glib-compile-schemas reads 'vendor override'
files, which are key files that can override default values for keys in
the schemas. The group names in the key files are the schema id, and the
values are written in serialized GVariant form.
Vendor override files must have the filename extension
<filename>.gschema.override</filename>.
</para>
<para>
By convention, vendor override files begin with <filename>nn_</filename>
where <filename>nn</filename> is a number from 00 to 99. Higher
numbered files have higher priority (eg: if the same override is made in
a file numbered 10 and then again in a file numbered 20, the override
from 20 will take precedence).
</para>
</refsect1>
<refsect1><title>Options</title>
<variablelist>
<varlistentry>
<term><option>-h</option>, <option>--help</option></term>
<listitem><para>
Print help and exit
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--version</option></term>
<listitem><para>
Print program version and exit
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--targetdir=<replaceable>TARGET</replaceable></option></term>
<listitem><para>
Store <filename>gschemas.compiled</filename> in the <replaceable>TARGET</replaceable> directory instead of <replaceable>DIRECTORY</replaceable>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--strict</option></term>
<listitem><para>
Abort on any errors in schemas. Without this option, faulty schema files are
simply omitted from the resulting compiled schema.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--dry-run</option></term>
<listitem><para>
Don't write <filename>gschemas.compiled</filename>. This option can be used
to check <filename>.gschema.xml</filename> sources for errors.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--allow-any-name</option></term>
<listitem><para>
Do not enforce restrictions on key names. Note that this option is purely
to facility the transition from GConf, and will be removed at some time
in the future.
</para></listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>

View file

@ -0,0 +1,127 @@
<refentry id="gresource-tool" lang="en">
<refentryinfo>
<title>gresource</title>
<productname>GIO</productname>
<authorgroup>
<author>
<contrib>Developer</contrib>
<firstname>Matthias</firstname>
<surname>Clasen</surname>
</author>
</authorgroup>
</refentryinfo>
<refmeta>
<refentrytitle>gresource</refentrytitle>
<manvolnum>1</manvolnum>
<refmiscinfo class="manual">User Commands</refmiscinfo>
</refmeta>
<refnamediv>
<refname>gresource</refname>
<refpurpose>GResource tool</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>gresource</command>
<arg choice="opt">--section <replaceable>SECTION</replaceable></arg>
<arg choice="plain">list</arg>
<arg choice="plain"><replaceable>FILE</replaceable></arg>
<arg choice="opt"><replaceable>PATH</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gresource</command>
<arg choice="opt">--section <replaceable>SECTION</replaceable></arg>
<arg choice="plain">details</arg>
<arg choice="plain"><replaceable>FILE</replaceable></arg>
<arg choice="opt"><replaceable>PATH</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gresource</command>
<arg choice="opt">--section <replaceable>SECTION</replaceable></arg>
<arg choice="plain">extract</arg>
<arg choice="plain"><replaceable>FILE</replaceable></arg>
<arg choice="plain"><replaceable>PATH</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gresource</command>
<arg choice="plain">sections</arg>
<arg choice="plain"><replaceable>FILE</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gresource</command>
<arg choice="plain">help</arg>
<arg choice="opt"><replaceable>COMMAND</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1><title>Description</title>
<para><command>gresource</command> offers a simple commandline
interface to <link linkend="GResource"><type>GResource</type></link>.
It lets you list and extract resources that have been compiled
into a resource file or included in an elf file (a binary or a
shared library).
</para>
<para>
The file to operate on is specified by the <replaceable>FILE</replaceable>
argument.
</para>
<para>
If an elf file includes multiple sections with resources, it is
possible to select which one to operate on with the
<arg choice="plain">--section</arg> option. Use the
<arg choice="plain">sections</arg> command to find available sections.
</para>
</refsect1>
<refsect1><title>Commands</title>
<variablelist>
<varlistentry>
<term><option>list</option></term>
<listitem><para>
Lists resources. If <replaceable>SECTION</replaceable> is given, only
list resources in this section. If <replaceable>PATH</replaceable> is
given, only list matching resources.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>details</option></term>
<listitem><para>
Lists resources with details. If <replaceable>SECTION</replaceable>
is given, only list resources in this section. If
<replaceable>PATH</replaceable> is given, only list matching resources.
Details include the section, size and compression of each resource.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>extract</option></term>
<listitem><para>
Extracts the resource named by <replaceable>PATH</replaceable> to stdout.
Note that resources may contain binary data.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>sections</option></term>
<listitem><para>
Lists sections containing resources. This is only interesting if
<replaceable>FILE</replaceable> is an elf file.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>help</option></term>
<listitem><para>
Prints help and exits.
</para></listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>

View file

@ -0,0 +1,248 @@
<refentry id="gsettings-tool" lang="en">
<refentryinfo>
<title>gsettings</title>
<productname>GIO</productname>
<authorgroup>
<author>
<contrib>Developer</contrib>
<firstname>Ryan</firstname>
<surname>Lortie</surname>
</author>
</authorgroup>
</refentryinfo>
<refmeta>
<refentrytitle>gsettings</refentrytitle>
<manvolnum>1</manvolnum>
<refmiscinfo class="manual">User Commands</refmiscinfo>
</refmeta>
<refnamediv>
<refname>gsettings</refname>
<refpurpose>GSettings configuration tool</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>gsettings</command>
<arg choice="plain">get</arg>
<arg choice="plain"><replaceable>SCHEMA</replaceable><arg choice="opt">:<replaceable>PATH</replaceable></arg></arg>
<arg choice="plain"><replaceable>KEY</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gsettings</command>
<arg choice="plain">monitor</arg>
<arg choice="plain"><replaceable>SCHEMA</replaceable><arg choice="opt">:<replaceable>PATH</replaceable></arg></arg>
<arg choice="opt"><replaceable>KEY</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gsettings</command>
<arg choice="plain">writable</arg>
<arg choice="plain"><replaceable>SCHEMA</replaceable><arg choice="opt">:<replaceable>PATH</replaceable></arg></arg>
<arg choice="plain"><replaceable>KEY</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gsettings</command>
<arg choice="plain">range</arg>
<arg choice="plain"><replaceable>SCHEMA</replaceable><arg choice="opt">:<replaceable>PATH</replaceable></arg></arg>
<arg choice="plain"><replaceable>KEY</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gsettings</command>
<arg choice="plain">describe</arg>
<arg choice="plain"><replaceable>SCHEMA</replaceable><arg choice="opt">:<replaceable>PATH</replaceable></arg></arg>
<arg choice="plain"><replaceable>KEY</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gsettings</command>
<arg choice="plain">set</arg>
<arg choice="plain"><replaceable>SCHEMA</replaceable><arg choice="opt">:<replaceable>PATH</replaceable></arg></arg>
<arg choice="plain"><replaceable>KEY</replaceable></arg>
<arg choice="plain"><replaceable>VALUE</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gsettings</command>
<arg choice="plain">reset</arg>
<arg choice="plain"><replaceable>SCHEMA</replaceable><arg choice="opt">:<replaceable>PATH</replaceable></arg></arg>
<arg choice="plain"><replaceable>KEY</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gsettings</command>
<arg choice="plain">reset-recursively</arg>
<arg choice="plain"><replaceable>SCHEMA</replaceable><arg choice="opt">:<replaceable>PATH</replaceable></arg></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gsettings</command>
<arg choice="plain">list-schemas</arg>
<arg choice="opt">--print-paths</arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gsettings</command>
<arg choice="plain">list-relocatable-schemas</arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gsettings</command>
<arg choice="plain">list-keys</arg>
<arg choice="plain"><replaceable>SCHEMA</replaceable><arg choice="opt">:<replaceable>PATH</replaceable></arg></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gsettings</command>
<arg choice="plain">list-children</arg>
<arg choice="plain"><replaceable>SCHEMA</replaceable><arg choice="opt">:<replaceable>PATH</replaceable></arg></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gsettings</command>
<arg choice="plain">list-recursively</arg>
<arg choice="opt"><replaceable>SCHEMA</replaceable><arg choice="opt">:<replaceable>PATH</replaceable></arg></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gsettings</command>
<arg choice="plain">help</arg>
<arg choice="opt"><replaceable>COMMAND</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1><title>Description</title>
<para><command>gsettings</command> offers a simple commandline
interface to <link linkend="GSettings"><type>GSettings</type></link>.
It lets you get, set or monitor an individual key for changes.
</para>
<para>
The <replaceable>SCHEMA</replaceable> and <replaceable>KEY</replaceable>
arguments are required for most commands to specify the schema id and the
name of the key to operate on. The schema id may optionally have a
:<replaceable>PATH</replaceable> suffix. Specifying the path is only needed
if the schema does not have a fixed path.
</para>
<para>
When setting a key, you also need specify a <replaceable>VALUE</replaceable>
The format for the value is that of a serialized
<link linkend="GVariant"><type>GVariant</type></link>,
so e.g. a string
must include explicit quotes: "'foo'". This format is also used when printing
out values.
</para>
<para>
Note that gsettings needs a D-Bus session bus connection to write changes to
the dconf database.
</para>
</refsect1>
<refsect1><title>Commands</title>
<variablelist>
<varlistentry>
<term><option>get</option></term>
<listitem><para>
Gets the value of <replaceable>KEY</replaceable>.
The value is printed out as a serialized
<link linkend="GVariant"><type>GVariant</type></link>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>monitor</option></term>
<listitem><para>
Monitors <replaceable>KEY</replaceable> for changes and prints the changed
values. If no <replaceable>KEY</replaceable> is specified, all keys in the
schema are monitored. Monitoring will continue until the process is terminated.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>writable</option></term>
<listitem><para>
Finds out whether <replaceable>KEY</replaceable> is writable.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>range</option></term>
<listitem><para>
Queries the range of valid values for <replaceable>KEY</replaceable>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>describe</option></term>
<listitem><para>
Queries the description of valid values for <replaceable>KEY</replaceable>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>set</option></term>
<listitem><para>
Sets the value of <replaceable>KEY</replaceable> to
<replaceable>VALUE</replaceable>. The value is specified as a serialized
<link linkend="GVariant"><type>GVariant</type></link>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>reset</option></term>
<listitem><para>
Resets <replaceable>KEY</replaceable> to its default value.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>reset-recursively</option></term>
<listitem><para>
Reset all keys under the given <replaceable>SCHEMA</replaceable>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>list-schemas</option></term>
<listitem><para>
Lists the installed, non-relocatable schemas.
See <option>list-relocatable-schemas</option> if you are interested in
relocatable schemas. If <optional><option>--print-paths</option></optional>
is given, the path where each schema is mapped is also printed.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>list-relocatable-schemas</option></term>
<listitem><para>
Lists the installed, relocatable schemas.
See <option>list-schemas</option> if you are interested in
non-relocatable schemas.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>list-keys</option></term>
<listitem><para>
Lists the keys in <replaceable>SCHEMA</replaceable>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>list-children</option></term>
<listitem><para>
Lists the children of <replaceable>SCHEMA</replaceable>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>list-recursively</option></term>
<listitem><para>
Lists keys and values, recursively. If no <replaceable>SCHEMA</replaceable>
is given, list keys in all schemas.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>help</option></term>
<listitem><para>
Prints help and exits.
</para></listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>

Binary file not shown.

Binary file not shown.

After

Width:  |  Height:  |  Size: 47 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 31 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 20 KiB

View file

@ -0,0 +1,242 @@
if get_option('gtk_doc')
subdir('gdbus-object-manager-example')
subdir('xml')
ignore_headers = [
'fam',
'fen',
'gdbus-2.0',
'gvdb',
'inotify',
'kqueue',
'libasyncns',
'tests',
'win32',
'xdgmime',
'gappinfoprivate.h',
'gapplicationimpl.h',
'gasynchelper.h',
'gcontenttypeprivate.h',
'gcontextspecificgroup.h',
'gcredentialsprivate.h',
'gdbus-daemon-generated.h',
'gdbusactiongroup-private.h',
'gdbusauth.h',
'gdbusauthmechanismanon.h',
'gdbusauthmechanismexternal.h',
'gdbusauthmechanism.h',
'gdbusauthmechanismsha1.h',
'gdbusdaemon.h',
'gdbusprivate.h',
'gdelayedsettingsbackend.h',
'gdocumentportal.h',
'gdummyfile.h',
'gdummyproxyresolver.h',
'gdummytlsbackend.h',
'gfileattribute-priv.h',
'gfileinfo-priv.h',
'ghttpproxy.h',
'giomodule-priv.h',
'gioprivate.h',
'giowin32-afunix.h',
'giowin32-priv.h',
'gio_probes.h',
'gio_trace.h',
'gio-tool.h',
'glocaldirectorymonitor.h',
'glocalfileenumerator.h',
'glocalfile.h',
'glocalfileinfo.h',
'glocalfileinputstream.h',
'glocalfileiostream.h',
'glocalfilemonitor.h',
'glocalfileoutputstream.h',
'glocalvfs.h',
'gmemorymonitordbus.h',
'gmemorymonitorportal.h',
'gmountprivate.h',
'gnativevolumemonitor.h',
'gnetworkingprivate.h',
'gnetworkmonitorbase.h',
'gnetworkmonitornetlink.h',
'gnetworkmonitornm.h',
'gnetworkmonitorportal.h',
'gnotificationbackend.h',
'gnotification-private.h',
'gopenuriportal.h',
'gpollfilemonitor.h',
'gportalsupport.h',
'gpowerprofilemonitordbus.h',
'gpowerprofilemonitorportal.h',
'gproxyresolverportal.h',
'gregistrysettingsbackend.h',
'gresourcefile.h',
'gsettingsbackendinternal.h',
'gsettings-mapping.h',
'gsettingsschema-internal.h',
'gsocketinputstream.h',
'gsocketoutputstream.h',
'gsocks4aproxy.h',
'gsocks4proxy.h',
'gsocks5proxy.h',
'gsubprocesslauncher-private.h',
'gthreadedresolver.h',
'gtrashportal.h',
'gunionvolumemonitor.h',
'gunixmount.h',
'gunixresolver.h',
'gunixvolume.h',
'gunixvolumemonitor.h',
'gwin32networkmonitor.h',
'gwin32api-application-activation-manager.h',
'gwin32api-iterator.h',
'gwin32api-misc.h',
'gwin32api-package.h',
'gwin32api-storage.h',
'gwin32appinfo.h',
'gwin32file-sync-stream.h',
'gwin32mount.h',
'gwin32packageparser.h',
'gwin32resolver.h',
'gwin32volumemonitor.h',
'thumbnail-verify.h',
'xdp-dbus.h',
]
sections_files = files('gio-sections-common.txt')
if host_system == 'windows'
ignore_headers += [
'gfiledescriptorbased.h',
'gunixmounts.h',
'gunixfdlist.h',
'gunixfdmessage.h',
'gunixinputstream.h',
'gunixoutputstream.h',
'gdesktopappinfo.h',
'gosxappinfo.h',
]
sections_files += files('gio-sections-win32.txt')
platform_file = files('gio-docs-win32.xml')
else
if glib_have_cocoa
ignore_headers += ['gdesktopappinfo.h']
else
ignore_headers += ['gosxappinfo.h']
endif
ignore_headers += [
'gwin32inputstream.h',
'gwin32outputstream.h',
'gwin32registrykey.h',
]
platform_file = files('gio-docs-unix.xml')
endif
ignore_sources = [
'kqueue',
'tests',
'gdbus-daemon-generated.c',
'xdp-dbus.c',
]
docpath = join_paths(glib_datadir, 'gtk-doc', 'html')
version_conf = configuration_data()
version_conf.set('VERSION', meson.project_version())
configure_file(
input: 'version.xml.in',
output: 'version.xml',
configuration: version_conf
)
# FIXME: configure_file() does not support more than one file in input
# argument. If input argument is omitted then meson checks that all items in
# the command array are strings. But if we have an input then extra files
# can be passed in command array.
# See https://github.com/mesonbuild/meson/issues/5893
concat_files_helper = find_program('concat-files-helper.py')
configure_file(
output : 'gio-sections.txt',
input : sections_files[0],
command : [concat_files_helper, '@OUTPUT@'] + sections_files,
)
configure_file(
output : 'gio-docs-platform.xml',
input : platform_file,
copy : true,
)
content_files = [
'overview.xml',
'migrating-posix.xml',
'migrating-gnome-vfs.xml',
'migrating-gconf.xml',
'migrating-gdbus.xml',
'gio-querymodules.xml',
'glib-compile-schemas.xml',
'glib-compile-resources.xml',
'gapplication.xml',
'gsettings.xml',
'gresource.xml',
'gdbus.xml',
'gdbus-codegen.xml',
]
content_files += [
gdbus_example_objectmanager_xml,
gdbus_example_objectmanager_sources,
gdbus_object_manager_example_doc
]
gnome.gtkdoc('gio',
main_xml : 'gio-docs.xml',
namespace : 'g',
mode : 'none',
dependencies : [libgio_dep, libgobject_dep, libglib_dep],
src_dir : 'gio',
scan_args : gtkdoc_common_scan_args + [
'--rebuild-types',
'--ignore-headers=' + ' '.join(ignore_headers),
],
mkdb_args : [
'--ignore-files=' + ' '.join(ignore_sources),
],
content_files : content_files,
expand_content_files : [
'overview.xml',
'migrating-posix.xml',
'migrating-gnome-vfs.xml',
'migrating-gconf.xml',
'migrating-gdbus.xml',
'gdbus-codegen.xml',
],
html_assets : [
'gvfs-overview.png',
'menu-example.png',
'menu-model.png',
],
fixxref_args: [
'--html-dir=' + docpath,
'--extra-dir=' + join_paths('gio', '..', 'glib', 'html'),
'--extra-dir=' + join_paths('gio', '..', 'gobject', 'html'),
],
install: true,
check: true,
)
endif
if get_option('man')
manpages = ['gapplication', 'gio-querymodules', 'glib-compile-schemas',
'glib-compile-resources', 'gsettings', 'gresource', 'gdbus',
'gio', 'gdbus-codegen']
foreach page : manpages
custom_target(page + '-man',
input: page + '.xml',
output: page + '.1',
command: xsltproc_command,
install: true,
install_dir: man1_dir)
endforeach
endif

View file

@ -0,0 +1,515 @@
<chapter>
<title>Migrating from GConf to GSettings</title>
<section>
<title>Before you start</title>
<para>
Converting individual applications and their settings from GConf to
GSettings can be done at will. But desktop-wide settings like font or
theme settings often have consumers in multiple modules. Therefore,
some consideration has to go into making sure that all users of a setting
are converted to GSettings at the same time or that the program
responsible for configuring that setting continues to update the value in
both places.
</para>
<para>
It is always a good idea to have a look at how others have handled
similar problems before.
</para>
</section>
<section>
<title>Conceptual differences</title>
<para>
Conceptually, GConf and GSettings are fairly similar. Both
have a concept of pluggable backends. Both keep information
about keys and their types in schemas. Both have a concept of
mandatory values, which lets you implement lock-down.
</para>
<para>
There are some differences in the approach to schemas. GConf
installs the schemas into the database and has API to handle
schema information (gconf_client_get_default_from_schema(),
gconf_value_get_schema(), etc). GSettings on the other hand
assumes that an application knows its own schemas, and does
not provide API to handle schema information at runtime.
GSettings is also more strict about requiring a schema whenever
you want to read or write a key. To deal with more free-form
information that would appear in schema-less entries in GConf,
GSettings allows for schemas to be 'relocatable'.
</para>
<para>
One difference in the way applications interact with their
settings is that with GConf you interact with a tree of
settings (ie the keys you pass to functions when reading
or writing values are actually paths with the actual name
of the key as the last element. With GSettings, you create
a GSettings object which has an implicit prefix that determines
where the settings get stored in the global tree of settings,
but the keys you pass when reading or writing values are just
the key names, not the full path.
</para>
</section>
<section>
<title>GConfClient (and GConfBridge) API conversion</title>
<para>
Most people use GConf via the high-level #GConfClient API.
The corresponding API is the #GSettings object. While not
every GConfClient function has a direct GSettings equivalent,
many do:
<table id="gconf-client-vs-gsettings">
<tgroup cols="2">
<thead>
<row><entry>GConfClient</entry><entry>GSettings</entry></row>
</thead>
<tbody>
<row><entry>gconf_client_get_default()</entry><entry>no direct equivalent,
instead you call g_settings_new() for the schemas you use</entry></row>
<row><entry>gconf_client_set()</entry><entry>g_settings_set()</entry></row>
<row><entry>gconf_client_get()</entry><entry>g_settings_get()</entry></row>
<row><entry>gconf_client_get_bool()</entry><entry>g_settings_get_boolean()</entry></row>
<row><entry>gconf_client_set_bool()</entry><entry>g_settings_set_boolean()</entry></row>
<row><entry>gconf_client_get_int()</entry><entry>g_settings_get_int()</entry></row>
<row><entry>gconf_client_set_int()</entry><entry>g_settings_set_int()</entry></row>
<row><entry>gconf_client_get_float()</entry><entry>g_settings_get_double()</entry></row>
<row><entry>gconf_client_set_float()</entry><entry>g_settings_set_double()</entry></row>
<row><entry>gconf_client_get_string()</entry><entry>g_settings_get_string()</entry></row>
<row><entry>gconf_client_set_string()</entry><entry>g_settings_set_string()</entry></row>
<row><entry>gconf_client_get_list()</entry><entry>for string lists, see g_settings_get_strv(), else see g_settings_get_value() and #GVariant API</entry></row>
<row><entry>gconf_client_set_list()</entry><entry>for string lists, see g_settings_set_strv(), else see g_settings_set_value() and #GVariant API</entry></row>
<row><entry>gconf_entry_get_is_writable()</entry><entry>g_settings_is_writable()</entry></row>
<row><entry>gconf_client_notify_add()</entry><entry>not required, the #GSettings::changed signal is emitted automatically</entry></row>
<row><entry>gconf_client_add_dir()</entry><entry>not required, each GSettings instance automatically watches all keys in its path</entry></row>
<row><entry>#GConfChangeSet</entry><entry>g_settings_delay(), g_settings_apply()</entry></row>
<row><entry>gconf_client_get_default_from_schema()</entry><entry>no equivalent, applications are expected to know their schema</entry></row>
<row><entry>gconf_client_all_entries()</entry><entry>no equivalent, applications are expected to know their schema, and GSettings does not allow schema-less entries</entry></row>
<row><entry>gconf_client_get_without_default()</entry><entry>no equivalent</entry></row>
<row><entry>gconf_bridge_bind_property()</entry><entry>g_settings_bind()</entry></row>
<row><entry>gconf_bridge_bind_property_full()</entry><entry>g_settings_bind_with_mapping()</entry></row>
</tbody>
</tgroup>
</table>
</para>
<para>
GConfBridge was a third-party library that used GConf to bind an object property
to a particular configuration key. GSettings offers this service itself.
</para>
<para>
There is a pattern that is sometimes used for GConf, where a setting can have
explicit 'value A', explicit 'value B' or 'use the system default'. With GConf,
'use the system default' is sometimes implemented by unsetting the user value.
</para>
<para>
This is not possible in GSettings, since it does not have API to determine if a value
is the default and does not let you unset values. The recommended way (and much
clearer) way in which this can be implemented in GSettings is to have a separate
'use-system-default' boolean setting.
</para>
</section>
<section>
<title>Change notification</title>
<para>
GConf requires you to call gconf_client_add_dir() and
gconf_client_notify_add() to get change notification. With
GSettings, this is not necessary; signals get emitted automatically
for every change.
</para>
<para>
The #GSettings::changed signal is emitted for each changed key.
There is also a #GSettings::change-event signal that you can handle
if you need to see groups of keys that get changed at the same time.
</para>
<para>
GSettings also notifies you about changes in writability of keys,
with the #GSettings::writable-changed signal (and the
#GSettings::writable-change-event signal).
</para>
</section>
<section><title>Change sets</title>
<para>
GConf has a concept of a set of changes which can be applied or reverted
at once: #GConfChangeSet (GConf doesn't actually apply changes atomically,
which is one of its shortcomings).
</para>
<para>
Instead of a separate object to represent a change set, GSettings has a
'delayed-apply' mode, which can be turned on for a GSettings object by
calling g_settings_delay(). In this mode, changes done to the GSettings
object are not applied - they are still visible when calling g_settings_get()
<emphasis>on the same object</emphasis>, but not to other GSettings instances
or even other processes.
</para>
<para>
To apply the pending changes all at once (GSettings <emphasis>does</emphasis>
atomicity here), call g_settings_apply(). To revert the pending changes,
call g_settings_revert() or just drop the reference to the #GSettings object.
</para>
</section>
<section>
<title>Schema conversion</title>
<para>
If you are porting your application from GConf, most likely you already
have a GConf schema. GConf comes with a commandline tool
gsettings-schema-convert that can help with the task of converting
a GConf schema into an equivalent GSettings schema. The tool is not
perfect and may need assistance in some cases.
</para>
<example><title>An example for using gsettings-schema-convert</title>
<para>Running <userinput>gsettings-schema-convert --gconf --xml --schema-id "org.gnome.font-rendering" --output org.gnome.font-rendering.gschema.xml destop_gnome_font_rendering.schemas</userinput> on the following <filename>desktop_gnome_font_rendering.schemas</filename> file:
<programlisting>
<![CDATA[
<?xml version="1.0"?>
<gconfschemafile>
<schemalist>
<schema>
<key>/schemas/desktop/gnome/font_rendering/dpi</key>
<applyto>/desktop/gnome/font_rendering/dpi</applyto>
<owner>gnome</owner>
<type>int</type>
<default>96</default>
<locale name="C">
<short>DPI</short>
<long>The resolution used for converting font sizes to pixel sizes, in dots per inch.</long>
</locale>
</schema>
</schemalist>
</gconfschemafile>
]]>
</programlisting>
produces a <filename>org.gnome.font-rendering.gschema.xml</filename> file with the following content:
<programlisting>
<![CDATA[
<schemalist>
<schema id="org.gnome.font-rendering" path="/desktop/gnome/font_rendering/">
<key name="dpi" type="i">
<default>96</default>
<summary>DPI</summary>
<description>The resolution used for converting font sizes to pixel sizes, in dots per inch.</description>
</key>
</schema>
</schemalist>
]]>
</programlisting>
</para>
</example>
<para>
GSettings schemas are identified at runtime by their id (as specified
in the XML source file). It is recommended to use a dotted name as schema
id, similar in style to a D-Bus bus name, e.g. "org.gnome.SessionManager".
In cases where the settings are general and not specific to one application,
the id should not use StudlyCaps, e.g. "org.gnome.font-rendering".
The filename used for the XML schema source is immaterial, but
schema compiler expects the files to have the extension
<filename>.gschema.xml</filename>. It is recommended to simply
use the schema id as the filename, followed by this extension,
e.g. <filename>org.gnome.SessionManager.gschema.xml</filename>.
</para>
<para>
The XML source file for your GSettings schema needs to get installed
into <filename>$datadir/glib-2.0/schemas</filename>, and needs to be
compiled into a binary form. At runtime, GSettings looks for compiled
schemas in the <filename>glib-2.0/schemas</filename> subdirectories
of all <envar>XDG_DATA_DIRS</envar> directories, so if you install
your schema in a different location, you need to set the
<envar>XDG_DATA_DIRS</envar> environment variable appropriately.
</para>
<para>
Schemas are compiled into binary form by the
<link linkend="glib-compile-schemas">glib-compile-schemas</link> utility.
GIO provides a <literal>glib_compile_schemas</literal>
variable for the schema compiler.
</para>
<para>
You can ignore all of this by using the provided m4 macros. To
do this, add to your <filename>configure.ac</filename>:
<programlisting>
GLIB_GSETTINGS
</programlisting>
The corresponding <filename>Makefile.am</filename> fragment looks like
this:
<programlisting>
# gsettings_SCHEMAS is a list of all the schemas you want to install
gsettings_SCHEMAS = my.app.gschema.xml
# include the appropriate makefile rules for schema handling
@GSETTINGS_RULES@
</programlisting>
</para>
<para>
This is not sufficient on its own. You need to mention what the source
of the <filename>my.app.gschema.xml</filename> file is. If the schema
file is distributed directly with your project's tarball then a mention
in <varname>EXTRA_DIST</varname> is appropriate. If the schema file is
generated from another source then you will need the appropriate rule
for that, plus probably an item in <varname>EXTRA_DIST</varname> for the
source files used by that rule.
</para>
<para>
One possible pitfall in doing schema conversion is that the default
values in GSettings schemas are parsed by the #GVariant parser.
This means that strings need to include quotes in the XML. Also note
that the types are now specified as #GVariant type strings.
<programlisting>
<![CDATA[
<type>string</type>
<default>rgb</default>
]]>
</programlisting>
becomes
<programlisting>
<![CDATA[
<key name="rgba-order" type="s">
<default>'rgb'</default> <!-- note quotes -->
</key>
]]>
</programlisting>
</para>
<para>
Another possible complication is that GConf specifies full paths
for each key, while a GSettings schema has a 'path' attribute that
contains the prefix for all the keys in the schema, and individual
keys just have a simple name. So
<programlisting>
<![CDATA[
<key>/schemas/desktop/gnome/font_rendering/antialiasing</key>
]]>
</programlisting>
becomes
<programlisting>
<![CDATA[
<schema id="org.gnome.font" path="/desktop/gnome/font_rendering/">
<key name="antialiasing" type="s">
]]>
</programlisting>
</para>
<para>
Default values can be localized in both GConf and GSettings schemas,
but GSettings uses gettext for the localization. You can specify
the gettext domain to use in the <tag class="attribute">gettext-domain</tag>
attribute. Therefore, when converting localized defaults in GConf,
<programlisting>
<![CDATA[
<key>/schemas/apps/my_app/font_size</key>
<locale name="C">
<default>18</default>
</locale>
<locale name="be">
<default>24</default>
</locale>
</key>
]]>
</programlisting>
becomes
<programlisting>
<![CDATA[
<schema id="..." gettext-domain="your-domain">
...
<key name="font-size" type="i">
<default l10n="messages" context="font_size">18</default>
</key>
]]>
</programlisting>
</para>
<para>
GSettings uses gettext for translation of default values.
The string that is translated is exactly the string that appears
inside of the <tag class='starttag'>default</tag> element. This
includes the quotation marks that appear around strings.
Default values must be marked with the <varname>l10n</varname>
attribute in the <tag class='starttag'>default</tag> tag, which
should be set as equal to <literal>'messages'</literal> or
<literal>'time'</literal> depending on the desired category. An
optional translation context can also be specified with the
<varname>context</varname> attribute, as in the example. This
is usually recommended, since the string "<literal>18</literal>"
is not particularly easy to translate without context. The
translated version of the default value should be stored in the
specified <varname>gettext-domain</varname>. Care must be taken
during translation to ensure that all translated values remain
syntactically valid; mistakes here will cause runtime errors.
</para>
<para>
GSettings schemas have optional <tag class="starttag">summary</tag> and
<tag class="starttag">description</tag> elements for each key which
correspond to the <tag class="starttag">short</tag> and
<tag class="starttag">long</tag> elements in the GConf schema and
will be used in similar ways by a future gsettings-editor, so you
should use the same conventions for them: The summary is just a short
label with no punctuation, the description can be one or more complete
sentences. If multiple paragraphs are desired for the description, the
paragraphs should be separated by a completely empty line.
</para>
<para>
Translations for these strings will also be handled
via gettext, so you should arrange for these strings to be
extracted into your gettext catalog. One way to do that is to use
intltool. Since intltool 0.50.1, schema files are
supported, so all you have to do is to add your .gschema.xml
files to <filename>POTFILES.in</filename> with a line like
<programlisting>
[type: gettext/gsettings]data/org.foo.MyApp.gschema.xml
</programlisting>
</para>
<para>
GSettings is a bit more restrictive about key names than GConf. Key
names in GSettings can be at most 32 characters long, and must only
consist of lowercase characters, numbers and dashes, with no
consecutive dashes. The first character must not be a number or dash,
and the last character cannot be '-'.
</para>
<para>
If you are using the GConf backend for GSettings during the
transition, you may want to keep your key names the same they
were in GConf, so that existing settings in the users GConf
database are preserved. You can achieve this by using the
<option>--allow-any-name</option> with the
<link linkend="glib-compile-schemas">glib-compile-schemas</link> schema
compiler. Note that this option is only meant
to ease the process of porting your application, allowing parts
of your application to continue to access GConf and parts to use
GSettings. By the time you have finished porting your application
you must ensure that all key names are valid.
</para>
</section>
<section><title>Data conversion</title>
<para>
GConf comes with a GSettings backend that can be used to
facility the transition to the GSettings API until you are
ready to make the jump to a different backend (most likely
dconf). To use it, you need to set the <envar>GSETTINGS_BACKEND</envar>
to 'gconf', e.g. by using
<programlisting>
g_setenv ("GSETTINGS_BACKEND", "gconf", TRUE);
</programlisting>
early on in your program. Note that this backend is meant purely
as a transition tool, and should not be used in production.
</para>
<para>
GConf also comes with a utility called
<command>gsettings-data-convert</command>, which is designed to help
with the task of migrating user settings from GConf into another
GSettings backend. It can be run manually, but it is designed to be
executed automatically, every time a user logs in. It keeps track of
the data migrations that it has already done, and it is harmless to
run it more than once.
</para>
<para>
To make use of this utility, you must install a keyfile in the
directory <filename>/usr/share/GConf/gsettings</filename> which
lists the GSettings keys and GConf paths to map to each other, for
each schema that you want to migrate user data for.
</para>
<para>
Here is an example:
<programlisting>
<![CDATA[
[org.gnome.fonts]
antialiasing = /desktop/gnome/font_rendering/antialiasing
dpi = /desktop/gnome/font_rendering/dpi
hinting = /desktop/gnome/font_rendering/hinting
rgba-order = /desktop/gnome/font_rendering/rgba_order
[apps.myapp:/path/to/myapps/]
some-odd-key1 = /apps/myapp/some_ODD-key1
]]>
</programlisting>
The last key demonstrates that it may be necessary to modify the key
name to comply with stricter GSettings key name rules. Of course,
that means your application must use the new key names when looking
up settings in GSettings.
</para>
<para>
The last group in the example also shows how to handle the case
of 'relocatable' schemas, which don't have a fixed path. You can
specify the path to use in the group name, separated by a colon.
</para>
<para>
There are some limitations: <command>gsettings-data-convert</command>
does not do any transformation of the values. And it does not handle
complex GConf types other than lists of strings or integers.
</para>
<para>
Don't forget to require GConf 2.31.1 or newer in your configure
script if you are making use of the GConf backend or the conversion
utility.
</para>
<para>
If, as an application developer, you are interested in manually
ensuring that <command>gsettings-data-convert</command> has been
invoked (for example, to deal with the case where the user is
logged in during a distribution upgrade or for non-XDG desktop
environments which do not run the command as an autostart) you
may invoke it manually during your program initialisation. This
is not recommended for all application authors -- it is your
choice if this use case concerns you enough.
</para>
<para>
Internally, <command>gsettings-data-convert</command> uses a
keyfile to track which settings have been migrated. The
following code fragment will check that keyfile to see if your
data conversion script has been run yet and, if not, will
attempt to invoke the tool to run it. You should adapt it to
your application as you see fit.
</para>
<para>
<programlisting>
<![CDATA[
static void
ensure_migrated (const gchar *name)
{
gboolean needed = TRUE;
GKeyFile *kf;
gchar **list;
gsize i, n;
kf = g_key_file_new ();
g_key_file_load_from_data_dirs (kf, "gsettings-data-convert",
NULL, G_KEY_FILE_NONE, NULL);
list = g_key_file_get_string_list (kf, "State", "converted", &n, NULL);
if (list)
{
for (i = 0; i < n; i++)
if (strcmp (list[i], name) == 0)
{
needed = FALSE;
break;
}
g_strfreev (list);
}
g_key_file_free (kf);
if (needed)
g_spawn_command_line_sync ("gsettings-data-convert",
NULL, NULL, NULL, NULL);
}
]]>
</programlisting>
</para>
<para>
Although there is the possibility that the
<command>gsettings-data-convert</command> script will end up
running multiple times concurrently with this approach, it is
believed that this is safe.
</para>
</section>
</chapter>

View file

@ -0,0 +1,310 @@
<?xml version="1.0"?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
<!ENTITY % local.common.attrib "xmlns:xi CDATA #FIXED 'http://www.w3.org/2003/XInclude'">
<!ENTITY version SYSTEM "version.xml">
]>
<chapter>
<title>Migrating to GDBus</title>
<section>
<title>Conceptual differences</title>
<para>
The central concepts of D-Bus are modelled in a very similar way
in dbus-glib and GDBus. Both have objects representing connections,
proxies and method invocations. But there are some important
differences:
<itemizedlist>
<listitem><para>
dbus-glib uses the <ulink
url="http://www.freedesktop.org/wiki/Software/dbus#ReferenceImplementation.28dbus-daemonandlibdbus.29">libdbus
reference implementation</ulink>, GDBus doesn't. Instead, it
relies on GIO streams as transport layer, and has its own
implementation for the D-Bus connection setup and
authentication. Apart from using streams as transport,
avoiding libdbus also lets GDBus avoid some thorny
multithreading issues.
</para></listitem>
<listitem><para>
dbus-glib uses the GObject type system for method arguments and
return values, including a homegrown container specialization
mechanism. GDBus relies on the #GVariant type system which is
explicitly designed to match D-Bus types.
</para></listitem>
<listitem><para>
dbus-glib models only D-Bus interfaces and does not provide
any types for objects. GDBus models both D-Bus interfaces
(via the #GDBusInterface, #GDBusProxy and
#GDBusInterfaceSkeleton types) and objects (via the
#GDBusObject, #GDBusObjectSkeleton and #GDBusObjectProxy types).
</para></listitem>
<listitem><para>
GDBus includes native support for the <ulink url="http://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-properties">org.freedesktop.DBus.Properties</ulink> (via the #GDBusProxy type) and <ulink url="http://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-objectmanager">org.freedesktop.DBus.ObjectManager</ulink> D-Bus interfaces, dbus-glib doesn't.
</para></listitem>
<listitem><para>
The typical way to export an object in dbus-glib involves
generating glue code from XML introspection data using
<command>dbus-binding-tool</command>. GDBus provides a
similar tool called <command><link
linkend="gdbus-codegen">gdbus-codegen</link></command> that
can also generate Docbook D-Bus interface documentation.
</para></listitem>
<listitem><para>
dbus-glib doesn't provide any convenience API for owning and
watching bus names, GDBus provides the g_bus_own_name() and
g_bus_watch_name() family of convenience functions.
</para></listitem>
<listitem><para>
GDBus provides API to parse, generate and work with <link
linkend="gio-D-Bus-Introspection-Data">Introspection
XML</link>, dbus-glib doesn't.
</para></listitem>
<listitem><para>
GTestDBus provides API to create isolated unit tests <link
linkend="gio-D-Bus-Test-Scaffolding">GDBus Test Scaffolding</link>.
</para></listitem>
</itemizedlist>
</para>
</section>
<section>
<title>API comparison</title>
<table id="dbus-glib-vs-gdbus">
<title>dbus-glib APIs and their GDBus counterparts</title>
<tgroup cols="2">
<thead>
<row><entry>dbus-glib</entry><entry>GDBus</entry></row>
</thead>
<tbody>
<row><entry>#DBusGConnection</entry><entry>#GDBusConnection</entry></row>
<row><entry>#DBusGProxy</entry><entry>#GDBusProxy, #GDBusInterface - also see #GDBusObjectProxy</entry></row>
<row><entry>#DBusGObject</entry><entry>#GDBusInterfaceSkeleton, #GDBusInterface - also see #GDBusObjectSkeleton</entry></row>
<row><entry>#DBusGMethodInvocation</entry><entry>#GDBusMethodInvocation</entry></row>
<row><entry>dbus_g_bus_get()</entry><entry>g_bus_get_sync(), also see
g_bus_get()</entry></row>
<row><entry>dbus_g_proxy_new_for_name()</entry><entry>g_dbus_proxy_new_sync() and
g_dbus_proxy_new_for_bus_sync(), also see g_dbus_proxy_new()</entry></row>
<row><entry>dbus_g_proxy_add_signal()</entry><entry>not needed, use the generic #GDBusProxy::g-signal</entry></row>
<row><entry>dbus_g_proxy_connect_signal()</entry><entry>use g_signal_connect() with #GDBusProxy::g-signal</entry></row>
<row><entry>dbus_g_connection_register_g_object()</entry><entry>g_dbus_connection_register_object() - also see g_dbus_object_manager_server_export()</entry></row>
<row><entry>dbus_g_connection_unregister_g_object()</entry><entry>g_dbus_connection_unregister_object() - also see g_dbus_object_manager_server_unexport()</entry></row>
<row><entry>dbus_g_object_type_install_info()</entry><entry>introspection data is installed while registering
an object, see g_dbus_connection_register_object()</entry></row>
<row><entry>dbus_g_proxy_begin_call()</entry><entry>g_dbus_proxy_call()</entry></row>
<row><entry>dbus_g_proxy_end_call()</entry><entry>g_dbus_proxy_call_finish()</entry></row>
<row><entry>dbus_g_proxy_call()</entry><entry>g_dbus_proxy_call_sync()</entry></row>
<row><entry>dbus_g_error_domain_register()</entry><entry>g_dbus_error_register_error_domain()</entry></row>
<row><entry>dbus_g_error_has_name()</entry><entry>no direct equivalent, see g_dbus_error_get_remote_error()</entry></row>
<row><entry>dbus_g_method_return()</entry><entry>g_dbus_method_invocation_return_value()</entry></row>
<row><entry>dbus_g_method_return_error()</entry><entry>g_dbus_method_invocation_return_error() and variants</entry></row>
<row><entry>dbus_g_method_get_sender()</entry><entry>g_dbus_method_invocation_get_sender()</entry></row>
</tbody>
</tgroup>
</table>
</section>
<section>
<title>Owning bus names</title>
<para>
Using dbus-glib, you typically call RequestName manually
to own a name, like in the following excerpt:
<informalexample><programlisting><![CDATA[
error = NULL;
res = dbus_g_proxy_call (system_bus_proxy,
"RequestName",
&error,
G_TYPE_STRING, NAME_TO_CLAIM,
G_TYPE_UINT, DBUS_NAME_FLAG_ALLOW_REPLACEMENT,
G_TYPE_INVALID,
G_TYPE_UINT, &result,
G_TYPE_INVALID);
if (!res)
{
if (error != NULL)
{
g_warning ("Failed to acquire %s: %s",
NAME_TO_CLAIM, error->message);
g_error_free (error);
}
else
{
g_warning ("Failed to acquire %s", NAME_TO_CLAIM);
}
goto out;
}
if (result != DBUS_REQUEST_NAME_REPLY_PRIMARY_OWNER)
{
if (error != NULL)
{
g_warning ("Failed to acquire %s: %s",
NAME_TO_CLAIM, error->message);
g_error_free (error);
}
else
{
g_warning ("Failed to acquire %s", NAME_TO_CLAIM);
}
exit (1);
}
dbus_g_proxy_add_signal (system_bus_proxy, "NameLost",
G_TYPE_STRING, G_TYPE_INVALID);
dbus_g_proxy_connect_signal (system_bus_proxy, "NameLost",
G_CALLBACK (on_name_lost), NULL, NULL);
/* further setup ... */
]]>
</programlisting></informalexample>
</para>
<para>
While you can do things this way with GDBus too, using
g_dbus_proxy_call_sync(), it is much nicer to use the high-level API
for this:
<informalexample><programlisting><![CDATA[
static void
on_name_acquired (GDBusConnection *connection,
const gchar *name,
gpointer user_data)
{
/* further setup ... */
}
/* ... */
owner_id = g_bus_own_name (G_BUS_TYPE_SYSTEM,
NAME_TO_CLAIM,
G_BUS_NAME_OWNER_FLAGS_ALLOW_REPLACEMENT,
on_bus_acquired,
on_name_acquired,
on_name_lost,
NULL,
NULL);
g_main_loop_run (loop);
g_bus_unown_name (owner_id);
]]>
</programlisting></informalexample>
Note that g_bus_own_name() works asynchronously and requires
you to enter your mainloop to await the on_name_aquired()
callback. Also note that in order to avoid race conditions (e.g.
when your service is activated by a method call), you have to export
your manager object <emphasis>before</emphasis> acquiring the
name. The on_bus_acquired() callback is the right place to do
such preparations.
</para>
</section>
<section>
<title>Creating proxies for well-known names</title>
<para>
dbus-glib lets you create proxy objects for well-known names, like the
following example:
<informalexample><programlisting><![CDATA[
proxy = dbus_g_proxy_new_for_name (system_bus_connection,
"org.freedesktop.Accounts",
"/org/freedesktop/Accounts",
"org.freedesktop.Accounts");
]]>
</programlisting></informalexample>
For a #DBusGProxy constructed like this, method calls will be sent to
the current owner of the name, and that owner can change over time.
</para>
<para>
The same can be achieved with #GDBusProxy:
<informalexample><programlisting><![CDATA[
error = NULL;
proxy = g_dbus_proxy_new_for_bus_sync (G_BUS_TYPE_SYSTEM,
G_DBUS_PROXY_FLAGS_NONE,
NULL, /* GDBusInterfaceInfo */
"org.freedesktop.Accounts",
"/org/freedesktop/Accounts",
"org.freedesktop.Accounts",
NULL, /* GCancellable */
&error);
]]>
</programlisting></informalexample>
For an added layer of safety, you can specify what D-Bus
interface the proxy is expected to conform to by using the
#GDBusInterfaceInfo type. Additionally, #GDBusProxy loads,
caches and tracks changes to the D-Bus properties on the remote
object. It also sets up match rules so D-Bus signals from the
remote object are delivered locally.
</para>
<para>
The #GDBusProxy type normally isn't used directly - instead
proxies subclassing #GDBusProxy generated by <command><link
linkend="gdbus-codegen">gdbus-codegen</link></command> is used, see <xref linkend="gdbus-example-gdbus-codegen"/>
</para>
</section>
<section>
<title>Generating code and docs</title>
<section id="gdbus-example-gdbus-codegen">
<title>Using gdbus-codegen</title>
<para>
dbus-glib comes with <command>dbus-binding-tool</command>, which
can produce somewhat nice client- and server-side wrappers for a D-Bus interface.
With GDBus, <command><link
linkend="gdbus-codegen">gdbus-codegen</link></command> is used and like
its counterpart, it also takes D-Bus Introspection XML as input:
</para>
<example id="gdbus-example-codegen-input"><title>Example D-Bus Introspection XML</title><programlisting><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" href="../../../../../gio/tests/gdbus-object-manager-example/gdbus-example-objectmanager.xml"><xi:fallback>FIXME: MISSING XINCLUDE CONTENT: gdbus-example-objectmanager.xml</xi:fallback></xi:include></programlisting></example>
<para>
If this XML is processed like this
<informalexample><programlisting><![CDATA[
gdbus-codegen --interface-prefix org.gtk.GDBus.Example.ObjectManager. \
--generate-c-code generated-code \
--c-namespace Example \
--c-generate-object-manager \
--generate-docbook generated-docs \
gdbus-example-objectmanager.xml
]]></programlisting></informalexample>
then two files <filename>generated-code.h</filename> and
<filename>generated-code.c</filename> are
generated. Additionally, two XML files
<filename>generated-docs-org.gtk.GDBus.Example.ObjectManager.Animal</filename> and
<filename>generated-docs-org.gtk.GDBus.Example.ObjectManager.Cat</filename>
with Docbook XML are generated. For an example of what the docs look
like see <link
linkend="gdbus-interface-org-gtk-GDBus-Example-ObjectManager-Animal">the Animal D-Bus interface documentation</link>.
and
<link
linkend="gdbus-interface-org-gtk-GDBus-Example-ObjectManager-Cat">the Cat D-Bus interface documentation</link>.
</para>
<para>
While the contents of <filename>generated-code.h</filename> and
<filename>generated-code.c</filename> are best described by the
<command><link
linkend="gdbus-codegen">gdbus-codegen</link></command> manual
page, brief examples of how this generated code can be used can be found in
<xref linkend="gdbus-example-codegen-server"/>
and <xref
linkend="gdbus-example-codegen-client"/>. Additionally, since
the generated code has 100% gtk-doc coverage, see
#ExampleAnimal, #ExampleCat, #ExampleObject and
#ExampleObjectManagerClient pages for documentation.
</para>
<example id="gdbus-example-codegen-server"><title>Server-side application using generated code</title><programlisting><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" href="../../../../../gio/tests/gdbus-example-objectmanager-server.c"><xi:fallback>FIXME: MISSING XINCLUDE CONTENT: gdbus-example-objectmanager-server.c</xi:fallback></xi:include></programlisting></example>
<example id="gdbus-example-codegen-client"><title>Client-side application using generated code</title><programlisting><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" href="../../../../../gio/tests/gdbus-example-objectmanager-client.c"><xi:fallback>FIXME: MISSING XINCLUDE CONTENT: gdbus-example-objectmanager-client.c</xi:fallback></xi:include></programlisting></example>
</section>
<!-- All XInclude paths are relative to the html/ directory under the build root directory -->
<xi:include href="../../../../gio/tests/gdbus-object-manager-example/objectmanager-gen-org.gtk.GDBus.Example.ObjectManager.Animal.xml"><xi:fallback>FIXME: MISSING XINCLUDE CONTENT: objectmanager-gen-org.gtk.GDBus.Example.ObjectManager.Animal.xml</xi:fallback></xi:include>
<xi:include href="../../../../gio/tests/gdbus-object-manager-example/objectmanager-gen-org.gtk.GDBus.Example.ObjectManager.Cat.xml"><xi:fallback>FIXME: MISSING XINCLUDE CONTENT: objectmanager-gen-org.gtk.GDBus.Example.ObjectManager.Cat.xml</xi:fallback></xi:include>
<xi:include href="../gdbus-object-manager-example/xml/ExampleAnimal.xml"><xi:fallback>FIXME: MISSING XINCLUDE CONTENT: ExampleAnimal.xml</xi:fallback></xi:include>
<xi:include href="../gdbus-object-manager-example/xml/ExampleCat.xml"><xi:fallback>FIXME: MISSING XINCLUDE CONTENT: ExampleCat.xml</xi:fallback></xi:include>
<xi:include href="../gdbus-object-manager-example/xml/ExampleObject.xml"><xi:fallback>FIXME: MISSING XINCLUDE CONTENT: ExampleObject.xml</xi:fallback></xi:include>
<xi:include href="../gdbus-object-manager-example/xml/ExampleObjectManagerClient.xml"><xi:fallback>FIXME: MISSING XINCLUDE CONTENT: ExampleObjectManagerClient.xml</xi:fallback></xi:include>
</section>
</chapter>

View file

@ -0,0 +1,133 @@
<chapter>
<title>Migrating from GnomeVFS to GIO</title>
<table id="gnome-vfs-vs-gio">
<title>Comparison of GnomeVFS and GIO concepts</title>
<tgroup cols="2">
<thead>
<row><entry>GnomeVFS</entry><entry>GIO</entry></row>
</thead>
<tbody>
<row><entry>GnomeVFSURI</entry><entry>GFile</entry></row>
<row><entry>GnomeVFSFileInfo</entry><entry>GFileInfo</entry></row>
<row><entry>GnomeVFSResult</entry><entry>GError, with G_IO_ERROR values</entry></row>
<row><entry>GnomeVFSHandle &amp; GnomeVFSAsyncHandle</entry><entry>GInputStream or GOutputStream</entry></row>
<row><entry>GnomeVFSDirectoryHandle</entry><entry>GFileEnumerator</entry></row>
<row><entry>mime type</entry><entry>content type</entry></row>
<row><entry>GnomeVFSMonitor</entry><entry>GFileMonitor</entry></row>
<row><entry>GnomeVFSVolumeMonitor</entry><entry>GVolumeMonitor</entry></row>
<row><entry>GnomeVFSVolume</entry><entry>GMount</entry></row>
<row><entry>GnomeVFSDrive</entry><entry>GVolume</entry></row>
<row><entry>-</entry><entry>GDrive</entry></row>
<row><entry>GnomeVFSContext</entry><entry>GCancellable</entry></row>
<row><entry>gnome_vfs_async_cancel</entry><entry>g_cancellable_cancel</entry></row>
</tbody>
</tgroup>
</table>
<section>
<title>Trash handling</title>
<para>
The handling of trashed files has been changed in GIO, compared
to gnome-vfs. gnome-vfs has a home-grown trash implementation that
predates the freedesktop.org <ulink url="http://www.freedesktop.org/wiki/Specifications/trash-spec">Desktop Trash Can</ulink> specification
that is implemented in GIO. The location for storing trashed files
has changed from <filename>$HOME/.Trash</filename> to
<filename>$HOME/.local/share/Trash</filename> (or more correctly
<filename>$XDG_DATA_HOME/Trash</filename>), which means that
there is a need for migrating files that have been trashed by
gnome-vfs to the new location.
</para>
<para>
In gnome-vfs, the <filename>trash://</filename> scheme offering a
merged view of all trash directories was implemented in nautilus,
and trash-handling applications had to find and monitor all trash
directories themselves. With GIO, the <filename>trash://</filename>
implementation has been moved to gvfs and applications can simply
monitor that location:
</para>
<informalexample><programlisting>
static void
file_changed (GFileMonitor *file_monitor,
GFile *child,
GFile *other_file,
GFileMonitorEvent event_type,
gpointer user_data)
{
switch (event_type)
{
case G_FILE_MONITOR_EVENT_DELETED:
g_print ("'%s' removed from trash\n", g_file_get_basename (child));
break;
case G_FILE_MONITOR_EVENT_CREATED:
g_print ("'%s' added to trash\n", g_file_get_basename (child));
break;
default: ;
}
}
static void
start_monitoring_trash (void)
{
GFile *file;
GFileMonitor *monitor;
file = g_file_new_for_uri ("trash://");
monitor = g_file_monitor_directory (file, 0, NULL, NULL);
g_object_unref (file);
g_signal_connect (monitor, "changed", G_CALLBACK (file_changed), NULL);
/* ... */
}
</programlisting></informalexample>
<para>
GIO exposes some useful metadata about trashed files. There are
trash::orig-path and trash::deletion-date attributes. The
standard::icon attribute of the <filename>trash://</filename>
itself provides a suitable icon for displaying the trash can on
the desktop. If you are using this icon, make sure to monitor
this attribute for changes, since the icon may be updated to
reflect that state of the trash can.
</para>
<para>
Moving a file to the trash is much simpler with GIO. Instead of
using gnome_vfs_find_directory() with %GNOME_VFS_DIRECTORY_KIND_TRASH
to find out where to move the trashed file, just use the g_file_trash()
function.
</para>
</section>
<section>
<title>Operations on multiple files</title>
<para>
gnome-vfs has the dreaded gnome_vfs_xfer_uri_list() function which
has tons of options and offers the equivalent of cp, mv, ln, mkdir
and rm at the same time.
</para>
<para>
GIO offers a much simpler I/O scheduler functionality instead, that
lets you schedule a function to be called in a separate thread, or
if threads are not available, as an idle in the mainloop.
See g_io_scheduler_push_job().
</para>
</section>
<section>
<title>Mime monitoring</title>
<para>
gnome-vfs offered a way to monitor the association between mime types
and default handlers for changes, with the #GnomeVFSMIMEMonitor object.
GIO does not offer a replacement for this functionality at this time,
since we have not found a compelling use case where
#GnomeVFSMIMEMonitor was used. If you think you have such a use
case, please report it at
<ulink url="https://gitlab.gnome.org/GNOME/glib/issues/new">https://gitlab.gnome.org/GNOME/glib/issues/new</ulink>.
</para>
</section>
</chapter>

View file

@ -0,0 +1,27 @@
<part id="migrating">
<title>Migrating to GIO</title>
<chapter>
<title>Migrating from POSIX to GIO</title>
<table id="posix-vs-gio">
<title>Comparison of POSIX and GIO concepts</title>
<tgroup cols="2">
<thead>
<row><entry>POSIX</entry><entry>GIO</entry></row>
</thead>
<tbody>
<row><entry>char *path</entry><entry>GFile *file</entry></row>
<row><entry>struct stat *buf</entry><entry>GFileInfo *info</entry></row>
<row><entry>struct statvfs *buf</entry><entry>GFileInfo *info</entry></row>
<row><entry morerows="1">int fd</entry><entry>GInputStream *in</entry></row>
<row><entry>GOutputStream *out</entry></row>
<row><entry>DIR *</entry><entry>GFileEnumerator *enum</entry></row>
<row><entry>fstab entry</entry><entry>GUnixMountPoint *mount_point</entry></row>
<row><entry>mtab entry</entry><entry>GUnixMountEntry *mount_entry</entry></row>
</tbody>
</tgroup>
</table>
</chapter>
</part>

View file

@ -0,0 +1,745 @@
<part>
<title>GIO Overview</title>
<chapter>
<title>Introduction</title>
<para>
GIO is striving to provide a modern, easy-to-use VFS API that sits
at the right level in the library stack, as well as other generally
useful APIs for desktop applications (such as networking and
D-Bus support). The goal is to overcome the shortcomings of GnomeVFS
and provide an API that is so good that developers prefer it over raw
POSIX calls. Among other things that means using GObject. It also means
not cloning the POSIX API, but providing higher-level, document-centric
interfaces.
</para>
<para>
The abstract file system model of GIO consists of a number of
interfaces and base classes for I/O and files:
<variablelist>
<varlistentry>
<term>GFile</term>
<listitem><para>reference to a file</para></listitem>
</varlistentry>
<varlistentry>
<term>GFileInfo</term>
<listitem><para>information about a file or filesystem</para></listitem>
</varlistentry>
<varlistentry>
<term>GFileEnumerator</term>
<listitem><para>list files in directories</para></listitem>
</varlistentry>
<varlistentry>
<term>GDrive</term>
<listitem><para>represents a drive</para></listitem>
</varlistentry>
<varlistentry>
<term>GVolume</term>
<listitem><para>represents a file system in an abstract way</para></listitem>
</varlistentry>
<varlistentry>
<term>GMount</term>
<listitem><para>represents a mounted file system</para></listitem>
</varlistentry>
</variablelist>
Then there is a number of stream classes, similar to the input and
output stream hierarchies that can be found in frameworks like Java:
<variablelist>
<varlistentry>
<term>GInputStream</term>
<listitem><para>read data</para></listitem>
</varlistentry>
<varlistentry>
<term>GOutputStream</term>
<listitem><para>write data</para></listitem>
</varlistentry>
<varlistentry>
<term>GIOStream</term>
<listitem><para>read and write data</para></listitem>
</varlistentry>
<varlistentry>
<term>GSeekable</term>
<listitem><para>interface optionally implemented by streams to support seeking</para></listitem>
</varlistentry>
</variablelist>
There are interfaces related to applications and the types
of files they handle:
<variablelist>
<varlistentry>
<term>GAppInfo</term>
<listitem><para>information about an installed application</para></listitem>
</varlistentry>
<varlistentry>
<term>GIcon</term>
<listitem><para>abstract type for file and application icons</para></listitem>
</varlistentry>
</variablelist>
There is a framework for storing and retrieving application settings:
<variablelist>
<varlistentry>
<term>GSettings</term>
<listitem><para>stores and retrieves application settings</para></listitem>
</varlistentry>
</variablelist>
There is support for network programming, including connectivity monitoring,
name resolution, lowlevel socket APIs and highlevel client and server
helper classes:
<variablelist>
<varlistentry>
<term>GSocket</term>
<listitem><para>lowlevel platform independent socket object</para></listitem>
</varlistentry>
<varlistentry>
<term>GResolver</term>
<listitem><para>asynchronous and cancellable DNS resolver</para></listitem>
</varlistentry>
<varlistentry>
<term>GSocketClient</term>
<listitem><para>high-level network client helper</para></listitem>
</varlistentry>
<varlistentry>
<term>GSocketService</term>
<listitem><para>high-level network server helper</para></listitem>
</varlistentry>
<varlistentry>
<term>GSocketConnection</term>
<listitem><para>network connection stream</para></listitem>
</varlistentry>
<varlistentry>
<term>GNetworkMonitor</term>
<listitem><para>network connectivity monitoring</para></listitem>
</varlistentry>
</variablelist>
There is support for connecting to <ulink url="http://www.freedesktop.org/wiki/Software/dbus">D-Bus</ulink>,
sending and receiving messages, owning and watching bus names,
and making objects available on the bus:
<variablelist>
<varlistentry>
<term>GDBusConnection</term>
<listitem><para>a D-Bus connection</para></listitem>
</varlistentry>
<varlistentry>
<term>GDBusMethodInvocation</term>
<listitem><para>for handling remote calls</para></listitem>
</varlistentry>
<varlistentry>
<term>GDBusServer</term>
<listitem><para>helper for accepting connections</para></listitem>
</varlistentry>
<varlistentry>
<term>GDBusProxy</term>
<listitem><para>proxy to access D-Bus interfaces on a remote object</para></listitem>
</varlistentry>
</variablelist>
Beyond these, GIO provides facilities for file monitoring,
asynchronous I/O and filename completion. In addition to the
interfaces, GIO provides implementations for the local case.
Implementations for various network file systems are provided
by the GVFS package as loadable modules.
</para>
<para>
Other design choices which consciously break with the GnomeVFS
design are to move backends out-of-process, which minimizes the
dependency bloat and makes the whole system more robust. The backends
are not included in GIO, but in the separate GVFS package. The GVFS
package also contains the GVFS daemon, which spawn further mount
daemons for each individual connection.
</para>
<figure id="gvfs-overview">
<title>GIO in the GTK+ library stack</title>
<graphic fileref="gvfs-overview.png" format="PNG"></graphic>
</figure>
<para>
The GIO model of I/O is stateful: if an application establishes e.g.
a SFTP connection to a server, it becomes available to all applications
in the session; the user does not have to enter their password over
and over again.
</para>
<para>
One of the big advantages of putting the VFS in the GLib layer
is that GTK+ can directly use it, e.g. in the filechooser.
</para>
</chapter>
<chapter>
<title>Writing GIO applications</title>
<para>
The information in the GLib <ulink url="http://developer.gnome.org/glib/stable/glib-programming.html">documentation</ulink> about writing GLib
applications is generally applicable when writing GIO applications.
</para>
<simplesect><title>Threads</title>
<para>
GDBus has its own private worker thread, so applications using
GDBus have at least 3 threads. GIO makes heavy use of the concept
of a <link linkend="g-main-context-push-thread-default">thread-default
main context</link> to execute callbacks of asynchronous
methods in the same context in which the operation was started.
</para>
</simplesect>
<simplesect id="async-programming"><title>Asynchronous Programming</title>
<para>
Many GIO functions come in two versions: synchronous and asynchronous,
denoted by an <code>_async</code> suffix. It is important to use these
appropriately: synchronous calls should not be used from
within a main loop which is shared with other code, such as one in the
applications main thread. Synchronous calls block until they complete,
and I/O operations can take noticeable amounts of time (even on fast
SSDs). Blocking a main loop iteration while waiting for I/O means that
other sources in the main loop will not be dispatched, such as input and
redraw handlers for the applications UI. This can cause the application
to freeze until I/O completes.
</para>
<para>
A few self-contained groups of functions, such as code generated by
<link linkend="gdbus-codegen"><application>gdbus-codegen</application></link>,
use a different convention: functions are asynchronous default, and it is
the <emphasis>synchronous</emphasis> version which has a
<code>_sync</code>
suffix. Aside from naming differences, they should be treated the same
way as functions following the normal convention above.
</para>
<para>
The asynchronous (<code>_async</code>) versions of functions return
control to the caller immediately, after scheduling the I/O in the kernel
and adding a callback for it to the main loop. This callback will be
invoked when the operation has completed. From the callback, the paired
<code>_finish</code> function should be called to retrieve the return
value of the I/O operation, and any errors which occurred. For more
information on using and implementing asynchronous functions, see
<link linkend="GAsyncResult.description"><type>GAsyncResult</type></link>
and <link linkend="GTask.description"><type>GTask</type></link>.
</para>
<para>
By starting multiple asynchronous operations in succession, they will be
executed in parallel (up to an arbitrary limit imposed by GIOs internal
worker thread pool).
</para>
<para>
The synchronous versions of functions can be used early in application
startup when there is no main loop to block, for example to load initial
configuration files. They can also be used for I/O on files which are
guaranteed to be small and on the local disk. Note that the users home
directory is not guaranteed to be on the local disk.
</para>
</simplesect>
<simplesect><title>Security</title>
<para>
When your program needs to carry out some privileged operation (say,
create a new user account), there are various ways in which you can go
about this:
<itemizedlist>
<listitem><para>
Implement a daemon that offers the privileged operation. A convenient
way to do this is as a D-Bus system-bus service. The daemon will probably
need ways to check the identity and authorization of the caller before
executing the operation. <ulink url="http://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html">polkit</ulink> is a framework that allows this.
</para></listitem>
<listitem><para>
Use a small helper that is executed with elevated privileges via
pkexec. <ulink url="http://www.freedesktop.org/software/polkit/docs/latest/pkexec.1.html">pkexec</ulink> is a small program launcher that is part of polkit.
</para></listitem>
<listitem><para>
Use a small helper that is executed with elevated privileges by
being suid root.
</para></listitem>
</itemizedlist>
None of these approaches is the clear winner, they all have their
advantages and disadvantages.
</para>
<para>
When writing code that runs with elevated privileges, it is important
to follow some basic rules of secure programming. David Wheeler has an
excellent book on this topic,
<ulink url="http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/index.html">Secure Programming for Linux and Unix HOWTO</ulink>.
</para>
<para>
When using GIO in code that runs with elevated privileges, you have to
be careful. GIO has extension points whose implementations get loaded
from modules (executable code in shared objects), which could allow
an attacker to sneak their own code into your application by tricking it
into loading the code as a module. However, GIO will never load modules
from your home directory except when explicitly asked to do so via an
environment variable.
</para>
<para>
In most cases, your helper program should be so small that you don't
need GIO, whose APIs are largely designed to support full-blown desktop
applications. If you can't resist the convenience of these APIs, here
are some steps you should take:
<itemizedlist>
<listitem><para>
Clear the environment, e.g. using the <function>clearenv()</function>
function.
David Wheeler has a good <ulink url="http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/environment-variables.html">explanation</ulink> for why it is
important to sanitize the environment.
See <xref linkend="running-gio-apps"/>
for a list of all environment variables affecting GIO. In particular,
<envar>PATH</envar> (used to locate binaries), <envar>GIO_EXTRA_MODULES</envar> (used to locate loadable modules) and <envar>DBUS_{SYSTEM,SESSION}_BUS_ADDRESS</envar> (used to locate the D-Bus system and session bus) are important.
</para></listitem>
<listitem><para>
Don't use GVfs, by setting <envar>GIO_USE_VFS=local</envar> in the environment.
The reason to avoid GVfs in security-sensitive programs is that it uses
many libraries which have not necessarily been audited for security problems.
Gvfs is also heavily distributed and relies on a session bus to be present.
</para></listitem>
</itemizedlist>
</para>
</simplesect>
</chapter>
<chapter>
<title>Compiling GIO applications</title>
<para>
GIO comes with a <filename>gio-2.0.pc</filename> file that you
should use together with <literal>pkg-config</literal> to obtain
the necessary information about header files and libraries. See
the <literal>pkg-config</literal> man page or the GLib documentation
for more information on how to use <literal>pkg-config</literal>
to compile your application.
</para>
<para>
If you are using GIO on UNIX-like systems, you may want to use
UNIX-specific GIO interfaces such as #GUnixInputStream,
#GUnixOutputStream, #GUnixMount or #GDesktopAppInfo.
To do so, use the <filename>gio-unix-2.0.pc</filename> file
instead of <filename>gio-2.0.pc</filename>
</para>
</chapter>
<chapter id="running-gio-apps">
<title>Running GIO applications</title>
<para>
GIO inspects a few environment variables in addition to the
ones used by GLib.
</para>
<formalpara>
<title><envar>XDG_DATA_HOME</envar>, <envar>XDG_DATA_DIRS</envar></title>
<para>
GIO uses these environment variables to locate MIME information.
For more information, see the <ulink url="http://freedesktop.org/Standards/shared-mime-info-spec">Shared MIME-info Database</ulink>
and the <ulink url="http://freedesktop.org/Standards/basedir-spec">Base Directory Specification</ulink>.
</para>
</formalpara>
<formalpara>
<title><envar>GVFS_DISABLE_FUSE</envar></title>
<para>
This variable can be set to keep #Gvfs from starting the fuse backend,
which may be unwanted or unnecessary in certain situations.
</para>
</formalpara>
<formalpara>
<title><envar>GIO_USE_VFS</envar></title>
<para>
This environment variable can be set to the name of a #GVfs
implementation to override the default for debugging purposes.
The #GVfs implementation for local files that is included in GIO
has the name "local", the implementation in the gvfs module has
the name "gvfs". Most commonly, system software will set this to "local"
to avoid having `GFile` APIs perform unnecessary D-Bus calls.
</para><para>
The special value <literal>help</literal> can be used to print a list of
available implementations to standard output.
</para>
</formalpara>
<para>
The following environment variables are only useful for debugging
GIO itself or modules that it loads. They should not be set in a
production environment.
</para>
<formalpara>
<title><envar>GIO_USE_FILE_MONITOR</envar></title>
<para>
This variable can be set to the name of a #GFileMonitor
implementation to override the default for debugging purposes.
The #GFileMonitor implementation for local files that is included
in GIO on Linux has the name <literal>inotify</literal>, others that are built
are built as modules (depending on the platform) are called
<literal>fam</literal> and <literal>fen</literal>.
</para><para>
The special value <literal>help</literal> can be used to print a list of
available implementations to standard output.
</para>
</formalpara>
<formalpara>
<title><envar>GIO_USE_VOLUME_MONITOR</envar></title>
<para>
This variable can be set to the name of a #GVolumeMonitor
implementation to override the default for debugging purposes.
The #GVolumeMonitor implementation for local files that is included
in GIO has the name "unix", the udisks2-based implementation in the
gvfs module has the name "udisks2".
</para><para>
The special value <literal>help</literal> can be used to print a list of
available implementations to standard output.
</para>
</formalpara>
<formalpara>
<title><envar>GIO_USE_TLS</envar></title>
<para>
This variable can be set to the name of a #GTlsBackend
implementation to override the default for debugging purposes.
GIO does not include a #GTlsBackend implementation, the gnutls-based
implementation in the glib-networking module has the name "gnutls".
</para><para>
The special value <literal>help</literal> can be used to print a list of
available implementations to standard output.
</para>
</formalpara>
<formalpara>
<title><envar>GIO_MODULE_DIR</envar></title>
<para>
When this environment variable is set to a path, GIO will load
modules from this alternate directory instead of the directory
built into GIO. This is useful when running tests, for example.
</para>
<para>
This environment variable is ignored when running in a setuid program.
</para>
</formalpara>
<formalpara>
<title><envar>GIO_EXTRA_MODULES</envar></title>
<para>
When this environment variable is set to a path, or a set of
paths separated by a colon, GIO will attempt to load
additional modules from within the path.
</para>
<para>
This environment variable is ignored when running in a setuid program.
</para>
</formalpara>
<formalpara>
<title><envar>GSETTINGS_BACKEND</envar></title>
<para>
This variable can be set to the name of a #GSettingsBackend
implementation to override the default for debugging purposes.
The memory-based implementation that is included in GIO has
the name "memory", the one in dconf has the name "dconf".
</para><para>
The special value <literal>help</literal> can be used to print a list of
available implementations to standard output.
</para>
</formalpara>
<formalpara>
<title><envar>GSETTINGS_SCHEMA_DIR</envar></title>
<para>
This variable can be set to the names of directories to consider when looking for compiled schemas for #GSettings,
in addition to the <filename>glib-2.0/schemas</filename>
subdirectories of the XDG system data dirs. To specify multiple directories, use <constant>G_SEARCHPATH_SEPARATOR_S</constant> as a separator.
</para>
</formalpara>
<formalpara>
<title><envar>DBUS_SYSTEM_BUS_ADDRESS</envar></title>
<para>
This variable is consulted to find the address of the D-Bus system
bus. For the format of D-Bus addresses, see the D-Bus
<ulink url="http://dbus.freedesktop.org/doc/dbus-specification.html#addresses">specification</ulink>.
</para>
<para>
Setting this variable overrides platform-specific ways of determining
the system bus address.
</para>
</formalpara>
<formalpara>
<title><envar>DBUS_SESSION_BUS_ADDRESS</envar></title>
<para>
This variable is consulted to find the address of the D-Bus session bus.
</para>
<para>
Setting this variable overrides platform-specific ways of determining
the session bus address.
</para>
</formalpara>
<formalpara>
<title><envar>DBUS_STARTER_BUS_TYPE</envar></title>
<para>
This variable is consulted to find out the 'starter' bus for an
application that has been started via D-Bus activation. The possible
values are 'system' or 'session'.
</para>
</formalpara>
<formalpara>
<title><envar>G_DBUS_DEBUG</envar></title>
<para>
This variable can be set to a list of debug options, which
cause GLib to print out different types of debugging
information when using the D-Bus routines.
<variablelist>
<varlistentry>
<term>transport</term>
<listitem><para>Show IO activity (e.g. reads and writes)</para></listitem>
</varlistentry>
<varlistentry>
<term>message</term>
<listitem><para>Show all sent and received D-Bus messages</para></listitem>
</varlistentry>
<varlistentry>
<term>payload</term>
<listitem><para>Show payload for all sent and received D-Bus messages (implies message)</para></listitem>
</varlistentry>
<varlistentry>
<term>call</term>
<listitem><para>Trace g_dbus_connection_call() and g_dbus_connection_call_sync() API usage</para></listitem>
</varlistentry>
<varlistentry>
<term>signal</term>
<listitem><para>Show when a D-Bus signal is received</para></listitem>
</varlistentry>
<varlistentry>
<term>incoming</term>
<listitem><para>Show when an incoming D-Bus method call is received</para></listitem>
</varlistentry>
<varlistentry>
<term>return</term>
<listitem><para>Show when a reply is returned via the #GDBusMethodInvocation API</para></listitem>
</varlistentry>
<varlistentry>
<term>emission</term>
<listitem><para>Trace g_dbus_connection_emit_signal() API usage</para></listitem>
</varlistentry>
<varlistentry>
<term>authentication</term>
<listitem><para>Show information about connection authentication</para></listitem>
</varlistentry>
<varlistentry>
<term>address</term>
<listitem><para>Show information about D-Bus address lookups and autolaunching</para></listitem>
</varlistentry>
</variablelist>
The special value <literal>all</literal> can be used to turn
on all debug options. The special value
<literal>help</literal> can be used to print a list of
supported options to standard output.
</para>
</formalpara>
<formalpara>
<title><envar>G_DBUS_COOKIE_SHA1_KEYRING_DIR</envar></title>
<para>
Can be used to override the directory used to store the
keyring used in the <literal>DBUS_COOKIE_SHA1</literal>
authentication mechanism. Normally the directory used is
<filename>.dbus-keyrings</filename> in the user's home
directory.
</para>
</formalpara>
<formalpara>
<title><envar>G_DBUS_COOKIE_SHA1_KEYRING_DIR_IGNORE_PERMISSION</envar></title>
<para>
If set, the permissions of the directory used to store the
keyring used in the <literal>DBUS_COOKIE_SHA1</literal>
authentication mechanism won't be checked. Normally the
directory must be readable only by the user.
</para>
</formalpara>
</chapter>
<chapter id="extending-gio">
<title>Extending GIO</title>
<para>
A lot of the functionality that is accessible through GIO
is implemented in loadable modules, and modules provide a convenient
way to extend GIO. In addition to the #GIOModule API which supports
writing such modules, GIO has a mechanism to define extension points,
and register implementations thereof, see #GIOExtensionPoint.
</para>
<para>
The following extension points are currently defined by GIO:
</para>
<formalpara>
<title>G_VFS_EXTENSION_POINT_NAME</title>
<para>
Allows to override the functionality of the #GVfs class.
Implementations of this extension point must be derived from #GVfs.
GIO uses the implementation with the highest priority that is active,
see g_vfs_is_active().
</para>
<para>
GIO implements this extension point for local files, gvfs contains
an implementation that supports all the backends in gvfs.
</para>
</formalpara>
<formalpara>
<title>G_VOLUME_MONITOR_EXTENSION_POINT_NAME</title>
<para>
Allows to add more volume monitors.
Implementations of this extension point must be derived from
#GVolumeMonitor. GIO uses all registered extensions.
</para>
<para>
gvfs contains an implementation that works together with the #GVfs
implementation in gvfs.
</para>
</formalpara>
<formalpara>
<title>G_NATIVE_VOLUME_MONITOR_EXTENSION_POINT_NAME</title>
<para>
Allows to override the 'native' volume monitor.
Implementations of this extension point must be derived from
#GNativeVolumeMonitor. GIO uses the implementation with
the highest priority that is supported, as determined by the
is_supported() vfunc in #GVolumeMonitorClass.
</para>
<para>
GIO implements this extension point for local mounts,
gvfs contains a udisks2-based implementation.
</para>
</formalpara>
<formalpara>
<title>G_LOCAL_FILE_MONITOR_EXTENSION_POINT_NAME</title>
<para>
Allows to override the file monitor implementation for
local files. Implementations of this extension point must
be derived from #GLocalFileMonitor. GIO uses the implementation
with the highest priority that is supported, as determined by the
is_supported() vfunc in #GLocalFileMonitorClass.
</para>
<para>
GIO uses this extension point internally, to switch between
its fam-based and inotify-based file monitoring implementations.
</para>
</formalpara>
<formalpara>
<title>G_DESKTOP_APP_INFO_LOOKUP_EXTENSION_POINT_NAME</title>
<para>
Unix-only. Allows to provide a way to associate default handlers
with URI schemes. Implementations of this extension point must
implement the #GDesktopAppInfoLookup interface. GIO uses the
implementation with the highest priority.
</para>
<para>
This extension point has been discontinued in GLib 2.28. It is
still available to keep API and ABI stability, but GIO is no
longer using it for default handlers. Instead, the mime handler
mechanism is used, together with x-scheme-handler pseudo-mimetypes.
</para>
</formalpara>
<formalpara>
<title>G_SETTINGS_BACKEND_EXTENSION_POINT_NAME</title>
<para>
Allows to provide an alternative storage for #GSettings.
Implementations of this extension point must derive from the
#GSettingsBackend type. GIO contains a keyfile-based
implementation of this extension point, another one is provided
by dconf.
</para>
</formalpara>
<formalpara>
<title>G_PROXY_EXTENSION_POINT_NAME</title>
<para>
Allows to provide implementations for network proxying.
Implementations of this extension point must provide the
#GProxy interface, and must be named after the network
protocol they are proxying.
</para>
<para>
glib-networking contains an implementation of this extension
point based on libproxy.
</para>
</formalpara>
<formalpara>
<title>G_TLS_BACKEND_EXTENSION_POINT_NAME</title>
<para>
Allows to provide implementations for TLS support.
Implementations of this extension point must implement
the #GTlsBackend interface.
</para>
<para>
glib-networking contains an implementation of this extension
point.
</para>
</formalpara>
<formalpara>
<title>G_NETWORK_MONITOR_EXTENSION_POINT_NAME</title>
<para>
Allows to provide implementations for network connectivity
monitoring.
Implementations of this extension point must implement
the #GNetworkMonitorInterface interface.
</para>
<para>
GIO contains an implementation of this extension point
that is using the netlink interface of the Linux kernel.
</para>
</formalpara>
</chapter>
</part>

View file

@ -0,0 +1 @@
@VERSION@

View file

@ -0,0 +1,8 @@
<!ENTITY package "@PACKAGE@">
<!ENTITY package_bugreport "@PACKAGE_BUGREPORT@">
<!ENTITY package_name "@PACKAGE_NAME@">
<!ENTITY package_string "@PACKAGE_STRING@">
<!ENTITY package_tarname "@PACKAGE_TARNAME@">
<!ENTITY package_url "@PACKAGE_URL@">
<!ENTITY package_version "@PACKAGE_VERSION@">
<!ENTITY package_api_version "@PACKAGE_API_VERSION@">

View file

@ -0,0 +1,14 @@
ent_conf = configuration_data()
ent_conf.set('PACKAGE', 'glib')
ent_conf.set('PACKAGE_BUGREPORT', 'https://gitlab.gnome.org/GNOME/glib/issues/new')
ent_conf.set('PACKAGE_NAME', 'glib')
ent_conf.set('PACKAGE_STRING', 'glib')
ent_conf.set('PACKAGE_TARNAME', 'glib')
ent_conf.set('PACKAGE_URL', 'FIXME')
ent_conf.set('PACKAGE_VERSION', glib_version)
ent_conf.set('PACKAGE_API_VERSION', glib_api_version)
configure_file(
input: 'gtkdocentities.ent.in',
output: 'gtkdocentities.ent',
configuration: ent_conf
)

View file

@ -0,0 +1,134 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 16.0.0, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
width="266px" height="212px" viewBox="0 0 266 212" enable-background="new 0 0 266 212" xml:space="preserve">
<g>
<g>
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" x1="27.23" y1="23.192" x2="29.23" y2="23.192"/>
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" stroke-dasharray="3.9562,3.9562" x1="33.187" y1="23.192" x2="236.932" y2="23.192"/>
<polyline fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" points="238.91,23.192 240.91,23.192
238.97,23.677 "/>
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" stroke-dasharray="3.9907,3.9907" x1="235.099" y1="24.646" x2="27.971" y2="76.427"/>
<polyline fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" points="26.035,76.912 24.095,77.396
26.095,77.396 "/>
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" stroke-dasharray="4.0154,4.0154" x1="30.11" y1="77.396" x2="236.902" y2="77.396"/>
<polyline fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" points="238.91,77.396 240.91,77.396
238.97,77.881 "/>
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" stroke-dasharray="3.9907,3.9907" x1="235.099" y1="78.85" x2="27.971" y2="130.631"/>
<polyline fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" points="26.035,131.114 24.095,131.6
26.095,131.6 "/>
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" stroke-dasharray="4.0154,4.0154" x1="30.11" y1="131.6" x2="236.902" y2="131.6"/>
<polyline fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" points="238.91,131.6 240.91,131.6
238.97,132.085 "/>
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" stroke-dasharray="3.9907,3.9907" x1="235.099" y1="133.053" x2="27.971" y2="184.835"/>
<polyline fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" points="26.035,185.318 24.095,185.804
26.095,185.804 "/>
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" stroke-dasharray="4.0086,4.0086" x1="30.104" y1="185.804" x2="228.53" y2="185.804"/>
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" x1="230.534" y1="185.804" x2="232.534" y2="185.804"/>
<g>
<rect x="24.095" y="19.892" width="6.602" height="6.602"/>
</g>
<g>
<path d="M238.569,185.804c-2.84,1.054-6.363,2.852-8.548,4.756l1.721-4.756l-1.721-4.755
C232.206,182.953,235.729,184.751,238.569,185.804z"/>
</g>
</g>
</g>
<g id="graph0">
<title>sorted_binary_tree</title>
<g id="node1">
<title>C</title>
<ellipse fill="#FFFFFF" stroke="#000000" cx="60.23" cy="185.804" rx="18.067" ry="18.067"/>
<text transform="matrix(1 0 0 1 55.5435 190.8223)" font-family="'Times-Roman'" font-size="14.0528">C</text>
</g>
<g id="node2">
<title>E</title>
<ellipse fill="#FFFFFF" stroke="#000000" cx="132.502" cy="185.804" rx="18.067" ry="18.067"/>
<text transform="matrix(1 0 0 1 128.21 190.8223)" font-family="'Times-Roman'" font-size="14.0528">E</text>
</g>
<g id="node3">
<title>H</title>
<ellipse fill="#FFFFFF" stroke="#000000" cx="204.773" cy="185.804" rx="17.064" ry="18.067"/>
<text transform="matrix(1 0 0 1 199.6992 190.8223)" font-family="'Times-Roman'" font-size="14.0528">H</text>
</g>
<g id="node4">
<title>A</title>
<ellipse fill="#FFFFFF" stroke="#000000" cx="24.094" cy="131.6" rx="17.064" ry="18.068"/>
<text transform="matrix(1 0 0 1 19.02 136.6191)" font-family="'Times-Roman'" font-size="14.0528">A</text>
</g>
<g id="node5">
<title>D</title>
<ellipse fill="#FFFFFF" stroke="#000000" cx="96.366" cy="131.6" rx="17.064" ry="18.068"/>
<text transform="matrix(1 0 0 1 91.292 136.6191)" font-family="'Times-Roman'" font-size="14.0528">D</text>
</g>
<g id="edge6">
<title>D-&gt;C</title>
<path fill="none" stroke="#000000" d="M86.328,147.66c-3.011,4.016-7.026,9.034-10.038,14.053"/>
<polygon stroke="#000000" points="78.298,164.725 70.268,170.747 73.279,160.709 "/>
</g>
<g id="edge8">
<title>D-&gt;E</title>
<path fill="none" stroke="#000000" d="M106.404,147.66c3.011,4.016,7.026,9.034,10.038,14.053"/>
<polygon stroke="#000000" points="119.453,160.709 122.464,170.747 114.434,164.725 "/>
</g>
<g id="node6">
<title>I</title>
<ellipse fill="#FFFFFF" stroke="#000000" cx="240.909" cy="131.6" rx="18.068" ry="18.068"/>
<text transform="matrix(1 0 0 1 238.5693 136.6191)" font-family="'Times-Roman'" font-size="14.0528">I</text>
</g>
<g id="edge12">
<title>I-&gt;H</title>
<path fill="none" stroke="#000000" d="M230.871,146.656c-3.011,5.02-6.021,10.038-10.037,15.057"/>
<polygon stroke="#000000" points="223.846,163.721 214.812,169.743 217.822,159.705 "/>
</g>
<g id="node7">
<title>B</title>
<ellipse fill="#FFFFFF" stroke="#000000" cx="60.23" cy="77.396" rx="18.068" ry="18.068"/>
<text transform="matrix(1 0 0 1 55.5435 82.415)" font-family="'Times-Roman'" font-size="14.0528">B</text>
</g>
<g id="edge3">
<title>B-&gt;A</title>
<path fill="none" stroke="#000000" d="M50.192,92.453c-3.011,5.019-6.022,10.038-10.038,15.057"/>
<polygon stroke="#000000" points="43.166,109.518 34.132,115.539 37.144,105.502 "/>
</g>
<g id="edge5">
<title>B-&gt;D</title>
<path fill="none" stroke="#000000" d="M70.268,92.453c3.011,5.019,6.022,10.038,10.038,15.057"/>
<polygon stroke="#000000" points="83.317,105.502 86.328,115.539 77.294,109.518 "/>
</g>
<g id="node8">
<title>G</title>
<ellipse fill="#FFFFFF" stroke="#000000" cx="204.773" cy="77.396" rx="17.064" ry="18.068"/>
<text transform="matrix(1 0 0 1 199.6992 82.415)" font-family="'Times-Roman'" font-size="14.0528">G</text>
</g>
<g id="edge11">
<title>G-&gt;I</title>
<path fill="none" stroke="#000000" d="M214.812,93.457c3.011,4.015,7.026,9.034,10.038,14.053"/>
<polygon stroke="#000000" points="227.86,106.506 230.871,116.543 222.842,110.521 "/>
</g>
<g id="node9">
<title>F</title>
<ellipse fill="#FFFFFF" stroke="#000000" cx="132.502" cy="23.192" rx="18.068" ry="18.068"/>
<text transform="matrix(1 0 0 1 128.5942 28.2109)" font-family="'Times-Roman'" font-size="14.0528">F</text>
</g>
<g id="edge2">
<title>F-&gt;B</title>
<path fill="none" stroke="#000000" d="M117.445,34.234c-11.042,8.03-23.087,17.064-34.128,26.098"/>
<polygon stroke="#000000" points="85.325,63.343 75.287,66.354 81.31,57.321 "/>
</g>
<g id="edge10">
<title>F-&gt;G</title>
<path fill="none" stroke="#000000" d="M147.559,34.234c11.041,8.03,23.087,17.064,34.129,26.098"/>
<polygon stroke="#000000" points="183.694,57.321 189.717,66.354 179.68,63.343 "/>
</g>
</g>
</svg>

After

Width:  |  Height:  |  Size: 7.1 KiB

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 36 KiB

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 36 KiB

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 36 KiB

View file

@ -0,0 +1,365 @@
<?xml version="1.0"?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
]>
<refentry id="glib-building">
<refmeta>
<refentrytitle>Compiling the GLib package</refentrytitle>
<manvolnum>3</manvolnum>
<refmiscinfo>GLib Library</refmiscinfo>
</refmeta>
<refnamediv>
<refname>Compiling the GLib Package</refname>
<refpurpose>How to compile GLib itself</refpurpose>
</refnamediv>
<refsect1 id="building">
<title>Building the Library on UNIX</title>
<para>
On UNIX, GLib uses the standard <application>Meson</application> build
system. The normal sequence for compiling and installing the GLib library
is thus:
<literallayout>
<userinput>meson _build</userinput>
<userinput>ninja -C _build</userinput>
<userinput>ninja -C _build install</userinput>
</literallayout>
On FreeBSD:
<literallayout>
<userinput>env CPPFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib -Wl,--disable-new-dtags" meson -Dxattr=false -Dinstalled_tests=true -Diconv=external -Db_lundef=false _build</userinput>
<userinput>ninja -C _build</userinput>
</literallayout>
</para>
<para>
The standard options provided by <application>Meson</application> may be
passed to the <command>meson</command> command. Please see the
<application>Meson</application> documentation or run
<command>meson configure --help</command> for information about
the standard options.
</para>
<para>
GLib is compiled with
<ulink url="https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fstrict-aliasing">strict aliasing</ulink>
disabled. It is strongly recommended that this is not re-enabled by
overriding the compiler flags, as GLib has not been tested with strict
aliasing and cannot be guaranteed to work.
</para>
<para>
The GTK+ documentation contains
<ulink url="https://developer.gnome.org/gtk3/stable/gtk-building.html">further details</ulink>
about the build process and ways to influence it.
</para>
</refsect1>
<refsect1 id="dependencies">
<title>Dependencies</title>
<para>
Before you can compile the GLib library, you need to have
various other tools and libraries installed on your system.
If you are building from a release archive, you will need
<ulink url="https://wiki.gnome.org/Projects/GLib/CompilerRequirements">a compliant C toolchain</ulink>,
<application>Meson</application>, and <application>pkg-config</application>;
the requirements are the same when building from a Git repository clone
of GLib.
</para>
<itemizedlist>
<listitem>
<para>
<ulink url="https://www.freedesktop.org/wiki/Software/pkg-config/">pkg-config</ulink>
is a tool for tracking the compilation flags needed for
libraries that are used by the GLib library. (For each
library, a small <literal>.pc</literal> text file is
installed in a standard location that contains the compilation
flags needed for that library along with version number
information).
</para>
</listitem>
</itemizedlist>
<para>
A UNIX build of GLib requires that the system implements at
least the original 1990 version of POSIX. Beyond this, it
depends on a number of other libraries.
</para>
<itemizedlist>
<listitem>
<para>
The <ulink url="http://www.gnu.org/software/libiconv/">GNU
libiconv library</ulink> is needed to build GLib if your
system doesn't have the <function>iconv()</function>
function for doing conversion between character
encodings. Most modern systems should have
<function>iconv()</function>, however many older systems lack
an <function>iconv()</function> implementation. On such systems,
you must install the libiconv library. This can be found at:
<ulink url="http://www.gnu.org/software/libiconv">http://www.gnu.org/software/libiconv</ulink>.
</para>
<para>
If your system has an <function>iconv()</function> implementation but
you want to use libiconv instead, you can pass the
<option>-Diconv=gnu</option> option to <command>meson</command>. This
forces libiconv to be used.
</para>
<para>
Note that if you have libiconv installed in your default include
search path (for instance, in <filename>/usr/local/</filename>), but
don't enable it, you will get an error while compiling GLib because
the <filename>iconv.h</filename> that libiconv installs hides the
system iconv.
</para>
<para>
If you are using the native iconv implementation on Solaris
instead of libiconv, you'll need to make sure that you have
the converters between locale encodings and UTF-8 installed.
At a minimum you'll need the SUNWuiu8 package. You probably
should also install the SUNWciu8, SUNWhiu8, SUNWjiu8, and
SUNWkiu8 packages.
</para>
<para>
The native iconv on Compaq Tru64 doesn't contain support for
UTF-8, so you'll need to use GNU libiconv instead. (When
using GNU libiconv for GLib, you'll need to use GNU libiconv
for GNU gettext as well.) This probably applies to related
operating systems as well.
</para>
</listitem>
<listitem>
<para>
Python 3.5 or newer is required. Your system Python must
conform to <ulink
url="https://www.python.org/dev/peps/pep-0394/">PEP 394
</ulink>
For FreeBSD, this means that the
<literal>lang/python3</literal> port must be installed.
</para>
</listitem>
<listitem>
<para>
The libintl library from the <ulink
url="http://www.gnu.org/software/gettext">GNU gettext
package</ulink> is needed if your system doesn't have the
<function>gettext()</function> functionality for handling
message translation databases.
</para>
</listitem>
<listitem>
<para>
A thread implementation is needed. The thread support in GLib
can be based upon POSIX threads or win32 threads.
</para>
</listitem>
<listitem>
<para>
GRegex uses the <ulink url="http://www.pcre.org/">PCRE library</ulink>
for regular expression matching. The system version of PCRE is used,
unless not available (which is the case on Android), in which case a
fallback subproject is used.
</para>
</listitem>
<listitem>
<para>
The optional extended attribute support in GIO requires the
<function>getxattr()</function> family of functions that may be
provided by the C library or by the standalone libattr library. To
build GLib without extended attribute support, use the
<option>-Dxattr=false</option> option.
</para>
</listitem>
<listitem>
<para>
The optional SELinux support in GIO requires libselinux.
To build GLib without SELinux support, use the
<option>-Dselinux=disabled</option> option.
</para>
</listitem>
<listitem>
<para>
The optional support for DTrace requires the
<filename>sys/sdt.h</filename> header, which is provided
by SystemTap on Linux. To build GLib without DTrace, use
the <option>-Ddtrace=false</option> option.
</para>
</listitem>
<listitem>
<para>
The optional support for
<ulink url="http://sourceware.org/systemtap/">SystemTap</ulink>
can be disabled with the <option>-Dsystemtap=false</option>
option. Additionally, you can control the location
where GLib installs the SystemTap probes, using the
<option>-Dtapset_install_dir=DIR</option> option.
</para>
</listitem>
</itemizedlist>
</refsect1>
<refsect1 id="extra-configuration-options">
<title>Extra Configuration Options</title>
<para>
In addition to the normal options, these additional ones are supported
when configuring the GLib library:
</para>
<formalpara>
<title><option>--buildtype</option></title>
<para>
This is a standard <application>Meson</application> option which
specifies how much debugging and optimization to enable. If the build
type starts with <literal>debug</literal>,
<literal>G_ENABLE_DEBUG</literal> will be defined and GLib will be built
with additional debug code enabled.
</para>
<para>
If the build type is <literal>plain</literal>, GLib will not enable any
optimization or debug options by default, and will leave it entirely to
the user to choose their options. To build with the options recommended
by GLib developers, choose <literal>release</literal>.
</para>
</formalpara>
<formalpara>
<title><option>-Dforce_posix_threads=true</option></title>
<para>
Normally, <application>Meson</application> should be able to work out
the correct thread implementation to use. This option forces POSIX
threads to be used even if the platform provides another threading API
(for example, on Windows).
</para>
</formalpara>
<formalpara>
<title><option>-Dbsymbolic_functions=false</option> and
<option>-Dbsymbolic_functions=true</option></title>
<para>
By default, GLib uses the <option>-Bsymbolic-functions</option>
linker flag to avoid intra-library PLT jumps. A side-effect
of this is that it is no longer possible to override
internal uses of GLib functions with
<envar>LD_PRELOAD</envar>. Therefore, it may make
sense to turn this feature off in some situations.
The <option>-Dbsymbolic_functions=false</option> option allows
to do that.
</para>
</formalpara>
<formalpara>
<title><option>-Dgtk_doc=false</option> and
<option>-Dgtk_doc=true</option></title>
<para>
By default, GLib will detect whether the
<application>gtk-doc</application> package is installed.
If it is, then it will use it to extract and build the
documentation for the GLib library. These options
can be used to explicitly control whether
<application>gtk-doc</application> should be
used or not. If it is not used, the distributed,
pre-generated HTML files will be installed instead of
building them on your machine.
</para>
</formalpara>
<formalpara>
<title><option>-Dman=false</option> and
<option>-Dman=true</option></title>
<para>
By default, GLib will detect whether <application>xsltproc</application>
and the necessary DocBook stylesheets are installed.
If they are, then it will use them to rebuild the included
man pages from the XML sources. These options can be used
to explicitly control whether man pages should be rebuilt
used or not. The distribution includes pre-generated man
pages.
</para>
</formalpara>
<formalpara>
<title><option>-Dxattr=false</option> and
<option>-Dxattr=true</option></title>
<para>
By default, GLib will detect whether the
<function>getxattr()</function>
family of functions is available. If it is, then extended
attribute support will be included in GIO. These options can
be used to explicitly control whether extended attribute
support should be included or not. <function>getxattr()</function>
and friends can be provided by glibc or by the standalone
libattr library.
</para>
</formalpara>
<formalpara>
<title><option>-Dselinux=auto</option>,
<option>-Dselinux=enabled</option> or
<option>-Dselinux=disabled</option></title>
<para>
By default, GLib will detect if libselinux is available and
include SELinux support in GIO if it is. These options can be
used to explicitly control whether SELinux support should
be included.
</para>
</formalpara>
<formalpara>
<title><option>-Ddtrace=false</option> and
<option>-Ddtrace=true</option></title>
<para>
By default, GLib will detect if DTrace support is available, and use it.
These options can be used to explicitly control whether DTrace support
is compiled into GLib.
</para>
</formalpara>
<formalpara>
<title><option>-Dsystemtap=false</option> and
<option>-Dsystemtap=true</option></title>
<para>
This option requires DTrace support. If it is available, then
GLib will also check for the presence of SystemTap.
</para>
</formalpara>
<formalpara>
<title><option>-Db_coverage=true</option> and
<option>-Db_coverage=false</option></title>
<para>
Enable the generation of coverage reports for the GLib tests.
This requires the lcov frontend to gcov from the
<ulink url="http://ltp.sourceforge.net">Linux Test Project</ulink>.
To generate a coverage report, use
<command>ninja coverage-html</command>. The report is placed in the
<filename>meson-logs</filename> directory.
</para>
</formalpara>
<formalpara>
<title><option>-Druntime_libdir=RELPATH</option></title>
<para>
Allows specifying a relative path to where to install the runtime
libraries (meaning library files used for running, not developing,
GLib applications). This can be used in operating system setups where
programs using GLib needs to run before e.g. <filename>/usr</filename>
is mounted.
For example, if <varname>LIBDIR</varname> is <filename>/usr/lib</filename> and
<filename>../../lib</filename> is passed to
<option>-Druntime_libdir</option> then the
runtime libraries are installed into <filename>/lib</filename> rather
than <filename>/usr/lib</filename>.
</para>
</formalpara>
</refsect1>
</refentry>

View file

@ -0,0 +1,174 @@
<?xml version="1.0"?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
]>
<refentry id="glib-changes" revision="17 Jan 2002">
<refmeta>
<refentrytitle>Changes to GLib</refentrytitle>
<manvolnum>3</manvolnum>
<refmiscinfo>Changes to GLib</refmiscinfo>
</refmeta>
<refnamediv>
<refname>Changes to GLib</refname>
<refpurpose>
Incompatible changes made between successive versions of GLib
</refpurpose>
</refnamediv>
<refsect1>
<title>Incompatible changes from 2.0 to 2.2</title>
<itemizedlist>
<listitem>
<para>
GLib changed the seeding algorithm for the pseudo-random number
generator Mersenne Twister, as used by <structname>GRand</structname>
and <structname>GRandom</structname>. This was necessary, because some
seeds would yield very bad pseudo-random streams. Also the
pseudo-random integers generated by
<function>g_rand*_int_range()</function> will have a
slightly better equal distribution with the new version of GLib.
</para>
<para>
Further information can be found at the website of the Mersenne
Twister random number generator at <ulink
url="http://www.math.keio.ac.jp/~matumoto/emt.html">http://www.math.keio.ac.jp/~matumoto/emt.html</ulink>.
</para>
<para>
The original seeding and generation algorithms, as found in GLib
2.0.x, can be used instead of the new ones by setting the environment
variable <envar>G_RANDOM_VERSION</envar> to the value of '2.0'. Use
the GLib-2.0 algorithms only if you have sequences of numbers generated
with Glib-2.0 that you need to reproduce exactly.
</para>
</listitem>
</itemizedlist>
</refsect1>
<refsect1>
<title>Incompatible changes from 1.2 to 2.0</title>
<itemizedlist>
<listitem>
<para>
The event loop functionality <structname>GMain</structname> has extensively
been revised to support multiple separate main loops in separate threads.
All sources (timeouts, idle functions, etc.) are associated with a
<structname>GMainContext</structname>.
</para>
<para>
Compatibility functions exist so that most application code dealing with
the main loop will continue to work. However, code that creates new custom
types of sources will require modification.
</para>
<para>
The main changes here are:
<itemizedlist>
<listitem>
<para>
Sources are now exposed as <type>GSource *</type>, rather than simply as
numeric ids.
</para>
</listitem>
<listitem>
<para>
New types of sources are created by structure "derivation" from
<structname>GSource</structname>, so the <literal>source_data</literal>
parameter to the <structname>GSource</structname> virtual functions has been
replaced with a <type>GSource *</type>.
</para>
</listitem>
<listitem>
<para>
Sources are first created, then later added to a specific
<structname>GMainContext</structname>.
</para>
</listitem>
<listitem>
<para>
Dispatching has been modified so both the callback and data are passed
in to the <function>dispatch()</function> virtual function.
</para>
</listitem>
</itemizedlist>
To go along with this change, the vtable for
<structname>GIOChannel</structname> has changed and
<function>add_watch()</function> has been replaced by
<function>create_watch()</function>.
</para>
</listitem>
<listitem>
<para>
<function>g_list_foreach()</function> and
<function>g_slist_foreach()</function> have been changed so they
are now safe against removal of the current item, not the next item.
</para>
<para>
It's not recommended to mutate the list in the callback to these
functions in any case.
</para>
</listitem>
<listitem>
<para>
<structname>GDate</structname> now works in UTF-8, not in the current locale.
If you want to use it with the encoding of the locale, you need to convert
strings using <function>g_locale_to_utf8()</function> first.
</para>
</listitem>
<listitem>
<para>
<function>g_strsplit()</function> has been fixed to:
<itemizedlist>
<listitem>
<para>
include trailing empty tokens, rather than stripping them
</para>
</listitem>
<listitem>
<para>
split into a maximum of <literal>max_tokens</literal> tokens, rather
than <literal>max_tokens + 1</literal>
</para>
</listitem>
</itemizedlist>
Code depending on either of these bugs will need to be fixed.
</para>
</listitem>
<listitem>
<para>
Deprecated functions that got removed:
<function>g_set_error_handler()</function>,
<function>g_set_warning_handler()</function>,
<function>g_set_message_handler()</function>, use
<function>g_log_set_handler()</function> instead.
</para>
</listitem>
</itemizedlist>
</refsect1>
</refentry>

View file

@ -0,0 +1,125 @@
<?xml version="1.0"?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
]>
<refentry id="glib-compiling" revision="17 Jan 2002">
<refmeta>
<refentrytitle>Compiling GLib Applications</refentrytitle>
<manvolnum>3</manvolnum>
<refmiscinfo>GLib Library</refmiscinfo>
</refmeta>
<refnamediv>
<refname>Compiling GLib Applications</refname>
<refpurpose>
How to compile your GLib application
</refpurpose>
</refnamediv>
<refsect1>
<title>Compiling GLib Applications on UNIX</title>
<para>
To compile a GLib application, you need to tell the compiler where to
find the GLib header files and libraries. This is done with the
<application>pkg-config</application> utility.
</para>
<para>
The following interactive shell session demonstrates how
<application>pkg-config</application> is used (the actual output on
your system may be different):
<programlisting>
$ pkg-config --cflags glib-2.0
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
$ pkg-config --libs glib-2.0
-L/usr/lib -lm -lglib-2.0
</programlisting>
</para>
<para>
See the <ulink url="http://www.freedesktop.org/wiki/Software/pkg-config">pkg-config website</ulink>
for more information about <application>pkg-config</application>.
</para>
<para>
If your application uses or <structname>GObject</structname>
features, it must be compiled and linked with the options returned
by the following <application>pkg-config</application> invocation:
<programlisting>
$ pkg-config --cflags --libs gobject-2.0
</programlisting>
</para>
<para>
If your application uses modules, it must be compiled and linked
with the options returned by one of the following
<application>pkg-config</application> invocations:
<programlisting>
$ pkg-config --cflags --libs gmodule-no-export-2.0
$ pkg-config --cflags --libs gmodule-2.0
</programlisting>
The difference between the two is that gmodule-2.0 adds
<option>--export-dynamic</option> to the linker flags,
which is often not needed.
</para>
<para>
The simplest way to compile a program is to use command substitution
feature of a shell. A command written in the format
<literal>$(command)</literal> gets substituted into the command line
before execution. So to compile a GLib Hello, World, you would type
the following:
<programlisting>
$ cc hello.c $(pkg-config --cflags --libs glib-2.0) -o hello
</programlisting>
</para>
<note><para>
Note that the name of the file must come before the other options
(such as <emphasis>pkg-config</emphasis>), or else you may get an
error from the linker.
</para></note>
<para>
Deprecated GLib functions are annotated to make the compiler
emit warnings when they are used (e.g. with gcc, you need to use
the -Wdeprecated-declarations option). If these warnings are
problematic, they can be turned off by defining the preprocessor
symbol %GLIB_DISABLE_DEPRECATION_WARNINGS by using the commandline
option <literal>-DGLIB_DISABLE_DEPRECATION_WARNINGS</literal>
</para>
<para>
GLib deprecation annotations are versioned; by defining the
macros %GLIB_VERSION_MIN_REQUIRED and %GLIB_VERSION_MAX_ALLOWED,
you can specify the range of GLib versions whose API you want
to use. APIs that were deprecated before or introduced after
this range will trigger compiler warnings.
</para>
<para>
Since GLib 2.62, the older deprecation mechanism of hiding deprecated interfaces
entirely from the compiler by using the preprocessor symbol
<literal>G_DISABLE_DEPRECATED</literal> has been removed. All deprecations
are now handled using the above mechanism.
</para>
<para>
The recommended way of using GLib has always been to only include the
toplevel headers <filename>glib.h</filename>,
<filename>glib-object.h</filename>, <filename>gio.h</filename>.
Starting with 2.32, GLib enforces this by generating an error
when individual headers are directly included.
</para>
<para>
Still, there are some exceptions; these headers have to be included
separately:
<filename>gmodule.h</filename>,
<filename>glib-unix.h</filename>,
<filename>glib/gi18n-lib.h</filename> or
<filename>glib/gi18n.h</filename> (see
the <link linkend="glib-I18N">Internationalization section</link>),
<filename>glib/gprintf.h</filename> and
<filename>glib/gstdio.h</filename>
(we don't want to pull in all of stdio).
</para>
</refsect1>
</refentry>

View file

@ -0,0 +1,147 @@
<?xml version="1.0"?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
]>
<refentry id="glib-cross-compiling" revision="7 Aug 2018">
<refmeta>
<refentrytitle>Cross-compiling the GLib package</refentrytitle>
<manvolnum>3</manvolnum>
<refmiscinfo>GLib Library</refmiscinfo>
</refmeta>
<refnamediv>
<refname>Cross-compiling the GLib Package</refname>
<refpurpose>
How to cross-compile GLib
</refpurpose>
</refnamediv>
<refsect1 id="cross">
<title>Building the Library for a different architecture</title>
<para>
Cross-compilation is the process of compiling a program or
library on a different architecture or operating system then
it will be run upon. GLib is slightly more difficult to
cross-compile than many packages because much of GLib is
about hiding differences between different systems.
</para>
<para>
These notes cover things specific to cross-compiling GLib;
for general information about cross-compilation, see the
<ulink url="http://mesonbuild.com/Cross-compilation.html">meson</ulink>
info pages.
</para>
<para>
GLib tries to detect as much information as possible about
the target system by compiling and linking programs without
actually running anything; however, some information GLib
needs is not available this way. This information needs
to be provided to meson via a cross file.
</para>
<para>
As an example of using a cross file, to cross compile for
the MingW32 Win64 runtime environment on a Linux system,
create a file <filename>cross_file.txt</filename> with the following
contents:
</para>
<programlisting>
[host_machine]
system = 'windows'
cpu_family = 'x86_64'
cpu = 'x86_64'
endian = 'little'
[properties]
c_args = []
c_link_args = []
[binaries]
c = 'x86_64-w64-mingw32-gcc'
cpp = 'x86_64-w64-mingw32-g++'
ar = 'x86_64-w64-mingw32-ar'
ld = 'x86_64-w64-mingw32-ld'
objcopy = 'x86_64-w64-mingw32-objcopy'
strip = 'x86_64-w64-mingw32-strip'
pkgconfig = 'x86_64-w64-mingw32-pkg-config'
windres = 'x86_64-w64-mingw32-windres'
</programlisting>
<para>
Then execute the following commands:
</para>
<programlisting>
meson --cross-file cross_file.txt builddir
</programlisting>
<para>
The complete list of cross properties follows. Most
of these won't need to be set in most cases.
</para>
</refsect1>
<refsect1 id="cross-properties">
<title>Cross properties</title>
<formalpara>
<title>have_[function]</title>
<para>
When meson checks if a function is supported, the test can be
overridden by setting the
<literal>have_<replaceable>function</replaceable></literal> property
to <constant>true</constant> or <constant>false</constant>.
For example <programlisting>Checking for function "fsync" : YES</programlisting>
can be overridden by setting <programlisting>have_fsync = false</programlisting>
</para>
</formalpara>
<formalpara>
<title>growing_stack=[true/false]</title>
<para>
Whether the stack grows up or down. Most places will want
<constant>false</constant>.
A few architectures, such as PA-RISC need <constant>true</constant>.
</para>
</formalpara>
<formalpara>
<title>have_strlcpy=[true/false]</title>
<para>
Whether you have <function>strlcpy()</function> that matches
OpenBSD. Defaults to <constant>false</constant>, which is safe,
since GLib uses a built-in version in that case.
</para>
</formalpara>
<formalpara>
<title>va_val_copy=[true/false]</title>
<para>
Whether <type>va_list</type> can be copied as a pointer. If set
to <constant>false</constant>, then <function>memcopy()</function>
will be used. Only matters if you don't have
<function>va_copy()</function> or <function>__va_copy()</function>.
(So, doesn't matter for GCC.)
Defaults to <constant>true</constant> which is slightly more common
than <constant>false</constant>.
</para>
</formalpara>
<formalpara>
<title>have_c99_vsnprintf=[true/false]</title>
<para>
Whether you have a <function>vsnprintf()</function> with C99
semantics. (C99 semantics means returning the number of bytes
that would have been written had the output buffer had enough
space.) Defaults to <constant>false</constant>.
</para>
</formalpara>
<formalpara>
<title>have_c99_snprintf=[true/false]</title>
<para>
Whether you have a <function>snprintf()</function> with C99
semantics. (C99 semantics means returning the number of bytes
that would have been written had the output buffer had enough
space.) Defaults to <constant>false</constant>.
</para>
</formalpara>
</refsect1>
</refentry>

Binary file not shown.

After

Width:  |  Height:  |  Size: 31 KiB

Binary file not shown.

View file

@ -0,0 +1,302 @@
<?xml version="1.0"?>
<!DOCTYPE book PUBLIC '-//OASIS//DTD DocBook XML V4.5//EN'
'http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd' [
<!ENTITY % local.common.attrib "xmlns:xi CDATA #FIXED 'http://www.w3.org/2003/XInclude'">
<!ENTITY version SYSTEM "version.xml">
]>
<book id="index" xmlns:xi="http://www.w3.org/2003/XInclude">
<bookinfo>
<title>GLib Reference Manual</title>
<releaseinfo>
for GLib &version;
The latest version of this documentation can be found on-line at
<ulink role="online-location" url="https://developer.gnome.org/glib/unstable/">https://developer.gnome.org/glib/unstable/</ulink>.
</releaseinfo>
</bookinfo>
<chapter id="glib">
<title>GLib Overview</title>
<para>
GLib is a general-purpose utility library, which provides many useful
data types, macros, type conversions, string utilities, file utilities,
a mainloop abstraction, and so on. It works on many UNIX-like platforms,
as well as Windows and OS X. GLib is released under the GNU Lesser
General Public License (GNU LGPL).
</para>
<xi:include href="building.xml" />
<xi:include href="cross.xml" />
<xi:include href="programming.xml" />
<xi:include href="xml/compiling.xml" />
<xi:include href="running.xml" />
<xi:include href="changes.xml" />
<xi:include href="resources.xml" />
</chapter>
<chapter id="glib-fundamentals">
<title>GLib Fundamentals</title>
<xi:include href="xml/version.xml" />
<xi:include href="xml/types.xml" />
<xi:include href="xml/macros.xml" />
<xi:include href="xml/type_conversion.xml" />
<xi:include href="xml/byte_order.xml" />
<xi:include href="xml/checkedmath.xml" />
<xi:include href="xml/numerical.xml" />
<xi:include href="xml/macros_misc.xml" />
<xi:include href="xml/atomic_operations.xml" />
</chapter>
<chapter id="glib-core">
<title>GLib Core Application Support</title>
<xi:include href="xml/main.xml" />
<xi:include href="xml/threads.xml" />
<xi:include href="xml/thread_pools.xml" />
<xi:include href="xml/async_queues.xml" />
<xi:include href="xml/modules.xml" />
<xi:include href="xml/memory.xml" />
<xi:include href="xml/memory_slices.xml" />
<xi:include href="xml/iochannels.xml" />
<xi:include href="xml/error_reporting.xml" />
<xi:include href="xml/warnings.xml" />
<xi:include href="xml/messages.xml" />
</chapter>
<chapter id="glib-utilities">
<title>GLib Utilities</title>
<xi:include href="xml/string_utils.xml" />
<xi:include href="xml/conversions.xml" />
<xi:include href="xml/unicode.xml" />
<xi:include href="xml/base64.xml" />
<xi:include href="xml/checksum.xml" />
<xi:include href="xml/hmac.xml" />
<xi:include href="xml/i18n.xml" />
<xi:include href="xml/date.xml" />
<xi:include href="xml/timezone.xml" />
<xi:include href="xml/date-time.xml" />
<xi:include href="xml/random_numbers.xml" />
<xi:include href="xml/hooks.xml" />
<xi:include href="xml/misc_utils.xml" />
<xi:include href="xml/scanner.xml" />
<xi:include href="xml/timers.xml" />
<xi:include href="xml/spawn.xml" />
<xi:include href="xml/fileutils.xml" />
<xi:include href="xml/guri.xml" />
<xi:include href="xml/ghostutils.xml" />
<xi:include href="xml/shell.xml" />
<xi:include href="xml/option.xml" />
<xi:include href="xml/patterns.xml" />
<xi:include href="xml/gregex.xml" />
<xi:include href="regex-syntax.xml" />
<xi:include href="xml/markup.xml" />
<xi:include href="xml/keyfile.xml" />
<xi:include href="xml/bookmarkfile.xml" />
<xi:include href="xml/testing.xml" />
<xi:include href="xml/gunix.xml" />
<xi:include href="xml/windows.xml" />
<xi:include href="xml/uuid.xml" />
</chapter>
<chapter id="glib-data-types">
<title>GLib Data Types</title>
<xi:include href="xml/linked_lists_double.xml" />
<xi:include href="xml/linked_lists_single.xml" />
<xi:include href="xml/queue.xml" />
<xi:include href="xml/sequence.xml" />
<xi:include href="xml/trash_stack.xml" />
<xi:include href="xml/hash_tables.xml" />
<xi:include href="xml/strings.xml" />
<xi:include href="xml/string_chunks.xml" />
<xi:include href="xml/arrays.xml" />
<xi:include href="xml/arrays_pointer.xml" />
<xi:include href="xml/arrays_byte.xml" />
<xi:include href="xml/trees-binary.xml" />
<xi:include href="xml/trees-nary.xml" />
<xi:include href="xml/quarks.xml" />
<xi:include href="xml/datalist.xml" />
<xi:include href="xml/datasets.xml" />
<xi:include href="xml/gvarianttype.xml"/>
<xi:include href="xml/gvariant.xml"/>
<xi:include href="gvariant-varargs.xml"/>
<xi:include href="gvariant-text.xml"/>
<xi:include href="xml/refcount.xml"/>
<xi:include href="xml/rcbox.xml"/>
<xi:include href="xml/arcbox.xml"/>
<xi:include href="xml/refstring.xml"/>
</chapter>
<chapter id="deprecated">
<title>Deprecated APIs</title>
<xi:include href="xml/threads-deprecated.xml"/>
<xi:include href="xml/caches.xml" />
<xi:include href="xml/relations.xml" />
<xi:include href="xml/completion.xml" />
</chapter>
<chapter id="tools">
<title>GLib Tools</title>
<xi:include href="glib-gettextize.xml" />
</chapter>
<chapter id="deprecated-tools">
<title>Deprecated Tools</title>
<xi:include href="gtester.xml" />
<xi:include href="gtester-report.xml" />
</chapter>
<index id="api-index-full">
<title>Index</title>
<xi:include href="xml/api-index-full.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-deprecated" role="deprecated">
<title>Index of deprecated symbols</title>
<xi:include href="xml/api-index-deprecated.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-2" role="2.2">
<title>Index of new symbols in 2.2</title>
<xi:include href="xml/api-index-2.2.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-4" role="2.4">
<title>Index of new symbols in 2.4</title>
<xi:include href="xml/api-index-2.4.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-6" role="2.6">
<title>Index of new symbols in 2.6</title>
<xi:include href="xml/api-index-2.6.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-8" role="2.8">
<title>Index of new symbols in 2.8</title>
<xi:include href="xml/api-index-2.8.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-10" role="2.10">
<title>Index of new symbols in 2.10</title>
<xi:include href="xml/api-index-2.10.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-12" role="2.12">
<title>Index of new symbols in 2.12</title>
<xi:include href="xml/api-index-2.12.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-14" role="2.14">
<title>Index of new symbols in 2.14</title>
<xi:include href="xml/api-index-2.14.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-16" role="2.16">
<title>Index of new symbols in 2.16</title>
<xi:include href="xml/api-index-2.16.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-18" role="2.18">
<title>Index of new symbols in 2.18</title>
<xi:include href="xml/api-index-2.18.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-20" role="2.20">
<title>Index of new symbols in 2.20</title>
<xi:include href="xml/api-index-2.20.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-22" role="2.22">
<title>Index of new symbols in 2.22</title>
<xi:include href="xml/api-index-2.22.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-24" role="2.24">
<title>Index of new symbols in 2.24</title>
<xi:include href="xml/api-index-2.24.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-26" role="2.26">
<title>Index of new symbols in 2.26</title>
<xi:include href="xml/api-index-2.26.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-28" role="2.28">
<title>Index of new symbols in 2.28</title>
<xi:include href="xml/api-index-2.28.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-30" role="2.30">
<title>Index of new symbols in 2.30</title>
<xi:include href="xml/api-index-2.30.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-32" role="2.32">
<title>Index of new symbols in 2.32</title>
<xi:include href="xml/api-index-2.32.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-34" role="2.34">
<title>Index of new symbols in 2.34</title>
<xi:include href="xml/api-index-2.34.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-36" role="2.36">
<title>Index of new symbols in 2.36</title>
<xi:include href="xml/api-index-2.36.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-38" role="2.38">
<title>Index of new symbols in 2.38</title>
<xi:include href="xml/api-index-2.38.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-40" role="2.40">
<title>Index of new symbols in 2.40</title>
<xi:include href="xml/api-index-2.40.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-42" role="2.42">
<title>Index of new symbols in 2.42</title>
<xi:include href="xml/api-index-2.42.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-44" role="2.44">
<title>Index of new symbols in 2.44</title>
<xi:include href="xml/api-index-2.44.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-46" role="2.46">
<title>Index of new symbols in 2.46</title>
<xi:include href="xml/api-index-2.46.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-48" role="2.48">
<title>Index of new symbols in 2.48</title>
<xi:include href="xml/api-index-2.48.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-50" role="2.50">
<title>Index of new symbols in 2.50</title>
<xi:include href="xml/api-index-2.50.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-52" role="2.52">
<title>Index of new symbols in 2.52</title>
<xi:include href="xml/api-index-2.52.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-54" role="2.54">
<title>Index of new symbols in 2.54</title>
<xi:include href="xml/api-index-2.54.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-56" role="2.56">
<title>Index of new symbols in 2.56</title>
<xi:include href="xml/api-index-2.56.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-58" role="2.58">
<title>Index of new symbols in 2.58</title>
<xi:include href="xml/api-index-2.58.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-60" role="2.60">
<title>Index of new symbols in 2.60</title>
<xi:include href="xml/api-index-2.60.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-62" role="2.62">
<title>Index of new symbols in 2.62</title>
<xi:include href="xml/api-index-2.62.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-64" role="2.64">
<title>Index of new symbols in 2.64</title>
<xi:include href="xml/api-index-2.64.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-66" role="2.66">
<title>Index of new symbols in 2.66</title>
<xi:include href="xml/api-index-2.66.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-68" role="2.68">
<title>Index of new symbols in 2.68</title>
<xi:include href="xml/api-index-2.68.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-70" role="2.70">
<title>Index of new symbols in 2.70</title>
<xi:include href="xml/api-index-2.70.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-72" role="2.72">
<title>Index of new symbols in 2.72</title>
<xi:include href="xml/api-index-2.72.xml"><xi:fallback /></xi:include>
</index>
<xi:include href="xml/annotation-glossary.xml"><xi:fallback /></xi:include>
</book>

View file

@ -0,0 +1,88 @@
<refentry id="glib-gettextize" lang="en">
<refentryinfo>
<title>glib-gettextize</title>
<productname>GLib</productname>
<authorgroup>
<author>
<contrib>Developer</contrib>
<firstname>Owen</firstname>
<surname>Taylor</surname>
</author>
</authorgroup>
</refentryinfo>
<refmeta>
<refentrytitle>glib-gettextize</refentrytitle>
<manvolnum>1</manvolnum>
<refmiscinfo class="manual">User Commands</refmiscinfo>
</refmeta>
<refnamediv>
<refname>glib-gettextize</refname>
<refpurpose>gettext internationalization utility</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>glib-gettextize</command>
<arg choice="opt" rep="repeat">OPTION</arg>
<arg choice="opt">DIRECTORY</arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1><title>Description</title>
<para><command>glib-gettextize</command> helps to prepare a source package for being
internationalized through <application>gettext</application>.
It is a variant of the <command>gettextize</command> that ships with
<application>gettext</application>.
</para>
<para><command>glib-gettextize</command> differs
from <command>gettextize</command> in that it doesn't create an
<filename>intl/</filename> subdirectory and doesn't modify
<filename>po/ChangeLog</filename> (note that newer versions of
<command>gettextize</command> behave like this when called with the
<option>--no-changelog</option> option).
</para>
</refsect1>
<refsect1><title>Options</title>
<variablelist>
<varlistentry>
<term><option>--help</option></term>
<listitem><para>
print help and exit
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--version</option></term>
<listitem><para>
print version information and exit
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-c</option>, <option>--copy</option></term>
<listitem><para>
copy files instead of making symlinks
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-f</option>, <option>--force</option></term>
<listitem><para>
force writing of new files even if old ones exist
</para></listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1><title>See also</title>
<para>
<citerefentry><refentrytitle>gettextize</refentrytitle><manvolnum>1</manvolnum></citerefentry>
</para>
</refsect1>
</refentry>

View file

@ -0,0 +1,294 @@
# This file makes most of the thread related macros look like
# functions, which they really were, if possible easy.
<MACRO>
<NAME>GLIB_DISABLE_DEPRECATION_WARNINGS</NAME>
#ifdef GLIB_DISABLE_DEPRECATION_WARNINGS
</MACRO>
<MACRO>
<NAME>G_ATOMIC_LOCK_FREE</NAME>
#define G_ATOMIC_LOCK_FREE
</MACRO>
# default thread implementation
<MACRO>
<NAME>G_THREADS_IMPL_POSIX</NAME>
#define G_THREADS_IMPL_POSIX
</MACRO>
<MACRO>
<NAME>G_THREADS_IMPL_WIN32</NAME>
#define G_THREADS_IMPL_NONE
</MACRO>
# threads supported?
<FUNCTION>
<NAME>g_thread_supported</NAME>
<RETURNS>gboolean</RETURNS>
</FUNCTION>
# GMutex
<FUNCTION>
<NAME>g_mutex_new</NAME>
<RETURNS>GMutex *</RETURNS>
</FUNCTION>
<FUNCTION>
<NAME>g_mutex_lock</NAME>
<RETURNS>void</RETURNS>
GMutex *mutex
</FUNCTION>
<FUNCTION>
<NAME>g_mutex_trylock</NAME>
<RETURNS>gboolean</RETURNS>
GMutex *mutex
</FUNCTION>
<FUNCTION>
<NAME>g_mutex_unlock</NAME>
<RETURNS>void</RETURNS>
GMutex *mutex
</FUNCTION>
<FUNCTION>
<NAME>g_mutex_free</NAME>
<RETURNS>void</RETURNS>
GMutex *mutex
</FUNCTION>
# GStaticMutex
<STRUCT>
<NAME>GStaticMutex</NAME>
</STRUCT>
<MACRO>
<NAME>G_STATIC_MUTEX_INIT</NAME>
#define G_STATIC_MUTEX_INIT
</MACRO>
<FUNCTION>
<NAME>g_static_mutex_lock</NAME>
<RETURNS>void</RETURNS>
GStaticMutex* mutex
</FUNCTION>
<FUNCTION>
<NAME>g_static_mutex_trylock</NAME>
<RETURNS>gboolean</RETURNS>
GStaticMutex* mutex
</FUNCTION>
<FUNCTION>
<NAME>g_static_mutex_unlock</NAME>
<RETURNS>void</RETURNS>
GStaticMutex* mutex
</FUNCTION>
<FUNCTION>
<NAME>g_static_mutex_get_mutex</NAME>
<RETURNS>GMutex *</RETURNS>
GStaticMutex* mutex
</FUNCTION>
# GThread
<FUNCTION>
<NAME>g_thread_yield</NAME>
<RETURNS>void</RETURNS>
</FUNCTION>
<FUNCTION>
<NAME>g_thread_create</NAME>
<RETURNS>GThread *</RETURNS>
GThreadFunc func
gpointer data,
gboolean joinable,
GError **error
</FUNCTION>
# G_LOCK_* macros
<MACRO>
<NAME>G_LOCK_DEFINE</NAME>
#define G_LOCK_DEFINE(name)
</MACRO>
<MACRO>
<NAME>G_LOCK_DEFINE_STATIC</NAME>
#define G_LOCK_DEFINE_STATIC(name)
</MACRO>
<MACRO>
<NAME>G_LOCK_EXTERN</NAME>
#define G_LOCK_EXTERN(name)
</MACRO>
<MACRO>
<NAME>G_LOCK</NAME>
#define G_LOCK(name)
</MACRO>
<MACRO>
<NAME>G_UNLOCK</NAME>
#define G_UNLOCK(name)
</MACRO>
<MACRO>
<NAME>G_TRYLOCK</NAME>
#define G_TRYLOCK(name)
</MACRO>
# GCond
<FUNCTION>
<NAME>g_cond_new</NAME>
<RETURNS>GCond*</RETURNS>
</FUNCTION>
<FUNCTION>
<NAME>g_cond_signal</NAME>
<RETURNS>void</RETURNS>
GCond *cond
</FUNCTION>
<FUNCTION>
<NAME>g_cond_broadcast</NAME>
<RETURNS>void</RETURNS>
GCond *cond
</FUNCTION>
<FUNCTION>
<NAME>g_cond_wait</NAME>
<RETURNS>void</RETURNS>
GCond *cond, GMutex *mutex
</FUNCTION>
<FUNCTION>
<NAME>g_cond_timed_wait</NAME>
<RETURNS>gboolean</RETURNS>
GCond *cond, GMutex *mutex, GTimeVal *abs_time
</FUNCTION>
<FUNCTION>
<NAME>g_cond_free</NAME>
<RETURNS>void</RETURNS>
GCond *cond
</FUNCTION>
# GPrivate
<MACRO>
<NAME>G_PRIVATE_INIT</NAME>
#define G_PRIVATE_INIT(notify)
</MACRO>
# GStaticPrivate
<MACRO>
<NAME>G_STATIC_PRIVATE_INIT</NAME>
#define G_STATIC_PRIVATE_INIT
</MACRO>
# Definitions for different operating systems
<MACRO>
<NAME>G_OS_UNIX</NAME>
#define G_OS_UNIX
</MACRO>
<MACRO>
<NAME>G_OS_WIN32</NAME>
#define G_OS_WIN32
</MACRO>
# g_ascii_isxxx
<FUNCTION>
<NAME>g_ascii_isalnum</NAME>
<RETURNS>gboolean</RETURNS>
gchar c
</FUNCTION>
<FUNCTION>
<NAME>g_ascii_isalpha</NAME>
<RETURNS>gboolean</RETURNS>
gchar c
</FUNCTION>
<FUNCTION>
<NAME>g_ascii_iscntrl</NAME>
<RETURNS>gboolean</RETURNS>
gchar c
</FUNCTION>
<FUNCTION>
<NAME>g_ascii_isdigit</NAME>
<RETURNS>gboolean</RETURNS>
gchar c
</FUNCTION>
<FUNCTION>
<NAME>g_ascii_isgraph</NAME>
<RETURNS>gboolean</RETURNS>
gchar c
</FUNCTION>
<FUNCTION>
<NAME>g_ascii_islower</NAME>
<RETURNS>gboolean</RETURNS>
gchar c
</FUNCTION>
<FUNCTION>
<NAME>g_ascii_isprint</NAME>
<RETURNS>gboolean</RETURNS>
gchar c
</FUNCTION>
<FUNCTION>
<NAME>g_ascii_ispunct</NAME>
<RETURNS>gboolean</RETURNS>
gchar c
</FUNCTION>
<FUNCTION>
<NAME>g_ascii_isspace</NAME>
<RETURNS>gboolean</RETURNS>
gchar c
</FUNCTION>
<FUNCTION>
<NAME>g_ascii_isupper</NAME>
<RETURNS>gboolean</RETURNS>
gchar c
</FUNCTION>
<FUNCTION>
<NAME>g_ascii_isxdigit</NAME>
<RETURNS>gboolean</RETURNS>
gchar c
</FUNCTION>
# g_atomic
<FUNCTION>
<NAME>g_atomic_int_inc</NAME>
<RETURNS>void</RETURNS>
gint *atomic
</FUNCTION>
<FUNCTION>
<NAME>g_atomic_int_dec_and_test</NAME>
<RETURNS>gboolean</RETURNS>
gint *atomic
</FUNCTION>
<MACRO>
<NAME>G_VA_COPY</NAME>
#define G_VA_COPY(ap1,ap2)
</MACRO>

File diff suppressed because it is too large Load diff

View file

@ -0,0 +1,78 @@
<refentry id="gtester-report">
<refentryinfo>
<title>gtester-report</title>
<productname>GLib</productname>
<authorgroup>
<author>
<contrib>Developer</contrib>
<firstname>Tim</firstname>
<surname>Janik</surname>
</author>
</authorgroup>
</refentryinfo>
<refmeta>
<refentrytitle>gtester-report</refentrytitle>
<manvolnum>1</manvolnum>
<refmiscinfo class="manual">User Commands</refmiscinfo>
</refmeta>
<refnamediv>
<refname>gtester-report</refname>
<refpurpose>test report formatting utility</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>gtester-report</command>
<arg choice="opt" rep="repeat">option</arg>
<arg>gtester-log</arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1><title>Description</title>
<para><command>gtester-report</command> is a script which converts
the XML output generated by gtester into HTML.
</para>
<para>Since GLib 2.62, <command>gtester-report</command> is deprecated. Use
TAP for reporting test results instead, and feed it to the test harness provided
by your build system.</para>
</refsect1>
<refsect1><title>Options</title>
<variablelist>
<varlistentry>
<term><option>-h</option>, <option>--help</option></term>
<listitem><para>
print help and exit
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-v</option>, <option>--version</option></term>
<listitem><para>
print version information and exit
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-s</option>, <option>--subunit</option></term>
<listitem><para>
Output subunit. Needs python-subunit.
</para></listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1><title>See also</title>
<para>
<citerefentry>
<refentrytitle>gtester</refentrytitle>
<manvolnum>1</manvolnum>
</citerefentry>
</para>
</refsect1>
</refentry>

View file

@ -0,0 +1,192 @@
<refentry id="gtester">
<refentryinfo>
<title>gtester</title>
<productname>GLib</productname>
<authorgroup>
<author>
<contrib>Developer</contrib>
<firstname>Tim</firstname>
<surname>Janik</surname>
</author>
<author>
<contrib>Developer</contrib>
<firstname>Sven</firstname>
<surname>Herzberg</surname>
</author>
</authorgroup>
</refentryinfo>
<refmeta>
<refentrytitle>gtester</refentrytitle>
<manvolnum>1</manvolnum>
<refmiscinfo class="manual">User Commands</refmiscinfo>
</refmeta>
<refnamediv>
<refname>gtester</refname>
<refpurpose>test running utility</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>gtester</command>
<arg choice="opt" rep="repeat">OPTION</arg>
<arg>testprogram</arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1><title>Description</title>
<para><command>gtester</command> is a utility to run unit tests that have
been written using the GLib test framework.
</para>
<para>Since GLib 2.62, <command>gtester-report</command> is deprecated. Use
TAP for reporting test results instead, and feed it to the test harness provided
by your build system.</para>
<para>
When called with the <option>-o</option> option, <command>gtester</command>
writes an XML report of the test results, which can be converted
into HTML using the <command>gtester-report</command> utility.
</para>
</refsect1>
<refsect1><title>Options</title>
<variablelist>
<varlistentry>
<term><option>-h</option>, <option>--help</option></term>
<listitem><para>
print help and exit
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-v</option>, <option>--version</option></term>
<listitem><para>
print version information and exit
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--g-fatal-warnings</option></term>
<listitem><para>
make warnings fatal
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-k</option>, <option>--keep-going</option></term>
<listitem><para>
continue running after tests failed
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-l</option></term>
<listitem><para>
list paths of available test cases
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-m=<replaceable>MODE</replaceable></option></term>
<listitem><para>
run test cases in <replaceable>MODE</replaceable>, which can be one of:
<variablelist>
<varlistentry>
<term><option>perf</option></term>
<listitem><para>
run performance tests
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>slow</option>, <option>thorough</option></term>
<listitem><para>
run slow tests, or repeat non-deterministic tests more often
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>quick</option></term>
<listitem><para>
do not run slow or performance tests, or do extra repeats
of non-deterministic tests (default)
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>undefined</option></term>
<listitem><para>
run test cases that deliberately provoke checks or assertion
failures, if implemented (default)
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>no-undefined</option></term>
<listitem><para>
do not run test cases that deliberately provoke checks or
assertion failures
</para></listitem>
</varlistentry>
</variablelist>
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-p=<replaceable>TESTPATH</replaceable></option></term>
<listitem><para>
only run test cases matching <replaceable>TESTPATH</replaceable>
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-s=<replaceable>TESTPATH</replaceable></option></term>
<listitem><para>
skip test cases matching <replaceable>TESTPATH</replaceable>
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--seed=<replaceable>SEEDSTRING</replaceable></option></term>
<listitem><para>
run all test cases with random number seed <replaceable>SEEDSTRING</replaceable>
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-o=<replaceable>LOGFILE</replaceable></option></term>
<listitem><para>
write the test log to <replaceable>LOGFILE</replaceable>
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-q</option>, <option>--quiet</option></term>
<listitem><para>
suppress per test binary output
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--verbose</option></term>
<listitem><para>
report success per testcase
</para></listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1><title>See also</title>
<para>
<citerefentry>
<refentrytitle>gtester-report</refentrytitle>
<manvolnum>1</manvolnum>
</citerefentry>
</para>
</refsect1>
</refentry>

View file

@ -0,0 +1,622 @@
<?xml version='1.0' encoding='utf-8'?>
<refentry id='gvariant-text'>
<refmeta>
<refentrytitle>GVariant Text Format</refentrytitle>
</refmeta>
<refnamediv>
<refname>GVariant Text Format</refname>
<refpurpose>textual representation of GVariants</refpurpose>
</refnamediv>
<refsect1>
<title>GVariant Text Format</title>
<para>
This page attempts to document the GVariant text format as produced by
<link linkend='g-variant-print'><function>g_variant_print()</function></link> and parsed by the
<link linkend='g-variant-parse'><function>g_variant_parse()</function></link> family of functions. In most
cases the style closely resembles the formatting of literals in Python but there are some additions and
exceptions.
</para>
<para>
The functions that deal with GVariant text format absolutely always deal in utf-8. Conceptually, GVariant
text format is a string of Unicode characters -- not bytes. Non-ASCII but otherwise printable Unicode
characters are not treated any differently from normal ASCII characters.
</para>
<para>
The parser makes two passes. The purpose of the first pass is to determine the type of the value being
parsed. The second pass does the actual parsing. Based on the fact that all elements in an array have to
have the same type, GVariant is able to make some deductions that would not otherwise be possible. As an
example:
<informalexample><programlisting>[[1, 2, 3], [4, 5, 6]]</programlisting></informalexample>
is parsed as an array of arrays of integers (type '<literal>aai</literal>'), but
<informalexample><programlisting>[[1, 2, 3], [4, 5, 6.0]]</programlisting></informalexample>
is parsed as an array of arrays of doubles (type '<literal>aad</literal>').
</para>
<para>
As another example, GVariant is able to determine that
<informalexample><programlisting>["hello", nothing]</programlisting></informalexample>
is an array of maybe strings (type '<literal>ams</literal>').
</para>
<para>
What the parser accepts as valid input is dependent on context. The API permits for out-of-band type
information to be supplied to the parser (which will change its behaviour). This can be seen in the
GSettings and GDBus command line utilities where the type information is available from the schema or the
remote introspection information. The additional information can cause parses to succeed when they would not
otherwise have been able to (by resolving ambiguous type information) or can cause them to fail (due to
conflicting type information). Unless stated otherwise, the examples given in this section assume that no
out-of-band type data has been given to the parser.
</para>
</refsect1>
<refsect1>
<title>Syntax Summary</title>
<para>
The following table describes the rough meaning of symbols that may appear inside GVariant text format.
Each symbol is described in detail in its own section, including usage examples.
</para>
<informaltable>
<tgroup cols='2'>
<colspec colname='col_0'/>
<colspec colname='col_1'/>
<tbody>
<row rowsep='1'>
<entry colsep='1' rowsep='1'>
<para>
<emphasis role='strong'>Symbol</emphasis>
</para>
</entry>
<entry colsep='1' rowsep='1'>
<para>
<emphasis role='strong'>Meaning</emphasis>
</para>
</entry>
</row>
<row rowsep='1'>
<entry colsep='1' rowsep='1'>
<para>
<emphasis role='strong'><literal>true</literal></emphasis>,
<emphasis role='strong'><literal>false</literal></emphasis>
</para>
</entry>
<entry colsep='1' rowsep='1'>
<para>
<link linkend='gvariant-text-booleans'>Booleans</link>.
</para>
</entry>
</row>
<row rowsep='1'>
<entry colsep='1' rowsep='1'>
<para>
<emphasis role='strong'><literal>""</literal></emphasis>,
<emphasis role='strong'><literal>''</literal></emphasis>
</para>
</entry>
<entry colsep='1' rowsep='1'>
<para>
String literal. See <link linkend='gvariant-text-strings'>Strings</link> below.
</para>
</entry>
</row>
<row rowsep='1'>
<entry colsep='1' rowsep='1'>
<para>
numbers
</para>
</entry>
<entry colsep='1' rowsep='1'>
<para>
See <link linkend='gvariant-text-numbers'>Numbers</link> below.
</para>
</entry>
</row>
<row rowsep='1'>
<entry colsep='1' rowsep='1'>
<para>
<emphasis role='strong'><literal>()</literal></emphasis>
</para>
</entry>
<entry colsep='1' rowsep='1'>
<para>
<link linkend='gvariant-text-tuples'>Tuples</link>.
</para>
</entry>
</row>
<row rowsep='1'>
<entry colsep='1' rowsep='1'>
<para>
<emphasis role='strong'><literal>[]</literal></emphasis>
</para>
</entry>
<entry colsep='1' rowsep='1'>
<para>
<link linkend='gvariant-text-arrays'>Arrays</link>.
</para>
</entry>
</row>
<row rowsep='1'>
<entry colsep='1' rowsep='1'>
<para>
<emphasis role='strong'><literal>{}</literal></emphasis>
</para>
</entry>
<entry colsep='1' rowsep='1'>
<para>
<link linkend='gvariant-text-dictionaries'>Dictionaries and Dictionary Entries</link>.
</para>
</entry>
</row>
<row rowsep='1'>
<entry colsep='1' rowsep='1'>
<para>
<emphasis role='strong'><literal>&lt;&gt;</literal></emphasis>
</para>
</entry>
<entry colsep='1' rowsep='1'>
<para>
<link linkend='gvariant-text-variants'>Variants</link>.
</para>
</entry>
</row>
<row rowsep='1'>
<entry colsep='1' rowsep='1'>
<para>
<emphasis role='strong'><literal>just</literal></emphasis>,
<emphasis role='strong'><literal>nothing</literal></emphasis>
</para>
</entry>
<entry colsep='1' rowsep='1'>
<para>
<link linkend='gvariant-text-maybe-types'>Maybe Types</link>.
</para>
</entry>
</row>
<row rowsep='1'>
<entry colsep='1' rowsep='1'>
<para>
<emphasis role='strong'><literal>@</literal></emphasis>
</para>
</entry>
<entry colsep='1' rowsep='1'>
<para>
<link linkend='gvariant-text-type-annotations'>Type Annotations</link>.
</para>
</entry>
</row>
<row rowsep='1'>
<entry colsep='1' rowsep='1'>
<para>
type keywords
</para>
</entry>
<entry colsep='1' rowsep='1'>
<para>
<literal>boolean</literal>,
<literal>byte</literal>,
<literal>int16</literal>,
<literal>uint16</literal>,
<literal>int32</literal>,
<literal>uint32</literal>,
<literal>handle</literal>,
<literal>int64</literal>,
<literal>uint64</literal>,
<literal>double</literal>,
<literal>string</literal>,
<literal>objectpath</literal>,
<literal>signature</literal>
</para>
<para>
See <link linkend='gvariant-text-type-annotations'>Type Annotations</link> below.
</para>
</entry>
</row>
<row rowsep='1'>
<entry colsep='1' rowsep='1'>
<para>
<emphasis role='strong'><literal>b""</literal></emphasis>,
<emphasis role='strong'><literal>b''</literal></emphasis>
</para>
</entry>
<entry colsep='1' rowsep='1'>
<para>
<link linkend='gvariant-text-bytestrings'>Bytestrings</link>.
</para>
</entry>
</row>
<row rowsep='1'>
<entry colsep='1' rowsep='1'>
<para>
<emphasis role='strong'><literal>%</literal></emphasis>
</para>
</entry>
<entry colsep='1' rowsep='1'>
<para>
<link linkend='gvariant-text-positional'>Positional Parameters</link>.
</para>
</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<refsect2 id='gvariant-text-booleans'>
<title>Booleans</title>
<para>
The strings <literal>true</literal> and <literal>false</literal> are parsed as booleans. This is the only
way to specify a boolean value.
</para>
</refsect2>
<refsect2 id='gvariant-text-strings'>
<title>Strings</title>
<para>
Strings literals must be quoted using <literal>""</literal> or <literal>''</literal>. The two are
completely equivalent (except for the fact that each one is unable to contain itself unescaped).
</para>
<para>
Strings are Unicode strings with no particular encoding. For example, to specify the character
<literal>é</literal>, you just write <literal>'é'</literal>. You could also give the Unicode codepoint of
that character (U+E9) as the escape sequence <literal>'\u00e9'</literal>. Since the strings are pure
Unicode, you should not attempt to encode the utf-8 byte sequence corresponding to the string using escapes;
it won't work and you'll end up with the individual characters corresponding to each byte.
</para>
<para>
Unicode escapes of the form <literal>\uxxxx</literal> and <literal>\Uxxxxxxxx</literal> are supported, in
hexadecimal. The usual control sequence escapes <literal>\a</literal>, <literal>\b</literal>,
<literal>\f</literal>, <literal>\n</literal>, <literal>\r</literal>, <literal>\t</literal> and
<literal>\v</literal> are supported. Additionally, a <literal>\</literal> before a newline character causes
the newline to be ignored. Finally, any other character following <literal>\</literal> is copied literally
(for example, <literal>\"</literal> or <literal>\\</literal>) but for forwards compatibility with future
additions you should only use this feature when necessary for escaping backslashes or quotes.
</para>
<para>
The usual octal and hexadecimal escapes <literal>\0nnn</literal> and <literal>\xnn</literal> are not
supported here. Those escapes are used to encode byte values and GVariant strings are Unicode.
</para>
<para>
Single-character strings are not interpreted as bytes. Bytes must be specified by their numerical value.
</para>
</refsect2>
<refsect2 id='gvariant-text-numbers'>
<title>Numbers</title>
<para>
Numbers are given by default as decimal values. Octal and hex values can be given in the usual way (by
prefixing with <literal>0</literal> or <literal>0x</literal>). Note that GVariant considers bytes to be
unsigned integers and will print them as a two digit hexadecimal number by default.
</para>
<para>
Floating point numbers can also be given in the usual ways, including scientific and hexadecimal notations.
</para>
<para>
For lack of additional information, integers will be parsed as int32 values by default. If the number has a
point or an 'e' in it, then it will be parsed as a double precision floating point number by default. If
type information is available (either explicitly or inferred) then that type will be used instead.
</para>
<para>
Some examples:
</para>
<para>
<literal>5</literal> parses as the int32 value five.
</para>
<para>
<literal>37.5</literal> parses as a floating point value.
</para>
<para>
<literal>3.75e1</literal> parses the same as the value above.
</para>
<para>
<literal>uint64 7</literal> parses seven as a uint64.
See <link linkend='gvariant-text-type-annotations'>Type Annotations</link>.
</para>
</refsect2>
<refsect2 id='gvariant-text-tuples'>
<title>Tuples</title>
<para>
Tuples are formed using the same syntax as Python. Here are some examples:
</para>
<para>
<literal>()</literal> parses as the empty tuple.
</para>
<para>
<literal>(5,)</literal> is a tuple containing a single value.
</para>
<para>
<literal>("hello", 42)</literal> is a pair. Note that values of different types are permitted.
</para>
</refsect2>
<refsect2 id='gvariant-text-arrays'>
<title>Arrays</title>
<para>
Arrays are formed using the same syntax as Python uses for lists (which is arguably the term that GVariant
should have used). Note that, unlike Python lists, GVariant arrays are statically typed. This has two
implications.
</para>
<para>
First, all items in the array must have the same type. Second, the type of the array must be known, even in
the case that it is empty. This means that (unless there is some other way to infer it) type information
will need to be given explicitly for empty arrays.
</para>
<para>
The parser is able to infer some types based on the fact that all items in an array must have the same type.
See the examples below:
</para>
<para>
<literal>[1]</literal> parses (without additional type information) as a one-item array of signed integers.
</para>
<para>
<literal>[1, 2, 3]</literal> parses (similarly) as a three-item array.
</para>
<para>
<literal>[1, 2, 3.0]</literal> parses as an array of doubles. This is the most simple case of the type
inferencing in action.
</para>
<para>
<literal>[(1, 2), (3, 4.0)]</literal> causes the 2 to also be parsed as a double (but the 1 and 3 are still
integers).
</para>
<para>
<literal>["", nothing]</literal> parses as an array of maybe strings. The presence of
"<literal>nothing</literal>" clearly implies that the array elements are nullable.
</para>
<para>
<literal>[[], [""]]</literal> will parse properly because the type of the first (empty) array can be
inferred to be equal to the type of the second array (both are arrays of strings).
</para>
<para>
<literal>[b'hello', []]</literal> looks odd but will parse properly.
See <link linkend='gvariant-text-bytestrings'>Bytestrings</link>
</para>
<para>
And some examples of errors:
</para>
<para>
<literal>["hello", 42]</literal> fails to parse due to conflicting types.
</para>
<para>
<literal>[]</literal> will fail to parse without additional type information.
</para>
</refsect2>
<refsect2 id='gvariant-text-dictionaries'>
<title>Dictionaries and Dictionary Entries</title>
<para>
Dictionaries and dictionary entries are both specified using the <literal>{}</literal> characters.
</para>
<para>
The dictionary syntax is more commonly used. This is what the printer elects to use in the normal case of
dictionary entries appearing in an array (aka "a dictionary"). The separate syntax for dictionary entries
is typically only used for when the entries appear on their own, outside of an array (which is valid but
unusual). Of course, you are free to use the dictionary entry syntax within arrays but there is no good
reason to do so (and the printer itself will never do so). Note that, as with arrays, the type of empty
dictionaries must be established (either explicitly or through inference).
</para>
<para>
The dictionary syntax is the same as Python's syntax for dictionaries. Some examples:
</para>
<para>
<literal>@a{sv} {}</literal> parses as the empty dictionary of everyone's favourite type.
</para>
<para>
<literal>@a{sv} []</literal> is the same as above (owing to the fact that dictionaries are really arrays).
</para>
<para>
<literal>{1: "one", 2: "two", 3: "three"}</literal> parses as a dictionary mapping integers to strings.
</para>
<para>
The dictionary entry syntax looks just like a pair (2-tuple) that uses braces instead of parens. The
presence of a comma immediately following the key differentiates it from the dictionary syntax (which
features a colon after the first key). Some examples:
</para>
<para>
<literal>{1, "one"}</literal> is a free-standing dictionary entry that can be parsed on its own or as part
of another container value.
</para>
<para>
<literal>[{1, "one"}, {2, "two"}, {3, "three"}]</literal> is exactly equivalent to the dictionary example
given above.
</para>
</refsect2>
<refsect2 id='gvariant-text-variants'>
<title>Variants</title>
<para>
Variants are denoted using angle brackets (aka "XML brackets"), <literal>&lt;&gt;</literal>. They may not
be omitted.
</para>
<para>
Using <literal>&lt;&gt;</literal> effectively disrupts the type inferencing that occurs between array
elements. This can have positive and negative effects.
</para>
<para>
<literal>[&lt;"hello"&gt;, &lt;42&gt;]</literal> will parse whereas <literal>["hello", 42]</literal> would
not.
</para>
<para>
<literal>[&lt;['']&gt;, &lt;[]&gt;]</literal> will fail to parse even though <literal>[[''], []]</literal>
parses successfully. You would need to specify <literal>[&lt;['']&gt;, &lt;@as []&gt;]</literal>.
</para>
<para>
<literal>{"title": &lt;"frobit"&gt;, "enabled": &lt;true&gt;, "width": &lt;800&gt;}</literal> is an example of
perhaps the most pervasive use of both dictionaries and variants.
</para>
</refsect2>
<refsect2 id='gvariant-text-maybe-types'>
<title>Maybe Types</title>
<para>
The syntax for specifying maybe types is inspired by Haskell.
</para>
<para>
The null case is specified using the keyword <literal>nothing</literal> and the non-null case is explicitly
specified using the keyword <literal>just</literal>. GVariant allows <literal>just</literal> to be omitted
in every case that it is able to unambiguously determine the intention of the writer. There are two cases
where it must be specified:
</para>
<itemizedlist>
<listitem>
<para>when using nested maybes, in order to specify the <literal>just nothing</literal> case</para>
</listitem>
<listitem>
<para>
to establish the nullability of the type of a value without explicitly specifying its full type
</para>
</listitem>
</itemizedlist>
<para>
Some examples:
</para>
<para>
<literal>just 'hello'</literal> parses as a non-null nullable string.
</para>
<para>
<literal>@ms 'hello'</literal> is the same (demonstrating how <literal>just</literal> can be dropped if the type is already
known).
</para>
<para>
<literal>nothing</literal> will not parse wtihout extra type information.
</para>
<para>
<literal>@ms nothing</literal> parses as a null nullable string.
</para>
<para>
<literal>[just 3, nothing]</literal> is an array of nullable integers
</para>
<para>
<literal>[3, nothing]</literal> is the same as the above (demonstrating another place were
<literal>just</literal> can be dropped).
</para>
<para>
<literal>[3, just nothing]</literal> parses as an array of maybe maybe integers (type
<literal>'ammi'</literal>).
</para>
</refsect2>
<refsect2 id='gvariant-text-type-annotations'>
<title>Type Annotations</title>
<para>
Type annotations allow additional type information to be given to the parser. Depending on the context,
this type information can change the output of the parser, cause an error when parsing would otherwise have
succeeded or resolve an error when parsing would have otherwise failed.
</para>
<para>
Type annotations come in two forms: type codes and type keywords.
</para>
<para>
Type keywords can be seen as more verbose (and more legible) versions of a common subset of the type codes.
The type keywords <literal>boolean</literal>, <literal>byte</literal>, <literal>int16</literal>,
<literal>uint16</literal>, <literal>int32</literal>, <literal>uint32</literal>, <literal>handle</literal>,
<literal>int64</literal>, <literal>uint64</literal>, <literal>double</literal>, <literal>string</literal>,
<literal>objectpath</literal> and literal <literal>signature</literal> are each exactly equivalent to their
corresponding type code.
</para>
<para>
Type codes are an <literal>@</literal> ("at" sign) followed by a definite GVariant type string. Some
examples:
</para>
<para>
<literal>uint32 5</literal> causes the number to be parsed unsigned instead of signed (the default).
</para>
<para>
<literal>@u 5</literal> is the same
</para>
<para>
<literal>objectpath "/org/gnome/xyz"</literal> creates an object path instead of a normal string
</para>
<para>
<literal>@au []</literal> specifies the type of the empty array (which would not parse otherwise)
</para>
<para>
<literal>@ms ""</literal> indicates that a string value is meant to have a maybe type
</para>
</refsect2>
<refsect2 id='gvariant-text-bytestrings'>
<title>Bytestrings</title>
<para>
The bytestring syntax is a piece of syntactic sugar meant to complement the bytestring APIs in GVariant. It
constructs arrays of non-nul bytes (type '<literal>ay</literal>') with a nul terminator at the end. These are
normal C strings with no particular encoding enforced, so the bytes may not be valid UTF-8.
Bytestrings are a special case of byte arrays; byte arrays (also type '<literal>ay</literal>'), in the general
case, can contain nul at any position, and need not end with nul.
</para>
<para>
Bytestrings are specified with either <literal>b""</literal> or <literal>b''</literal>. As with strings,
there is no fundamental difference between the two different types of quotes.
</para>
<para>
Bytestrings support the full range of escapes that you would expect (ie: those supported by
<link linkend='g-strcompress'><function>g_strcompress()</function></link>. This includes the normal control
sequence escapes (as mentioned in the section on strings) as well as octal and hexadecimal escapes of the
forms <literal>\0nnn</literal> and <literal>\xnn</literal>.
</para>
<para>
<literal>b'abc'</literal> is equivalent to <literal>[byte 0x61, 0x62, 0x63, 0]</literal>.
</para>
<para>
When formatting arrays of bytes, the printer will choose to display the array as a bytestring if it contains
a nul character at the end and no other nul bytes within. Otherwise, it is formatted as a normal array.
</para>
</refsect2>
<refsect2 id='gvariant-text-positional'>
<title>Positional Parameters</title>
<para>
Positional parameters are not a part of the normal GVariant text format, but they are mentioned here because
they can be used with <link linkend='g-variant-new-parsed'><function>g_variant_new_parsed()</function></link>.
</para>
<para>
A positional parameter is indicated with a <literal>%</literal> followed by any valid
<link linkend='gvariant-format-strings'>GVariant Format String</link>. Variable arguments are collected as
specified by the format string and the resulting value is inserted at the current position.
</para>
<para>
This feature is best explained by example:
</para>
<informalexample><programlisting><![CDATA[char *t = "xyz";
gboolean en = false;
GVariant *value;
value = g_variant_new_parsed ("{'title': <%s>, 'enabled': <%b>}", t, en);]]></programlisting></informalexample>
<para>
This constructs a dictionary mapping strings to variants (type '<literal>a{sv}</literal>') with two items in
it. The key names are parsed from the string and the values for those keys are taken as variable arguments
parameters.
</para>
<para>
The arguments are always collected in the order that they appear in the string to be parsed. Format strings
that collect multiple arguments are permitted, so you may require more varargs parameters than the number of
<literal>%</literal> signs that appear. You can also give format strings that collect no arguments, but
there's no good reason to do so.
</para>
</refsect2>
</refsect1>
</refentry>

File diff suppressed because it is too large Load diff

View file

@ -0,0 +1,306 @@
%!PS-Adobe-2.0 EPSF-2.0
%%Title: mainloop-stages.eps
%%Creator: fig2dev Version 3.2 Patchlevel 3c
%%CreationDate: Wed Nov 29 12:23:52 2000
%%For: otaylor@fresnel.labs.redhat.com (Owen Taylor)
%%BoundingBox: 0 0 503 291
%%Magnification: 1.0000
%%EndComments
/$F2psDict 200 dict def
$F2psDict begin
$F2psDict /mtrx matrix put
/col-1 {0 setgray} bind def
/col0 {0.000 0.000 0.000 srgb} bind def
/col1 {0.000 0.000 1.000 srgb} bind def
/col2 {0.000 1.000 0.000 srgb} bind def
/col3 {0.000 1.000 1.000 srgb} bind def
/col4 {1.000 0.000 0.000 srgb} bind def
/col5 {1.000 0.000 1.000 srgb} bind def
/col6 {1.000 1.000 0.000 srgb} bind def
/col7 {1.000 1.000 1.000 srgb} bind def
/col8 {0.000 0.000 0.560 srgb} bind def
/col9 {0.000 0.000 0.690 srgb} bind def
/col10 {0.000 0.000 0.820 srgb} bind def
/col11 {0.530 0.810 1.000 srgb} bind def
/col12 {0.000 0.560 0.000 srgb} bind def
/col13 {0.000 0.690 0.000 srgb} bind def
/col14 {0.000 0.820 0.000 srgb} bind def
/col15 {0.000 0.560 0.560 srgb} bind def
/col16 {0.000 0.690 0.690 srgb} bind def
/col17 {0.000 0.820 0.820 srgb} bind def
/col18 {0.560 0.000 0.000 srgb} bind def
/col19 {0.690 0.000 0.000 srgb} bind def
/col20 {0.820 0.000 0.000 srgb} bind def
/col21 {0.560 0.000 0.560 srgb} bind def
/col22 {0.690 0.000 0.690 srgb} bind def
/col23 {0.820 0.000 0.820 srgb} bind def
/col24 {0.500 0.190 0.000 srgb} bind def
/col25 {0.630 0.250 0.000 srgb} bind def
/col26 {0.750 0.380 0.000 srgb} bind def
/col27 {1.000 0.500 0.500 srgb} bind def
/col28 {1.000 0.630 0.630 srgb} bind def
/col29 {1.000 0.750 0.750 srgb} bind def
/col30 {1.000 0.880 0.880 srgb} bind def
/col31 {1.000 0.840 0.000 srgb} bind def
end
save
newpath 0 291 moveto 0 0 lineto 503 0 lineto 503 291 lineto closepath clip newpath
-106.0 402.0 translate
1 -1 scale
/cp {closepath} bind def
/ef {eofill} bind def
/gr {grestore} bind def
/gs {gsave} bind def
/sa {save} bind def
/rs {restore} bind def
/l {lineto} bind def
/m {moveto} bind def
/rm {rmoveto} bind def
/n {newpath} bind def
/s {stroke} bind def
/sh {show} bind def
/slc {setlinecap} bind def
/slj {setlinejoin} bind def
/slw {setlinewidth} bind def
/srgb {setrgbcolor} bind def
/rot {rotate} bind def
/sc {scale} bind def
/sd {setdash} bind def
/ff {findfont} bind def
/sf {setfont} bind def
/scf {scalefont} bind def
/sw {stringwidth} bind def
/tr {translate} bind def
/tnt {dup dup currentrgbcolor
4 -2 roll dup 1 exch sub 3 -1 roll mul add
4 -2 roll dup 1 exch sub 3 -1 roll mul add
4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb}
bind def
/shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
4 -2 roll mul srgb} bind def
/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
/$F2psEnd {$F2psEnteredState restore end} def
$F2psBegin
%%Page: 1 1
10 setmiterlimit
0.06000 0.06000 sc
%
% Fig objects follow
%
/Times-Roman ff 270.00 scf sf
9300 6225 m
gs 1 -1 sc (Initial[n+1]) dup sw pop 2 div neg 0 rm col0 sh gr
/Times-Roman ff 270.00 scf sf
9300 6540 m
gs 1 -1 sc (\(Recursion\)) dup sw pop 2 div neg 0 rm col0 sh gr
% Polyline
15.000 slw
[60] 0 sd
n 1905 6000 m 1800 6000 1800 6420 105 arcto 4 {pop} repeat
1800 6525 3120 6525 105 arcto 4 {pop} repeat
3225 6525 3225 6105 105 arcto 4 {pop} repeat
3225 6000 1905 6000 105 arcto 4 {pop} repeat
cp gs col0 s gr [] 0 sd
% Polyline
[60] 0 sd
gs clippath
3865 5498 m 3806 5431 l 3688 5535 l 3808 5490 l 3747 5602 l cp
3184 5976 m 3243 6043 l 3361 5939 l 3242 5985 l 3302 5872 l cp
eoclip
n 3225 6000 m
3825 5475 l gs col0 s gr gr
[] 0 sd
% arrowhead
n 3302 5872 m 3242 5985 l 3361 5939 l 3302 5872 l cp gs 0.00 setgray ef gr col0 s
% arrowhead
n 3747 5602 m 3808 5490 l 3688 5535 l 3747 5602 l cp gs 0.00 setgray ef gr col0 s
% Polyline
n 4980 5775 m 4875 5775 4875 6270 105 arcto 4 {pop} repeat
4875 6375 6870 6375 105 arcto 4 {pop} repeat
6975 6375 6975 5880 105 arcto 4 {pop} repeat
6975 5775 4980 5775 105 arcto 4 {pop} repeat
cp gs col0 s gr
% Polyline
[60] 0 sd
gs clippath
8457 5969 m 8515 5900 l 8394 5799 l 8458 5911 l 8337 5868 l cp
8042 5505 m 7984 5574 l 8105 5675 l 8042 5564 l 8162 5606 l cp
eoclip
n 8025 5550 m
8475 5925 l gs col0 s gr gr
[] 0 sd
% arrowhead
n 8162 5606 m 8042 5564 l 8105 5675 l 8162 5606 l cp gs 0.00 setgray ef gr col0 s
% arrowhead
n 8337 5868 m 8458 5911 l 8394 5799 l 8337 5868 l cp gs 0.00 setgray ef gr col0 s
% Polyline
[60] 0 sd
n 8580 5850 m 8475 5850 8475 6570 105 arcto 4 {pop} repeat
8475 6675 10020 6675 105 arcto 4 {pop} repeat
10125 6675 10125 5955 105 arcto 4 {pop} repeat
10125 5850 8580 5850 105 arcto 4 {pop} repeat
cp gs col0 s gr [] 0 sd
% Polyline
n 7155 3825 m 7050 3825 7050 4320 105 arcto 4 {pop} repeat
7050 4425 9045 4425 105 arcto 4 {pop} repeat
9150 4425 9150 3930 105 arcto 4 {pop} repeat
9150 3825 7155 3825 105 arcto 4 {pop} repeat
cp gs col0 s gr
% Polyline
n 5055 2100 m 4950 2100 4950 2595 105 arcto 4 {pop} repeat
4950 2700 6945 2700 105 arcto 4 {pop} repeat
7050 2700 7050 2205 105 arcto 4 {pop} repeat
7050 2100 5055 2100 105 arcto 4 {pop} repeat
cp gs col0 s gr
% Polyline
n 2730 3900 m 2625 3900 2625 4395 105 arcto 4 {pop} repeat
2625 4500 4620 4500 105 arcto 4 {pop} repeat
4725 4500 4725 4005 105 arcto 4 {pop} repeat
4725 3900 2730 3900 105 arcto 4 {pop} repeat
cp gs col0 s gr
% Polyline
[60] 0 sd
n 8580 1875 m 8475 1875 8475 2295 105 arcto 4 {pop} repeat
8475 2400 9645 2400 105 arcto 4 {pop} repeat
9750 2400 9750 1980 105 arcto 4 {pop} repeat
9750 1875 8580 1875 105 arcto 4 {pop} repeat
cp gs col0 s gr [] 0 sd
% Polyline
[60] 0 sd
gs clippath
8518 2419 m 8451 2358 l 8345 2474 l 8460 2416 l 8412 2534 l cp
8003 2848 m 8070 2909 l 8176 2793 l 8062 2852 l 8109 2733 l cp
eoclip
n 8047 2868 m
8475 2400 l gs col0 s gr gr
[] 0 sd
% arrowhead
n 8109 2733 m 8062 2852 l 8176 2793 l 8109 2733 l cp gs 0.00 setgray ef gr col0 s
% arrowhead
n 8412 2534 m 8460 2416 l 8345 2474 l 8412 2534 l cp gs 0.00 setgray ef gr col0 s
% Polyline
2 slj
gs clippath
3340 4475 m 3252 4494 l 3286 4648 l 3305 4522 l 3374 4629 l cp
eoclip
n 4875 6075 m 4874 6075 l 4872 6074 l 4868 6073 l 4861 6072 l 4852 6070 l
4839 6067 l 4824 6064 l 4805 6059 l 4783 6054 l 4759 6048 l
4731 6041 l 4701 6033 l 4669 6025 l 4635 6015 l 4600 6004 l
4563 5993 l 4526 5981 l 4487 5967 l 4448 5953 l 4408 5937 l
4367 5920 l 4326 5901 l 4284 5881 l 4241 5859 l 4198 5835 l
4154 5809 l 4109 5781 l 4063 5749 l 4016 5715 l 3968 5678 l
3920 5638 l 3872 5595 l 3825 5550 l 3780 5503 l 3737 5455 l
3697 5407 l 3660 5359 l 3626 5312 l 3594 5266 l 3566 5221 l
3540 5177 l 3516 5134 l 3494 5091 l 3474 5049 l 3455 5008 l
3438 4967 l 3422 4927 l 3408 4888 l 3394 4849 l 3382 4812 l
3371 4775 l 3360 4740 l 3350 4706 l 3342 4674 l 3334 4644 l
3327 4616 l 3321 4592 l 3316 4570 l 3311 4551 l 3308 4536 l
3305 4523 l 3303 4514 l
3300 4500 l gs col0 s gr gr
% arrowhead
0 slj
n 3374 4629 m 3305 4522 l 3286 4648 l 3374 4629 l cp gs 0.00 setgray ef gr col0 s
% Polyline
2 slj
gs clippath
6943 6114 m 6978 6197 l 7123 6135 l 6995 6141 l 7087 6052 l cp
eoclip
n 8475 4500 m 8475 4501 l 8475 4503 l 8475 4508 l 8475 4515 l 8474 4525 l
8474 4538 l 8473 4553 l 8472 4573 l 8470 4594 l 8468 4619 l
8465 4646 l 8462 4675 l 8457 4706 l 8452 4739 l 8445 4773 l
8437 4808 l 8427 4845 l 8416 4882 l 8403 4921 l 8388 4961 l
8370 5002 l 8350 5045 l 8326 5090 l 8299 5137 l 8268 5186 l
8232 5237 l 8192 5290 l 8148 5345 l 8100 5400 l 8057 5445 l
8013 5490 l 7968 5533 l 7923 5573 l 7878 5612 l 7833 5649 l
7789 5684 l 7745 5717 l 7701 5749 l 7658 5779 l 7615 5807 l
7573 5834 l 7531 5861 l 7489 5886 l 7447 5910 l 7407 5933 l
7366 5955 l 7327 5977 l 7288 5997 l 7250 6017 l 7214 6035 l
7180 6052 l 7147 6068 l 7117 6083 l 7090 6096 l 7065 6108 l
7043 6118 l 7025 6127 l 7010 6134 l 6998 6140 l 6989 6144 l
6975 6150 l gs col0 s gr gr
% arrowhead
0 slj
n 7087 6052 m 6995 6141 l 7123 6135 l 7087 6052 l cp gs 0.00 setgray ef gr col0 s
% Polyline
2 slj
gs clippath
8433 3848 m 8521 3831 l 8493 3676 l 8471 3803 l 8404 3693 l cp
eoclip
n 7050 2400 m 7051 2400 l 7054 2401 l 7058 2401 l 7066 2403 l 7076 2404 l
7090 2407 l 7107 2410 l 7127 2414 l 7150 2418 l 7177 2424 l
7206 2430 l 7238 2437 l 7271 2445 l 7306 2454 l 7343 2463 l
7381 2474 l 7419 2486 l 7458 2499 l 7498 2513 l 7538 2528 l
7579 2545 l 7621 2564 l 7663 2585 l 7706 2608 l 7750 2634 l
7795 2662 l 7841 2694 l 7887 2728 l 7933 2766 l 7980 2807 l
8025 2850 l 8068 2895 l 8109 2942 l 8147 2988 l 8181 3034 l
8213 3080 l 8241 3125 l 8267 3169 l 8290 3212 l 8311 3254 l
8330 3296 l 8347 3337 l 8362 3377 l 8376 3417 l 8389 3456 l
8401 3494 l 8412 3532 l 8421 3569 l 8430 3604 l 8438 3637 l
8445 3669 l 8451 3698 l 8457 3725 l 8461 3748 l 8465 3768 l
8468 3785 l 8471 3799 l 8472 3809 l
8475 3825 l gs col0 s gr gr
% arrowhead
0 slj
n 8404 3693 m 8471 3803 l 8493 3676 l 8404 3693 l cp gs 0.00 setgray ef gr col0 s
% Polyline
2 slj
gs clippath
4970 2442 m 4959 2353 l 4803 2372 l 4928 2403 l 4814 2461 l cp
eoclip
n 3375 3900 m 3375 3899 l 3376 3897 l 3377 3892 l 3378 3886 l 3380 3876 l
3383 3863 l 3386 3848 l 3391 3828 l 3396 3806 l 3402 3781 l
3409 3753 l 3417 3722 l 3425 3689 l 3435 3655 l 3446 3619 l
3457 3581 l 3469 3543 l 3483 3504 l 3497 3464 l 3513 3423 l
3530 3383 l 3549 3341 l 3569 3299 l 3591 3257 l 3615 3214 l
3641 3170 l 3669 3125 l 3701 3080 l 3735 3034 l 3772 2988 l
3812 2941 l 3855 2895 l 3900 2850 l 3950 2804 l 4001 2762 l
4052 2723 l 4102 2687 l 4152 2655 l 4201 2625 l 4248 2599 l
4295 2576 l 4340 2555 l 4385 2536 l 4429 2519 l 4472 2504 l
4515 2490 l 4557 2477 l 4598 2466 l 4638 2456 l 4677 2447 l
4715 2439 l 4751 2432 l 4784 2426 l 4815 2420 l 4843 2415 l
4868 2411 l 4890 2408 l 4908 2406 l 4922 2404 l 4933 2402 l
4950 2400 l gs col0 s gr gr
% arrowhead
0 slj
n 4814 2461 m 4928 2403 l 4803 2372 l 4814 2461 l cp gs 0.00 setgray ef gr col0 s
/Times-Roman ff 360.00 scf sf
5925 6225 m
gs 1 -1 sc (Initial[n]) dup sw pop 2 div neg 0 rm col0 sh gr
/Times-Roman ff 360.00 scf sf
8100 4275 m
gs 1 -1 sc (Dispatching) dup sw pop 2 div neg 0 rm col0 sh gr
/Times-Roman ff 360.00 scf sf
3675 4350 m
gs 1 -1 sc (Prepared) dup sw pop 2 div neg 0 rm col0 sh gr
/Times-Roman ff 360.00 scf sf
5925 2550 m
gs 1 -1 sc (Polling) dup sw pop 2 div neg 0 rm col0 sh gr
/Times-Roman ff 270.00 scf sf
4050 3300 m
gs 1 -1 sc (query\(\)) col0 sh gr
/Times-Roman ff 270.00 scf sf
7800 3225 m
gs 1 -1 sc (check\(\)) dup sw pop neg 0 rm col0 sh gr
/Times-Roman ff 270.00 scf sf
2475 6375 m
gs 1 -1 sc (Working) dup sw pop 2 div neg 0 rm col0 sh gr
/Times-Roman ff 270.00 scf sf
3900 5400 m
gs 1 -1 sc (prepare\(\)) col0 sh gr
/Times-Roman ff 270.00 scf sf
8025 5325 m
gs 1 -1 sc (dispatch\(\)) dup sw pop neg 0 rm col0 sh gr
/Times-Roman ff 270.00 scf sf
9150 2250 m
gs 1 -1 sc (Working) dup sw pop 2 div neg 0 rm col0 sh gr
$F2psEnd
rs

View file

@ -0,0 +1,65 @@
#FIG 3.2
Landscape
Center
Inches
Letter
100.00
Single
-2
1200 2
6 8625 6000 9975 6600
4 1 0 50 0 0 18 0.0000 4 240 1290 9300 6225 Initial[n+1]\001
4 1 0 50 0 0 18 0.0000 4 255 1335 9300 6540 (Recursion)\001
-6
2 4 1 2 0 7 50 0 -1 4.000 0 0 7 0 0 5
3225 6525 3225 6000 1800 6000 1800 6525 3225 6525
2 1 1 2 0 7 50 0 -1 4.000 0 0 -1 1 1 2
1 1 2.00 90.00 120.00
1 1 2.00 90.00 120.00
3225 6000 3825 5475
2 4 0 2 0 7 50 0 -1 0.000 0 0 7 0 0 5
6975 6375 6975 5775 4875 5775 4875 6375 6975 6375
2 1 1 2 0 7 50 0 -1 4.000 0 0 -1 1 1 2
1 1 2.00 90.00 120.00
1 1 2.00 90.00 120.00
8025 5550 8475 5925
2 4 1 2 0 7 50 0 -1 4.000 0 0 7 0 0 5
10125 6675 10125 5850 8475 5850 8475 6675 10125 6675
2 4 0 2 0 7 50 0 -1 0.000 0 0 7 0 0 5
9150 4425 9150 3825 7050 3825 7050 4425 9150 4425
2 4 0 2 0 7 50 0 -1 0.000 0 0 7 0 0 5
7050 2700 7050 2100 4950 2100 4950 2700 7050 2700
2 4 0 2 0 7 50 0 -1 0.000 0 0 7 0 0 5
4725 4500 4725 3900 2625 3900 2625 4500 4725 4500
2 4 1 2 0 7 50 0 -1 4.000 0 0 7 0 0 5
9750 2400 9750 1875 8475 1875 8475 2400 9750 2400
2 1 1 2 0 7 50 0 -1 4.000 0 0 -1 1 1 2
1 1 2.00 90.00 120.00
1 1 2.00 90.00 120.00
8047 2868 8475 2400
3 2 0 2 0 7 50 0 -1 0.000 0 1 0 3
1 1 2.00 90.00 120.00
4875 6075 3825 5550 3300 4500
0.000 -1.000 0.000
3 2 0 2 0 7 50 0 -1 0.000 0 1 0 3
1 1 2.00 90.00 120.00
8475 4500 8100 5400 6975 6150
0.000 -1.000 0.000
3 2 0 2 0 7 50 0 -1 0.000 0 1 0 3
1 1 2.00 90.00 120.00
7050 2400 8025 2850 8475 3825
0.000 -1.000 0.000
3 2 0 2 0 7 50 0 -1 0.000 0 1 0 3
1 1 2.00 90.00 120.00
3375 3900 3900 2850 4950 2400
0.000 -1.000 0.000
4 1 0 50 0 0 24 0.0000 4 315 1290 5925 6225 Initial[n]\001
4 1 0 50 0 0 24 0.0000 4 330 1770 8100 4275 Dispatching\001
4 1 0 50 0 0 24 0.0000 4 330 1320 3675 4350 Prepared\001
4 1 0 50 0 0 24 0.0000 4 330 1050 5925 2550 Polling\001
4 0 0 50 0 0 18 0.0000 4 255 825 4050 3300 query()\001
4 2 0 50 0 0 18 0.0000 4 255 855 7800 3225 check()\001
4 1 0 50 0 0 18 0.0000 4 255 990 2475 6375 Working\001
4 0 0 50 0 0 18 0.0000 4 255 1050 3900 5400 prepare()\001
4 2 0 50 0 0 18 0.0000 4 255 1140 8025 5325 dispatch()\001
4 1 0 50 0 0 18 0.0000 4 255 990 9150 2250 Working\001

Binary file not shown.

After

Width:  |  Height:  |  Size: 6.9 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 15 KiB

View file

@ -0,0 +1,104 @@
if get_option('gtk_doc')
subdir('xml')
ignore_headers = [
'gallocator.h',
'gdatasetprivate.h',
'glibintl.h',
'gbsearcharray.h',
'glib-private.h',
'gmoduleconf.h',
'grcboxprivate.h',
'gstdioprivate.h',
'gthreadprivate.h',
'gunibreak.h',
'gunicomp.h',
'gunidecomp.h',
'gunichartables.h',
'glib_probes.h',
'glib_trace.h',
'libcharset.h',
'gdebug.h',
'gprintfint.h',
'gmirroringtable.h',
'gscripttable.h',
'gtrace-private.h',
'glib-mirroring-tab',
'gnulib',
'gbytesprivate.h',
'gvariant-internal.h',
'gvariant-serialiser.h',
'gvariant-core.h',
'gvarianttypeinfo.h',
'gwakeup.h',
'gtranslit-data.h',
'glib-init.h',
'gconstructor.h',
'valgrind.h',
'gutilsprivate.h',
'gvalgrind.h',
'dirent.h',
]
docpath = join_paths(glib_datadir, 'gtk-doc', 'html')
version_conf = configuration_data()
version_conf.set('GLIB_VERSION', meson.project_version())
configure_file(
input: 'version.xml.in',
output: 'version.xml',
configuration: version_conf
)
gnome.gtkdoc('glib',
main_xml : 'glib-docs.xml',
namespace : 'g',
mode : 'none',
src_dir : [ 'glib', 'gmodule' ],
dependencies : libglib_dep,
scan_args : gtkdoc_common_scan_args + [
'--ignore-headers=' + ' '.join(ignore_headers),
],
content_files : [
'cross.xml',
'running.xml',
'building.xml',
'changes.xml',
'compiling.xml',
'programming.xml',
'resources.xml',
'regex-syntax.xml',
'glib-gettextize.xml',
'gtester.xml',
'gtester-report.xml',
'gvariant-varargs.xml',
'gvariant-text.xml',
],
expand_content_files : [
'compiling.xml',
],
html_assets : [
'file-name-encodings.png',
'mainloop-states.gif',
'Sorted_binary_tree_breadth-first_traversal.svg',
'Sorted_binary_tree_inorder.svg',
'Sorted_binary_tree_postorder.svg',
'Sorted_binary_tree_preorder.svg',
],
fixxref_args: [
'--html-dir=' + docpath,
],
install: true,
check: true)
endif
if get_option('man')
manpages = ['glib-gettextize', 'gtester', 'gtester-report']
foreach page : manpages
custom_target(page + '-man',
input: page + '.xml',
output: page + '.1',
command: xsltproc_command,
install: true,
install_dir: man1_dir)
endforeach
endif

View file

@ -0,0 +1,67 @@
<?xml version="1.0"?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
]>
<refentry id="glib-programming">
<refmeta>
<refentrytitle>Writing GLib Applications</refentrytitle>
<manvolnum>3</manvolnum>
<refmiscinfo>GLib Library</refmiscinfo>
</refmeta>
<refnamediv>
<refname>Writing GLib Applications</refname>
<refpurpose>
General considerations when programming with GLib
</refpurpose>
</refnamediv>
<refsect1>
<title>Writing GLib Applications</title>
<refsect2>
<title>Threads</title>
<para>
The general policy of GLib is that all functions are invisibly threadsafe
with the exception of data structure manipulation functions, where, if
you have two threads manipulating the <emphasis>same</emphasis> data
structure, they must use a lock to synchronize their operation.
</para>
<para>
GLib creates a worker thread for its own purposes so GLib applications
will always have at least 2 threads.
</para>
<para>
See the sections on <link linkend="glib-Threads">threads</link> and
<link linkend="glib-Thread-Pools">threadpools</link> for GLib APIs that
support multithreaded applications.
</para>
</refsect2>
<refsect2>
<title>Security</title>
<para>
When writing code that runs with elevated privileges, it is important
to follow some basic rules of secure programming. David Wheeler has an
excellent book on this topic,
<ulink url="http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/index.html">Secure Programming for Linux and Unix HOWTO</ulink>.
</para>
<para>
When it comes to GLib and its associated libraries, GLib and
GObject are generally fine to use in code that runs with elevated
privileges; they don't load modules (executable code in shared objects)
or run other programs 'behind your back'. GIO has to be used
carefully in privileged programs, see the <ulink url="http://developer.gnome.org/gio/stable/ch02.html">GIO documentation</ulink> for details.
</para>
</refsect2>
</refsect1>
</refentry>

File diff suppressed because it is too large Load diff

View file

@ -0,0 +1,77 @@
<?xml version="1.0"?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
]>
<refentry id="glib-resources" revision="17 Jan 2002">
<refmeta>
<refentrytitle>Mailing lists and bug reports</refentrytitle>
<manvolnum>3</manvolnum>
<refmiscinfo>Mailing lists and bug reports</refmiscinfo>
</refmeta>
<refnamediv>
<refname>Mailing lists and bug reports</refname>
<refpurpose>
Getting help with GLib
</refpurpose>
</refnamediv>
<refsect1>
<title>Filing a bug report or feature request</title>
<para>
If you encounter a bug, misfeature, or missing feature in GLib, please
file a bug report on the issue tracker at
<ulink url="https://gitlab.gnome.org/GNOME/glib/issues/new">https://gitlab.gnome.org/GNOME/glib/issues/new</ulink>.
We'd also appreciate reports of incomplete or misleading information in
the GLib documentation; file those with the Documentation label.
</para>
<para>
Don't hesitate to file a bug report, even if you think we may know
about it already, or aren't sure of the details. Just give us as much
information as you have, and if it's already fixed or has already been
discussed, we'll add a note to that effect in the report.
</para>
<para>
The issue tracker should definitely be used for feature requests, it's
not only for bugs. We track all GLib development in GitLab, so it's
the way to be sure the GLib developers won't forget about an issue.
</para>
</refsect1>
<refsect1>
<title>Code Contributions</title>
<para>
If you develop a bugfix or enhancement for GLib, please open a merge request
for that in GitLab as well. All branches must be offered under the terms of
the GNU LGPL license, so be sure you are authorized to give us the branch
under those terms.
</para>
<para>
If you want to discuss your branch before or after developing it, open a
topic on <ulink url="https://discourse.gnome.org/tags/glib">Discourse</ulink>.
But be sure to create the GitLab merge request as well; if the branch is only
on the list and not in GitLab, it's likely to slip through the cracks.
</para>
</refsect1>
<refsect1>
<title>Discussions and user questions</title>
<para>
The <ulink url="https://gitlab.gnome.org/GNOME/glib/issues">GLib issue tracker</ulink>
is meant for discussions with actionable topics. If you want to ask a question
about using GLib, or discuss new features, you should use
<ulink url="https://discourse.gnome.org/tags/glib">the glib tag on Discourse</ulink>.
</para>
</refsect1>
</refentry>

View file

@ -0,0 +1,414 @@
<?xml version="1.0"?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
]>
<refentry id="glib-running">
<refmeta>
<refentrytitle>Running GLib Applications</refentrytitle>
<manvolnum>3</manvolnum>
<refmiscinfo>GLib Library</refmiscinfo>
</refmeta>
<refnamediv>
<refname>Running GLib Applications</refname>
<refpurpose>
How to run and debug your GLib application
</refpurpose>
</refnamediv>
<refsect1>
<title>Running and debugging GLib Applications</title>
<refsect2>
<title>Environment variables</title>
<para>
The runtime behaviour of GLib applications can be influenced by a
number of environment variables.
</para>
<formalpara>
<title>Standard variables</title>
<para>
GLib reads standard environment variables like <envar>LANG</envar>,
<envar>PATH</envar>, <envar>HOME</envar>, <envar>TMPDIR</envar>,
<envar>TZ</envar> and <envar>LOGNAME</envar>.
</para>
</formalpara>
<formalpara>
<title>XDG directories</title>
<para>
GLib consults the environment variables <envar>XDG_DATA_HOME</envar>,
<envar>XDG_DATA_DIRS</envar>, <envar>XDG_CONFIG_HOME</envar>,
<envar>XDG_CONFIG_DIRS</envar>, <envar>XDG_CACHE_HOME</envar> and
<envar>XDG_RUNTIME_DIR</envar> for the various XDG directories.
For more information, see the <ulink url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG basedir spec</ulink>.
</para>
</formalpara>
<formalpara id="G_FILENAME_ENCODING">
<title><envar>G_FILENAME_ENCODING</envar></title>
<para>
This environment variable can be set to a comma-separated list of character
set names. GLib assumes that filenames are encoded in the first character
set from that list rather than in UTF-8. The special token "@locale" can be
used to specify the character set for the current locale.
</para>
</formalpara>
<formalpara id="G_BROKEN_FILENAMES">
<title><envar>G_BROKEN_FILENAMES</envar></title>
<para>
If this environment variable is set, GLib assumes that filenames are in
the locale encoding rather than in UTF-8. G_FILENAME_ENCODING takes
priority over G_BROKEN_FILENAMES.
</para>
</formalpara>
<formalpara id="G_MESSAGES_PREFIXED">
<title><envar>G_MESSAGES_PREFIXED</envar></title>
<para>
A list of log levels for which messages should be prefixed by the
program name and PID of the application. The default is to prefix
everything except <literal>G_LOG_LEVEL_MESSAGE</literal> and
<literal>G_LOG_LEVEL_INFO</literal>.
The possible values are
<literal>error</literal>,
<literal>warning</literal>,
<literal>critical</literal>,
<literal>message</literal>,
<literal>info</literal> and
<literal>debug</literal>.
You can also use the special values
<literal>all</literal> and
<literal>help</literal>.
</para>
<para>
This environment variable only affects the default log handler,
g_log_default_handler().
</para>
</formalpara>
<formalpara id="G_MESSAGES_DEBUG">
<title><envar>G_MESSAGES_DEBUG</envar></title>
<para>
A space-separated list of log domains for which informational
and debug messages should be printed. By default, these
messages are not printed.
</para>
<para>
You can also use the special value <literal>all</literal>.
</para>
<para>
This environment variable only affects the default log handler,
g_log_default_handler().
</para>
</formalpara>
<formalpara id="G-DEBUG:CAPS">
<title><envar>G_DEBUG</envar></title>
<para>
This environment variable can be set to a list of debug options,
which cause GLib to print out different types of debugging information.
<variablelist>
<varlistentry>
<term>fatal-warnings</term>
<listitem><para>Causes GLib to abort the program at the first call
to g_warning() or g_critical(). Use of this flag is not
recommended except when debugging.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>fatal-criticals</term>
<listitem><para>Causes GLib to abort the program at the first call
to g_critical(). This flag can be useful during debugging and
testing.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>gc-friendly</term>
<listitem><para>Newly allocated memory that isn't directly initialized,
as well as memory being freed will be reset to 0. The point here is
to allow memory checkers and similar programs that use Boehm GC alike
algorithms to produce more accurate results.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>resident-modules</term>
<listitem><para>All modules loaded by GModule will be made resident.
This can be useful for tracking memory leaks in modules which are
later unloaded; but it can also hide bugs where code is accessed
after the module would have normally been unloaded.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>bind-now-modules</term>
<listitem><para>All modules loaded by GModule will bind their symbols
at load time, even when the code uses %G_MODULE_BIND_LAZY.</para>
</listitem>
</varlistentry>
</variablelist>
The special value <literal>all</literal> can be used to turn on all debug options.
The special value <literal>help</literal> can be used to print all available options.
</para>
</formalpara>
<formalpara id="G_SLICE">
<title><envar>G_SLICE</envar></title>
<para>
This environment variable allows reconfiguration of the GSlice
memory allocator.
<variablelist>
<varlistentry>
<term>always-malloc</term>
<listitem><para>This will cause all slices allocated through
g_slice_alloc() and released by g_slice_free1() to be actually
allocated via direct calls to g_malloc() and g_free().
This is most useful for memory checkers and similar programs that
use Boehm GC alike algorithms to produce more accurate results.
It can also be in conjunction with debugging features of the system's
malloc() implementation such as glibc's MALLOC_CHECK_=2 to debug
erroneous slice allocation code, although
<literal>debug-blocks</literal> is usually a better suited debugging
tool.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>debug-blocks</term>
<listitem><para>Using this option (present since GLib 2.13) engages
extra code which performs sanity checks on the released memory
slices. Invalid slice addresses or slice sizes will be reported and
lead to a program halt. This option is for debugging scenarios.
In particular, client packages sporting their own test suite should
<emphasis>always enable this option when running tests</emphasis>.
Global slice validation is ensured by storing size and address
information for each allocated chunk, and maintaining a global
hash table of that data. That way, multi-thread scalability is
given up, and memory consumption is increased. However, the
resulting code usually performs acceptably well, possibly better
than with comparable memory checking carried out using external
tools.</para>
<para>An example of a memory corruption scenario that cannot be
reproduced with <literal>G_SLICE=always-malloc</literal>, but will
be caught by <literal>G_SLICE=debug-blocks</literal> is as follows:
<programlisting>
/* void* gives up type-safety */
void *slist = g_slist_alloc ();
/* corruption: sizeof (GSList) != sizeof (GList) */
g_list_free (slist);
</programlisting></para>
</listitem>
</varlistentry>
</variablelist>
The special value <literal>all</literal> can be used to turn on all options.
The special value <literal>help</literal> can be used to print all available options.
</para>
</formalpara>
<formalpara id="G_RANDOM_VERSION">
<title><envar>G_RANDOM_VERSION</envar></title>
<para>
If this environment variable is set to '2.0', the outdated
pseudo-random number seeding and generation algorithms from
GLib 2.0 are used instead of the newer, better ones. You should
only set this variable if you have sequences of numbers that were
generated with Glib 2.0 that you need to reproduce exactly.
</para>
</formalpara>
<formalpara id="LIBCHARSET_ALIAS_DIR">
<title><envar>LIBCHARSET_ALIAS_DIR</envar></title>
<para>
Allows to specify a nonstandard location for the
<filename>charset.aliases</filename> file that is used by the
character set conversion routines. The default location is the
<replaceable>libdir</replaceable> specified at compilation time.
</para>
</formalpara>
<formalpara id="TZDIR">
<title><envar>TZDIR</envar></title>
<para>
Allows to specify a nonstandard location for the timezone data files
that are used by the #GDateTime API. The default location is under
<filename>/usr/share/zoneinfo</filename>. For more information,
also look at the <command>tzset</command> manual page.
</para>
</formalpara>
<formalpara id="G_ENABLE_DIAGNOSTIC">
<title><envar>G_ENABLE_DIAGNOSTIC</envar></title>
<para>
If set to a non-zero value, this environment variable enables
diagnostic messages, like deprecation messages for GObject properties
and signals.
</para>
</formalpara>
<formalpara id="G_DEBUGGER">
<title><envar>G_DEBUGGER</envar></title>
<para>
When running on Windows, if set to a non-empty string, GLib will
try to interpret the contents of this environment variable as
a command line to a debugger, and run it if the process crashes.
The debugger command line should contain <literal>%p</literal> and <literal>%e</literal> substitution
tokens, which GLib will replace with the process ID of the crashing
process and a handle to an event that the debugger should signal
to let GLib know that the debugger successfully attached to the
process. If <literal>%e</literal> is absent, or if the debugger is not able to
signal events, GLib will resume execution after 60 seconds.
If <literal>%p</literal> is absent, the debugger won't know which process to attach to,
and GLib will also resume execution after 60 seconds.
</para>
<para>
Additionally, even if <envar>G_DEBUGGER</envar> is not set, GLib would still
try to print basic exception information (code and address) into
stderr.
</para>
<para>
By default the debugger gets a new console allocated for it.
Set the <envar>G_DEBUGGER_OLD_CONSOLE</envar> environment variable to any
non-empty string to make the debugger inherit the console of
the crashing process. Normally this is only used by the GLib
testsuite.
</para>
<para>
The exception handler is written with the aim of making it as
simple as possible, to minimize the risk of it invoking
buggy functions or running buggy code, which would result
in exceptions being raised recursively. Because of that
it lacks most of the amenities that one would expect of GLib.
Namely, it does not support Unicode, so it is highly advisable
to only use ASCII characters in <envar>G_DEBUGGER</envar>.
</para>
<para>
See also <link linkend="G_VEH_CATCH"><envar>G_VEH_CATCH</envar></link>.
</para>
</formalpara>
<formalpara id="G_VEH_CATCH">
<title><envar>G_VEH_CATCH</envar></title>
<para>
Catching some exceptions can break the program, since Windows
will sometimes use exceptions for execution flow control and
other purposes other than signalling a crash.
</para>
<para>
The <envar>G_VEH_CATCH</envar> environment variable augments
<ulink url="https://docs.microsoft.com/en-us/windows/desktop/debug/vectored-exception-handling">Vectored Exception Handling</ulink>
on Windows (see <link linkend="G_DEBUGGER"><envar>G_DEBUGGER</envar></link>), allowing GLib to catch more
exceptions. Set this variable to a comma-separated list of
hexadecimal exception codes that should additionally be caught.
</para>
<para>
By default GLib will only catch Access Violation, Stack Overflow and
Illegal Instruction <ulink url="https://docs.microsoft.com/en-us/windows/desktop/api/winnt/ns-winnt-_exception_record">exceptions</ulink>.
</para>
</formalpara>
</refsect2>
<refsect2 id="setlocale">
<title>Locale</title>
<para>
A number of interfaces in GLib depend on the current locale in which
an application is running. Therefore, most GLib-using applications should
call <function>setlocale (LC_ALL, "")</function> to set up the current
locale.
</para>
<para>
On Windows, in a C program there are several locale concepts
that not necessarily are synchronized. On one hand, there is the
system default ANSI code-page, which determines what encoding is used
for file names handled by the C library's functions and the Win32
API. (We are talking about the "narrow" functions here that take
character pointers, not the "wide" ones.)
</para>
<para>
On the other hand, there is the C library's current locale. The
character set (code-page) used by that is not necessarily the same as
the system default ANSI code-page. Strings in this character set are
returned by functions like <function>strftime()</function>.
</para>
</refsect2>
<para>
GLib ships with a set of Python macros for the GDB debugger. These includes pretty
printers for lists, hashtables and GObject types. It also has a backtrace filter
that makes backtraces with signal emissions easier to read.
</para>
<para>
To use this you need a version of GDB that supports Python scripting; anything
from 7.0 should be fine. You then need to install GLib in the same prefix as
GDB so that the Python GDB autoloaded files get installed in the right place
for GDB to pick up.
</para>
<para>
General pretty printing should just happen without having to do anything special.
To get the signal emission filtered backtrace you must use the "new-backtrace" command
instead of the standard one.
</para>
<para>
There is also a new command called gforeach that can be used to apply a command
on each item in a list. E.g. you can do
<programlisting>
gforeach i in some_list_variable: print *(GtkWidget *)l
</programlisting>
Which would print the contents of each widget in a list of widgets.
</para>
<refsect2>
<title>SystemTap</title>
<para>
<ulink url="http://sourceware.org/systemtap/">SystemTap</ulink> is a dynamic whole-system
analysis toolkit. GLib ships with a file <filename>libglib-2.0.so.*.stp</filename> which defines a
set of probe points, which you can hook into with custom SystemTap scripts.
See the files <filename>libglib-2.0.so.*.stp</filename>, <filename>libgobject-2.0.so.*.stp</filename>
and <filename>libgio-2.0.so.*.stp</filename> which
are in your shared SystemTap scripts directory.
</para>
</refsect2>
<refsect2>
<title>Memory statistics</title>
<para>
g_mem_profile() will output a summary g_malloc() memory usage, if memory
profiling has been enabled by calling
<literal>g_mem_set_vtable (glib_mem_profiler_table)</literal> upon startup.
</para>
<para>
If GLib has been configured with <option>--enable-debug=yes</option>,
then g_slice_debug_tree_statistics() can be called in a debugger to
output details about the memory usage of the slice allocator.
</para>
</refsect2>
</refsect1>
</refentry>

View file

@ -0,0 +1 @@
@GLIB_VERSION@

View file

@ -0,0 +1,8 @@
<!ENTITY package "@PACKAGE@">
<!ENTITY package_bugreport "@PACKAGE_BUGREPORT@">
<!ENTITY package_name "@PACKAGE_NAME@">
<!ENTITY package_string "@PACKAGE_STRING@">
<!ENTITY package_tarname "@PACKAGE_TARNAME@">
<!ENTITY package_url "@PACKAGE_URL@">
<!ENTITY package_version "@PACKAGE_VERSION@">
<!ENTITY package_api_version "@PACKAGE_API_VERSION@">

View file

@ -0,0 +1,14 @@
ent_conf = configuration_data()
ent_conf.set('PACKAGE', 'glib')
ent_conf.set('PACKAGE_BUGREPORT', 'https://gitlab.gnome.org/GNOME/glib/issues/new')
ent_conf.set('PACKAGE_NAME', 'glib')
ent_conf.set('PACKAGE_STRING', 'glib')
ent_conf.set('PACKAGE_TARNAME', 'glib')
ent_conf.set('PACKAGE_URL', 'FIXME')
ent_conf.set('PACKAGE_VERSION', glib_version)
ent_conf.set('PACKAGE_API_VERSION', glib_api_version)
configure_file(
input: 'gtkdocentities.ent.in',
output: 'gtkdocentities.ent',
configuration: ent_conf
)

View file

@ -0,0 +1,579 @@
<refentry id="glib-genmarshal" lang="en">
<refentryinfo>
<title>glib-genmarshal</title>
<productname>GObject</productname>
<authorgroup>
<author>
<contrib>Developer</contrib>
<firstname>Emmanuele</firstname>
<surname>Bassi</surname>
</author>
<author>
<contrib>Original developer</contrib>
<firstname>Tim</firstname>
<surname>Janik</surname>
</author>
</authorgroup>
</refentryinfo>
<refmeta>
<refentrytitle>glib-genmarshal</refentrytitle>
<manvolnum>1</manvolnum>
<refmiscinfo class="manual">User Commands</refmiscinfo>
</refmeta>
<refnamediv>
<refname>glib-genmarshal</refname>
<refpurpose>C code marshaller generation utility for GLib closures</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>glib-genmarshal</command>
<arg choice="opt" rep="repeat">OPTION</arg>
<arg choice="opt" rep="repeat">FILE</arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1><title>Description</title>
<para><command>glib-genmarshal</command> is a small utility that generates C code
marshallers for callback functions of the GClosure mechanism in the GObject
sublibrary of GLib. The marshaller functions have a standard signature,
they get passed in the invoking closure, an array of value structures holding
the callback function parameters and a value structure for the return value
of the callback. The marshaller is then responsible to call the respective C
code function of the closure with all the parameters on the stack and to
collect its return value.
</para>
<para><command>glib-genmarshal</command> takes a list of marshallers to generate as
input. The marshaller list is either read from files passed as additional arguments
on the command line; or from standard input, by using <literal>-</literal> as the
input file.
</para>
<refsect2><title>Marshaller list format</title>
<para>
The marshaller lists are processed line by line, a line can contain a
comment in the form of
<informalexample><programlisting>
# this is a comment
</programlisting></informalexample>
or a marshaller specification of the form
<programlisting>
<replaceable>RTYPE</replaceable>:<replaceable>PTYPE</replaceable>
<replaceable>RTYPE</replaceable>:<replaceable>PTYPE</replaceable>,<replaceable>PTYPE</replaceable>
<replaceable>RTYPE</replaceable>:<replaceable>PTYPE</replaceable>,<replaceable>PTYPE</replaceable>,<replaceable>PTYPE</replaceable>
</programlisting>
</para>
<para>
The <replaceable>RTYPE</replaceable> part specifies the callback's return
type and the <replaceable>PTYPE</replaceable>s right to the colon specify
the callback's parameter list, except for the first and the last arguments
which are always pointers.
</para>
</refsect2>
<refsect2><title>Parameter types</title>
<para>
Currently, the following types are supported:
<variablelist>
<varlistentry>
<term><replaceable>VOID</replaceable></term>
<listitem><para>
indicates no return type, or no extra parameters.
If <replaceable>VOID</replaceable> is used as the parameter list, no
additional parameters may be present.
</para></listitem>
</varlistentry>
<varlistentry>
<term><replaceable>BOOLEAN</replaceable></term>
<listitem><para>
for boolean types (gboolean)
</para></listitem>
</varlistentry>
<varlistentry>
<term><replaceable>CHAR</replaceable></term>
<listitem><para>
for signed char types (gchar)
</para></listitem>
</varlistentry>
<varlistentry>
<term><replaceable>UCHAR</replaceable></term>
<listitem><para>
for unsigned char types (guchar)
</para></listitem>
</varlistentry>
<varlistentry>
<term><replaceable>INT</replaceable></term>
<listitem><para>
for signed integer types (gint)
</para></listitem>
</varlistentry>
<varlistentry>
<term><replaceable>UINT</replaceable></term>
<listitem><para>
for unsigned integer types (guint)
</para></listitem>
</varlistentry>
<varlistentry>
<term><replaceable>LONG</replaceable></term>
<listitem><para>
for signed long integer types (glong)
</para></listitem>
</varlistentry>
<varlistentry>
<term><replaceable>ULONG</replaceable></term>
<listitem><para>
for unsigned long integer types (gulong)
</para></listitem>
</varlistentry>
<varlistentry>
<term><replaceable>INT64</replaceable></term>
<listitem><para>
for signed 64bit integer types (gint64)
</para></listitem>
</varlistentry>
<varlistentry>
<term><replaceable>UINT64</replaceable></term>
<listitem><para>
for unsigned 64bit integer types (guint64)
</para></listitem>
</varlistentry>
<varlistentry>
<term><replaceable>ENUM</replaceable></term>
<listitem><para>
for enumeration types (gint)
</para></listitem>
</varlistentry>
<varlistentry>
<term><replaceable>FLAGS</replaceable></term>
<listitem><para>
for flag enumeration types (guint)
</para></listitem>
</varlistentry>
<varlistentry>
<term><replaceable>FLOAT</replaceable></term>
<listitem><para>
for single-precision float types (gfloat)
</para></listitem>
</varlistentry>
<varlistentry>
<term><replaceable>DOUBLE</replaceable></term>
<listitem><para>
for double-precision float types (gdouble)
</para></listitem>
</varlistentry>
<varlistentry>
<term><replaceable>STRING</replaceable></term>
<listitem><para>
for string types (gchar*)
</para></listitem>
</varlistentry>
<varlistentry>
<term><replaceable>BOXED</replaceable></term>
<listitem><para>
for boxed (anonymous but reference counted) types (GBoxed*)
</para></listitem>
</varlistentry>
<varlistentry>
<term><replaceable>PARAM</replaceable></term>
<listitem><para>
for GParamSpec or derived types (GParamSpec*)
</para></listitem>
</varlistentry>
<varlistentry>
<term><replaceable>POINTER</replaceable></term>
<listitem><para>
for anonymous pointer types (gpointer)
</para></listitem>
</varlistentry>
<varlistentry>
<term><replaceable>OBJECT</replaceable></term>
<listitem><para>
for GObject or derived types (GObject*)
</para></listitem>
</varlistentry>
<varlistentry>
<term><replaceable>VARIANT</replaceable></term>
<listitem><para>
for GVariant types (GVariant*)
</para></listitem>
</varlistentry>
<varlistentry>
<term><replaceable>NONE</replaceable></term>
<listitem><para>
deprecated alias for <replaceable>VOID</replaceable>
</para></listitem>
</varlistentry>
<varlistentry>
<term><replaceable>BOOL</replaceable></term>
<listitem><para>
deprecated alias for <replaceable>BOOLEAN</replaceable>
</para></listitem>
</varlistentry>
</variablelist>
</para>
</refsect2>
</refsect1>
<refsect1><title>Options</title>
<variablelist>
<varlistentry>
<term><option>--header</option></term>
<listitem><para>
Generate header file contents of the marshallers. This option is mutually
exclusive with the <option>--body</option> option.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--body</option></term>
<listitem><para>
Generate C code file contents of the marshallers. This option is mutually
exclusive with the <option>--header</option> option.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--prefix=<replaceable>PREFIX</replaceable></option></term>
<listitem><para>
Specify marshaller prefix. The default prefix is <literal>`g_cclosure_user_marshal'</literal>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--skip-source</option></term>
<listitem><para>
Skip source location remarks in generated comments.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--stdinc</option></term>
<listitem><para>
Use the standard marshallers of the GObject library, and include
<filename>glib-object.h</filename> in generated header files. This
option is mutually exclusive with the <option>--nostdinc</option>
option.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--nostdinc</option></term>
<listitem><para>
Do not use the standard marshallers of the GObject library, and skip
<filename>glib-object.h</filename> include directive in generated header files.
This option is mutually exclusive with the <option>--stdinc</option> option.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--internal</option></term>
<listitem><para>
Mark generated functions as internal, using <literal>G_GNUC_INTERNAL</literal>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--valist-marshallers</option></term>
<listitem><para>
Generate valist marshallers, for use with <function>g_signal_set_va_marshaller()</function>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-v</option>, <option>--version</option></term>
<listitem><para>
Print version information.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--g-fatal-warnings</option></term>
<listitem><para>
Make warnings fatal, that is, exit immediately once a warning occurs.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-h</option>, <option>--help</option></term>
<listitem><para>
Print brief help and exit.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-v</option>, <option>--version</option></term>
<listitem><para>
Print version and exit.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--output=FILE</option></term>
<listitem><para>
Write output to <replaceable>FILE</replaceable> instead of the standard output.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--prototypes</option></term>
<listitem><para>
Generate function prototypes before the function definition in the C source
file, in order to avoid a <literal>missing-prototypes</literal> compiler
warning. This option is only useful when using the <option>--body</option>
option.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--pragma-once</option></term>
<listitem><para>
Use the <literal>once</literal> pragma instead of an old style header guard
when generating the C header file. This option is only useful when using the
<option>--header</option> option.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--include-header=<replaceable>HEADER</replaceable></option></term>
<listitem><para>
Adds a <literal>#include</literal> directive for the given file in the C
source file. This option is only useful when using the <option>--body</option>
option.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-D <replaceable>SYMBOL[=VALUE]</replaceable></option></term>
<listitem><para>
Adds a <literal>#define</literal> C pre-processor directive for
<replaceable>SYMBOL</replaceable> and its given <replaceable>VALUE</replaceable>,
or "1" if the value is unset. You can use this option multiple times; if you do,
all the symbols will be defined in the same order given on the command line, before
the symbols undefined using the <option>-U</option> option. This option is only
useful when using the <option>--body</option> option.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-U <replaceable>SYMBOL</replaceable></option></term>
<listitem><para>
Adds a <literal>#undef</literal> C pre-processor directive to undefine the
given <replaceable>SYMBOL</replaceable>. You can use this option multiple times;
if you do, all the symbols will be undefined in the same order given on the
command line, after the symbols defined using the <option>-D</option> option.
This option is only useful when using the <option>--body</option> option.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--quiet</option></term>
<listitem><para>
Minimizes the output of <command>glib-genmarshal</command>, by printing only
warnings and errors. This option is mutually exclusive with the
<option>--verbose</option> option.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--verbose</option></term>
<listitem><para>
Increases the verbosity of <command>glib-genmarshal</command>, by printing
debugging information. This option is mutually exclusive with the
<option>--quiet</option> option.
</para></listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1><title>Using <command>glib-genmarshal</command> with Meson</title>
<para>
Meson supports generating closure marshallers using <command>glib-genmarshal</command>
out of the box in its "gnome" module.
</para>
<para>
In your <filename>meson.build</filename> file you will typically call the
<literal>gnome.genmarshal()</literal> method with the source list of marshallers
to generate:
</para>
<informalexample><programlisting>
gnome = import('gnome')
marshal_files = gnome.genmarshal('marshal',
sources: 'marshal.list',
internal: true,
)
</programlisting></informalexample>
<para>
The <literal>marshal_files</literal> variable will contain an array of two elements
in the following order:
</para>
<itemizedlist>
<listitem><para>a build target for the source file</para></listitem>
<listitem><para>a build target for the header file</para></listitem>
</itemizedlist>
<para>
You should use the returned objects to provide a dependency on every other
build target that references the source or header file; for instance, if you
are using the source to build a library:
</para>
<informalexample><programlisting>
mainlib = library('project',
sources: project_sources + marshal_files,
...
)
</programlisting></informalexample>
<para>
Additionally, if you are including the generated header file inside a build
target that depends on the library you just built, you must ensure that the
internal dependency includes the generated header as a required source file:
</para>
<informalexample><programlisting>
mainlib_dep = declare_dependency(sources: marshal_files[1], link_with: mainlib)
</programlisting></informalexample>
<para>
You should not include the generated source file as well, otherwise it will
be built separately for every target that depends on it, causing build
failures. To know more about why all this is required, please refer to the
<ulink url="https://mesonbuild.com/FAQ.html#how-do-i-tell-meson-that-my-sources-use-generated-headers">
corresponding Meson FAQ entry</ulink>.
</para>
<para>
For more information on how to use the method, see the
<ulink url="https://mesonbuild.com/Gnome-module.html#gnomegenmarshal">Meson
documentation for <literal>gnome.genmarshal()</literal></ulink>.
</para>
</refsect1>
<refsect1><title>Using <command>glib-genmarshal</command> with Autotools</title>
<para>
In order to use <command>glib-genmarshal</command> in your project when using
Autotools as the build system, you will first need to modify your
<filename>configure.ac</filename> file to ensure you find the appropriate
command using <command>pkg-config</command>, similarly as to how you discover
the compiler and linker flags for GLib.
</para>
<informalexample><programlisting>
PKG_PROG_PKG_CONFIG([0.28])
PKG_CHECK_VAR([GLIB_GENMARSHAL], [glib-2.0], [glib_genmarshal])
</programlisting></informalexample>
<para>
In your <filename>Makefile.am</filename> file you will typically need very
simple rules to generate the C files needed for the build.
</para>
<informalexample><programlisting>
marshal.h: marshal.list
$(AM_V_GEN)$(GLIB_GENMARSHAL) \
--header \
--output=$@ \
$&lt;
marshal.c: marshal.list marshal.h
$(AM_V_GEN)$(GLIB_GENMARSHAL) \
--include-header=marshal.h \
--body \
--output=$@ \
$&lt;
BUILT_SOURCES += marshal.h marshal.c
CLEANFILES += marshal.h marshal.c
EXTRA_DIST += marshal.list
</programlisting></informalexample>
<para>
In the example above, the first rule generates the header file and depends on
a <filename>marshal.list</filename> file in order to regenerate the result in
case the marshallers list is updated. The second rule generates the source file
for the same <filename>marshal.list</filename>, and includes the file generated
by the header rule.
</para>
</refsect1>
<refsect1><title>Example</title>
<para>
To generate marshallers for the following callback functions:
</para>
<informalexample><programlisting>
void foo (gpointer data1,
gpointer data2);
void bar (gpointer data1,
gint param1,
gpointer data2);
gfloat baz (gpointer data1,
gboolean param1,
guchar param2,
gpointer data2);
</programlisting></informalexample>
<para>
The <filename>marshaller.list</filename> file has to look like this:
</para>
<programlisting>
VOID:VOID
VOID:INT
FLOAT:BOOLEAN,UCHAR
</programlisting>
<para>
and you call glib-genmarshal like this:
</para>
<programlisting>
glib-genmarshal --header marshaller.list > marshaller.h
glib-genmarshal --body marshaller.list > marshaller.c
</programlisting>
<para>
The generated marshallers have the arguments encoded in their function name.
For this particular list, they are
</para>
<programlisting>
g_cclosure_user_marshal_VOID__VOID(...),
g_cclosure_user_marshal_VOID__INT(...),
g_cclosure_user_marshal_FLOAT__BOOLEAN_UCHAR(...).
</programlisting>
<para>
They can be used directly for GClosures or be passed in as the
GSignalCMarshaller c_marshaller; argument upon creation of signals:
</para>
<informalexample><programlisting>
GClosure *cc_foo, *cc_bar, *cc_baz;
cc_foo = g_cclosure_new (NULL, foo, NULL);
g_closure_set_marshal (cc_foo, g_cclosure_user_marshal_VOID__VOID);
cc_bar = g_cclosure_new (NULL, bar, NULL);
g_closure_set_marshal (cc_bar, g_cclosure_user_marshal_VOID__INT);
cc_baz = g_cclosure_new (NULL, baz, NULL);
g_closure_set_marshal (cc_baz, g_cclosure_user_marshal_FLOAT__BOOLEAN_UCHAR);
</programlisting></informalexample>
</refsect1>
<refsect1><title>See also</title>
<para>
<citerefentry>
<refentrytitle>glib-mkenums</refentrytitle>
<manvolnum>1</manvolnum>
</citerefentry>
</para>
</refsect1>
</refentry>

View file

@ -0,0 +1,653 @@
<refentry id="glib-mkenums" lang="en">
<refentryinfo>
<title>gdbus</title>
<productname>GObject</productname>
<authorgroup>
<author>
<contrib>Developer</contrib>
<firstname>Owen</firstname>
<surname>Taylor</surname>
</author>
</authorgroup>
</refentryinfo>
<refmeta>
<refentrytitle>glib-mkenums</refentrytitle>
<manvolnum>1</manvolnum>
<refmiscinfo class="manual">User Commands</refmiscinfo>
</refmeta>
<refnamediv>
<refname>glib-mkenums</refname>
<refpurpose>C language enum description generation utility</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>glib-mkenums</command>
<arg choice="opt" rep="repeat">OPTION</arg>
<arg choice="opt" rep="repeat">FILE</arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1><title>Description</title>
<para><command>glib-mkenums</command> is a small utility that parses C code to
extract enum definitions and produces enum descriptions based on text templates
specified by the user. Typically, you can use this tool to generate enumeration
types for the GType type system, for GObject properties and signal marshalling;
additionally, you can use it to generate enumeration values of GSettings schemas.
</para>
<para><command>glib-mkenums</command> takes a list of valid C code files as
input. The options specified control the text that generated, substituting various
keywords enclosed in <literal>@</literal> characters in the templates.
</para>
<refsect2><title>Production text substitutions</title>
<para>
Certain keywords enclosed in <literal>@</literal> characters will be substituted in the
emitted text. For the substitution examples of the keywords below,
the following example enum definition is assumed:
</para>
<informalexample><programlisting>
typedef enum
{
PREFIX_THE_XVALUE = 1 &lt;&lt; 3,
PREFIX_ANOTHER_VALUE = 1 &lt;&lt; 4
} PrefixTheXEnum;
</programlisting></informalexample>
<variablelist>
<varlistentry>
<term><literal>@EnumName@</literal>></term>
<listitem><para>
The name of the enum currently being processed, enum names are assumed to be
properly namespaced and to use mixed capitalization to separate
words (e.g. <literal>PrefixTheXEnum</literal>).
</para></listitem>
</varlistentry>
<varlistentry>
<term><literal>@enum_name@</literal></term>
<listitem><para>
The enum name with words lowercase and word-separated by underscores
(e.g. <literal>prefix_the_xenum</literal>).
</para></listitem>
</varlistentry>
<varlistentry>
<term><literal>@ENUMNAME@</literal></term>
<listitem><para>
The enum name with words uppercase and word-separated by underscores
(e.g. <literal>PREFIX_THE_XENUM</literal>).
</para></listitem>
</varlistentry>
<varlistentry>
<term><literal>@ENUMSHORT@</literal></term>
<listitem><para>
The enum name with words uppercase and word-separated by underscores,
prefix stripped (e.g. <literal>THE_XENUM</literal>).
</para></listitem>
</varlistentry>
<varlistentry>
<term><literal>@ENUMPREFIX@</literal></term>
<listitem><para>
The prefix of the enum name (e.g. <literal>PREFIX</literal>).
</para></listitem>
</varlistentry>
<varlistentry>
<term><literal>@VALUENAME@</literal></term>
<listitem><para>
The enum value name currently being processed with words uppercase and
word-separated by underscores,
this is the assumed literal notation of enum values in the C sources
(e.g. <literal>PREFIX_THE_XVALUE</literal>).
</para></listitem>
</varlistentry>
<varlistentry>
<term><literal>@valuenick@</literal></term>
<listitem><para>
A nick name for the enum value currently being processed, this is usually
generated by stripping common prefix words of all the enum values of the
current enum, the words are lowercase and underscores are substituted by a
minus (e.g. <literal>the-xvalue</literal>).
</para></listitem>
</varlistentry>
<varlistentry>
<term><literal>@valuenum@</literal></term>
<listitem><para>
The integer value for the enum value currently being processed. If the
evaluation fails then <command>glib-mkenums</command> will exit with an
error status, but this only happens if <literal>@valuenum@</literal>
appears in your value production template. (Since: 2.26)
</para></listitem>
</varlistentry>
<varlistentry>
<term><literal>@type@</literal></term>
<listitem><para>
This is substituted either by "enum" or "flags", depending on whether the
enum value definitions contained bit-shift operators or not (e.g. <literal>flags</literal>).
</para></listitem>
</varlistentry>
<varlistentry>
<term><literal>@Type@</literal></term>
<listitem><para>
The same as <literal>@type@</literal> with the first letter capitalized (e.g. <literal>Flags</literal>).
</para></listitem>
</varlistentry>
<varlistentry>
<term><literal>@TYPE@</literal></term>
<listitem><para>
The same as <literal>@type@</literal> with all letters uppercased (e.g. <literal>FLAGS</literal>).
</para></listitem>
</varlistentry>
<varlistentry>
<term><literal>@filename@</literal></term>
<listitem><para>
The full path of the input file currently being processed (e.g. <literal>/build/environment/project/src/foo.h</literal>).
</para></listitem>
</varlistentry>
<varlistentry>
<term><literal>@basename@</literal></term>
<listitem><para>
The base name of the input file currently being processed (e.g. <literal>foo.h</literal>).
Typically you want to use <literal>@basename@</literal> in place of <literal>@filename@</literal>
in your templates, to improve the reproducibility of the build. (Since: 2.22)
</para></listitem>
</varlistentry>
</variablelist>
</refsect2>
<refsect2><title>Trigraph extensions</title>
<para>
Some C comments are treated specially in the parsed enum definitions,
such comments start out with the trigraph sequence <literal>/*&lt;</literal>
and end with the trigraph sequence <literal>&gt;*/</literal>.
</para>
<para>The following options can be specified per enum definition:</para>
<variablelist>
<varlistentry>
<term><literal>skip</literal></term>
<listitem><para>
Indicates this enum definition should be skipped.
</para></listitem>
</varlistentry>
<varlistentry>
<term><literal>flags</literal></term>
<listitem><para>
Indicates this enum should be treated as a flags definition.
</para></listitem>
</varlistentry>
<varlistentry>
<term><literal>underscore_name</literal></term>
<listitem><para>
Specifies the word separation used in the <function>*_get_type()</function>
function. For instance, <literal>/*&lt; underscore_name=gnome_vfs_uri_hide_options &gt;*/</literal>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><literal>since</literal></term>
<listitem><para>
Specifies the version tag that will be used to substitute the <literal>@enumsince@</literal>
keyword in the template, useful when documenting methods generated from the enums
(e.g. <literal>Since: @enumsince@</literal>). (Since: 2.66)
</para></listitem>
</varlistentry>
</variablelist>
<para>The following options can be specified per value definition:</para>
<variablelist>
<varlistentry>
<term><literal>skip</literal></term>
<listitem><para>
Indicates the value should be skipped.
</para></listitem>
</varlistentry>
<varlistentry>
<term><literal>nick</literal></term>
<listitem><para>
Specifies the otherwise auto-generated nickname.
</para></listitem>
</varlistentry>
</variablelist>
<para>Examples:</para>
<informalexample><programlisting>
typedef enum /*&lt; skip &gt;*/
{
PREFIX_FOO
} PrefixThisEnumWillBeSkipped;
typedef enum /*&lt; flags,prefix=PREFIX,since=1.0 &gt;*/
{
PREFIX_THE_ZEROTH_VALUE, /*&lt; skip &gt;*/
PREFIX_THE_FIRST_VALUE,
PREFIX_THE_SECOND_VALUE,
PREFIX_THE_THIRD_VALUE, /*&lt; nick=the-last-value &gt;*/
} PrefixTheFlagsEnum;
</programlisting></informalexample>
</refsect2>
</refsect1>
<refsect1><title>Options</title>
<variablelist>
<varlistentry>
<term><option>--fhead</option> <replaceable>TEXT</replaceable></term>
<listitem><para>
Emits <replaceable>TEXT</replaceable> prior to processing input files.
</para>
<para>
You can specify this option multiple times, and the <replaceable>TEXT</replaceable>
will be concatenated.
</para>
<para>
When used along with a template file, <replaceable>TEXT</replaceable>
will be prepended to the template's <literal>file-header</literal> section.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--fprod</option> <replaceable>TEXT</replaceable></term>
<listitem><para>
Emits <replaceable>TEXT</replaceable> every time a new input file
is being processed.
</para>
<para>
You can specify this option multiple times, and the <replaceable>TEXT</replaceable>
will be concatenated.
</para>
<para>
When used along with a template file, <replaceable>TEXT</replaceable>
will be appended to the template's <literal>file-production</literal> section.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--ftail</option> <replaceable>TEXT</replaceable></term>
<listitem><para>
Emits <replaceable>TEXT</replaceable> after all input files have been
processed.
</para>
<para>
You can specify this option multiple times, and the <replaceable>TEXT</replaceable>
will be concatenated.
</para>
<para>
When used along with a template file, <replaceable>TEXT</replaceable>
will be appended to the template's <literal>file-tail</literal> section.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--eprod</option> <replaceable>TEXT</replaceable></term>
<listitem><para>
Emits <replaceable>TEXT</replaceable> every time an enum is encountered
in the input files.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--vhead</option> <replaceable>TEXT</replaceable></term>
<listitem><para>
Emits <replaceable>TEXT</replaceable> before iterating over the set of
values of an enum.
</para>
<para>
You can specify this option multiple times, and the <replaceable>TEXT</replaceable>
will be concatenated.
</para>
<para>
When used along with a template file, <replaceable>TEXT</replaceable>
will be prepended to the template's <literal>value-header</literal> section.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--vprod</option> <replaceable>TEXT</replaceable></term>
<listitem><para>
Emits <replaceable>TEXT</replaceable> for every value of an enum.
</para>
<para>
You can specify this option multiple times, and the <replaceable>TEXT</replaceable>
will be concatenated.
</para>
<para>
When used along with a template file, <replaceable>TEXT</replaceable>
will be appended to the template's <literal>value-production</literal> section.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--vtail</option> <replaceable>TEXT</replaceable></term>
<listitem><para>
Emits <replaceable>TEXT</replaceable> after iterating over all values
of an enum.
</para>
<para>
You can specify this option multiple times, and the <replaceable>TEXT</replaceable>
will be concatenated.
</para>
<para>
When used along with a template file, <replaceable>TEXT</replaceable>
will be appended to the template's <literal>value-tail</literal> section.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--comments</option> <replaceable>TEXT</replaceable></term>
<listitem><para>
Template for auto-generated comments, the default (for C code generations) is
<literal>"/* @comment@ */"</literal>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--template</option> <replaceable>FILE</replaceable></term>
<listitem><para>
Read templates from the given file. The templates are enclosed in
specially-formatted C comments:
</para>
<informalexample><programlisting>
/*** BEGIN section ***/
/*** END section ***/
</programlisting></informalexample>
<para>
<replaceable>section</replaceable> may be <literal>file-header</literal>,
<literal>file-production</literal>, <literal>file-tail</literal>,
<literal>enumeration-production</literal>, <literal>value-header</literal>,
<literal>value-production</literal>, <literal>value-tail</literal> or
<literal>comment</literal>.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--identifier-prefix</option> <replaceable>PREFIX</replaceable></term>
<listitem><para>
Indicates what portion of the enum name should be interpreted as the
prefix (eg, the "<literal>Gtk</literal>" in
"<literal>GtkDirectionType</literal>"). Normally this will be figured
out automatically, but you may need to override the default if your
namespace is capitalized oddly.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--symbol-prefix</option> <replaceable>PREFIX</replaceable></term>
<listitem><para>
Indicates what prefix should be used to correspond to the identifier
prefix in related C function names (eg, the "<literal>gtk</literal>"
in "<literal>gtk_direction_type_get_type</literal>". Equivalently,
this is the lowercase version of the prefix component of the enum
value names (eg, the "<literal>GTK</literal>" in
"<literal>GTK_DIR_UP</literal>". The default value is the identifier
prefix, converted to lowercase.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--help</option></term>
<listitem><para>
Print brief help and exit.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--version</option></term>
<listitem><para>
Print version and exit.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--output=FILE</option></term>
<listitem><para>
Write output to FILE instead of stdout.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>@RSPFILE</option></term>
<listitem><para>
When passed as the sole argument, read and parse the actual arguments from
<literal>RSPFILE</literal>. Useful on systems with a low command-line length
limit. For example, Windows has a limit of 8191 characters.
</para></listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1><title>Using templates</title>
<para>
Instead of passing the various sections of the generated file to the command
line of <command>glib-mkenums</command>, it's strongly recommended to use a
template file, especially for generating C sources.
</para>
<para>
A C header template file will typically look like this:
</para>
<informalexample><programlisting>
/*** BEGIN file-header ***/
#pragma once
/* Include the main project header */
#include "project.h"
G_BEGIN_DECLS
/*** END file-header ***/
/*** BEGIN file-production ***/
/* enumerations from "@basename@" */
/*** END file-production ***/
/*** BEGIN value-header ***/
GType @enum_name@_get_type (void) G_GNUC_CONST;
#define @ENUMPREFIX@_TYPE_@ENUMSHORT@ (@enum_name@_get_type ())
/*** END value-header ***/
/*** BEGIN file-tail ***/
G_END_DECLS
/*** END file-tail ***/
</programlisting></informalexample>
<para>
A C source template file will typically look like this:
</para>
<informalexample><programlisting>
/*** BEGIN file-header ***/
#include "config.h"
#include "enum-types.h"
/*** END file-header ***/
/*** BEGIN file-production ***/
/* enumerations from "@basename@" */
/*** END file-production ***/
/*** BEGIN value-header ***/
GType
@enum_name@_get_type (void)
{
static gsize static_g_@type@_type_id;
if (g_once_init_enter (&amp;static_g_@type@_type_id))
{
static const G@Type@Value values[] = {
/*** END value-header ***/
/*** BEGIN value-production ***/
{ @VALUENAME@, "@VALUENAME@", "@valuenick@" },
/*** END value-production ***/
/*** BEGIN value-tail ***/
{ 0, NULL, NULL }
};
GType g_@type@_type_id =
g_@type@_register_static (g_intern_static_string ("@EnumName@"), values);
g_once_init_leave (&amp;static_g_@type@_type_id, g_@type@_type_id);
}
return static_g_@type@_type_id;
}
/*** END value-tail ***/
</programlisting></informalexample>
<para>
Template files are easier to modify and update, and can be used
to generate various types of outputs using the same command line
or tools during the build.
</para>
</refsect1>
<refsect1><title>Using glib-mkenums with Meson</title>
<para>
Meson supports generating enumeration types using <command>glib-mkenums</command>
out of the box in its "gnome" module.
</para>
<para>
In your <filename>meson.build</filename> file you will typically call the
<literal>gnome.mkenums_simple()</literal> method to generate idiomatic enumeration
types from a list of headers to inspect:
</para>
<informalexample><programlisting>
project_headers = [
'project-foo.h',
'project-bar.h',
'project-baz.h',
]
gnome = import('gnome')
enum_files = gnome.mkenums_simple('enum-types',
sources: project_headers,
)
</programlisting></informalexample>
<para>
The <literal>enum_files</literal> variable will contain an array of two elements
in the following order:
</para>
<itemizedlist>
<listitem><para>a build target for the source file</para></listitem>
<listitem><para>a build target for the header file</para></listitem>
</itemizedlist>
<para>
You should use the returned objects to provide a dependency on every other
build target that references the source or header file; for instance, if you
are using the source to build a library:
</para>
<informalexample><programlisting>
mainlib = library('project',
sources: project_sources + enum_files,
...
)
</programlisting></informalexample>
<para>
Additionally, if you are including the generated header file inside a build
target that depends on the library you just built, you must ensure that the
internal dependency includes the generated header as a required source file:
</para>
<informalexample><programlisting>
mainlib_dep = declare_dependency(sources: enum_files[1], link_with: mainlib)
</programlisting></informalexample>
<para>
You should not include the generated source file as well, otherwise it will
be built separately for every target that depends on it, causing build
failures. To know more about why all this is required, please refer to the
<ulink url="https://mesonbuild.com/FAQ.html#how-do-i-tell-meson-that-my-sources-use-generated-headers">
corresponding Meson FAQ entry</ulink>.
</para>
<para>
If you are generating C header and source files that require special
templates, you can use <literal>gnome.mkenums()</literal> to provide those
headers, for instance:
</para>
<informalexample><programlisting>
enum_files = gnome.mkenums('enum-types',
sources: project_headers,
h_template: 'enum-types.h.in',
c_template: 'enum-types.c.in',
install_header: true,
)
</programlisting></informalexample>
<para>
For more information, see the <ulink url="https://mesonbuild.com/Gnome-module.html#gnomegenmarshal">Meson
documentation for <literal>gnome.mkenums()</literal></ulink>.
</para>
</refsect1>
<refsect1><title>Using glib-mkenums with Autotools</title>
<para>
In order to use <command>glib-mkenums</command> in your project when using
Autotools as the build system, you will first need to modify your
<filename>configure.ac</filename> file to ensure you find the appropriate
command using <command>pkg-config</command>, similarly as to how you discover
the compiler and linker flags for GLib.
</para>
<informalexample><programlisting>
PKG_PROG_PKG_CONFIG([0.28])
PKG_CHECK_VAR([GLIB_MKENUMS], [glib-2.0], [glib_mkenums])
</programlisting></informalexample>
<para>
In your <filename>Makefile.am</filename> file you will typically use rules
like these:
</para>
<informalexample><programlisting>
# A list of headers to inspect
project_headers = \
project-foo.h \
project-bar.h \
project-baz.h
enum-types.h: $(project_headers) enum-types.h.in
$(AM_V_GEN)$(GLIB_MKENUMS) \
--template=enum-types.h.in \
--output=$@ \
$(project_headers)
enum-types.c: $(project_headers) enum-types.c.in enum-types.h
$(AM_V_GEN)$(GLIB_MKENUMS) \
--template=enum-types.c.in \
--output=$@ \
$(project_headers)
# Build the enum types files before every other target
BUILT_SOURCES += enum-types.h enum-types.c
CLEANFILES += enum-types.h enum-types.c
EXTRA_DIST += enum-types.h.in enum-types.c.in
</programlisting></informalexample>
<para>
In the example above, we have a variable called <literal>project_headers</literal>
where we reference all header files we want to inspect for generating enumeration
GTypes. In the <filename>enum-types.h</filename> rule we use <command>glib-mkenums</command>
with a template called <filename>enum-types.h.in</filename> in order to generate the
header file; similarly, in the <filename>enum-types.c</filename> rule we use a
template called <filename>enum-types.c.in</filename>.
</para>
</refsect1>
<refsect1><title>See also</title>
<para>
<citerefentry>
<refentrytitle>glib-genmarshal</refentrytitle>
<manvolnum>1</manvolnum>
</citerefentry>
</para>
</refsect1>
</refentry>

View file

@ -0,0 +1,224 @@
<?xml version="1.0"?>
<!DOCTYPE book PUBLIC '-//OASIS//DTD DocBook XML V4.5//EN'
'http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd' [
<!ENTITY % local.common.attrib "xmlns:xi CDATA #FIXED 'http://www.w3.org/2003/XInclude'">
<!ENTITY version SYSTEM "version.xml">
]>
<book id="index" xmlns:xi="http://www.w3.org/2003/XInclude">
<bookinfo>
<title>GObject Reference Manual</title>
<releaseinfo>
for GObject &version;
The latest version of this documentation can be found on-line at
<ulink role="online-location" url="https://developer.gnome.org/gobject/unstable/">https://developer.gnome.org/gobject/unstable/</ulink>.
</releaseinfo>
</bookinfo>
<preface>
<title>Introduction</title>
<para>
Most modern programming languages come with their own native object
systems and additional fundamental algorithmic language constructs.
Just as GLib serves as an implementation of such fundamental
types and algorithms (linked lists, hash tables and so forth), the
GLib Object System provides the required implementations of a
flexible, extensible, and intentionally easy to map (into other
languages) object-oriented framework for C.
The substantial elements that are provided can be summarized as:
<itemizedlist>
<listitem><para>
A generic type system to register arbitrary single-inherited
flat and deep derived types as well as interfaces for
structured types.
It takes care of creation, initialization and memory management
of the assorted object and class structures, maintains
parent/child relationships and deals with dynamic implementations
of such types. That is, their type specific implementations are
relocatable/unloadable during runtime.
</para></listitem>
<listitem><para>
A collection of fundamental type implementations, such as integers,
doubles, enums and structured types, to name a few.
</para></listitem>
<listitem><para>
A sample fundamental type implementation to base object hierarchies
upon - the GObject fundamental type.
</para></listitem>
<listitem><para>
A signal system that allows very flexible user customization of
virtual/overridable object methods and can serve as a powerful
notification mechanism.
</para></listitem>
<listitem><para>
An extensible parameter/value system, supporting all the provided
fundamental types that can be used to generically handle object
properties or otherwise parameterized types.
</para></listitem>
</itemizedlist>
</para>
</preface>
<part label="I">
<title>Concepts</title>
<xi:include href="tut_intro.xml" />
<xi:include href="tut_gtype.xml" />
<xi:include href="tut_gobject.xml" />
<xi:include href="tut_gsignal.xml" />
</part>
<reference label="II">
<title>API Reference</title>
<xi:include href="xml/gtype.xml" />
<xi:include href="xml/gtypeplugin.xml" />
<xi:include href="xml/gtypemodule.xml" />
<xi:include href="xml/objects.xml" />
<xi:include href="xml/enumerations_flags.xml" />
<xi:include href="xml/gboxed.xml" />
<xi:include href="xml/generic_values.xml" />
<xi:include href="xml/param_value_types.xml" />
<xi:include href="xml/gparamspec.xml" />
<xi:include href="xml/value_collection.xml" />
<xi:include href="xml/signals.xml" />
<xi:include href="xml/gsignalgroup.xml" />
<xi:include href="xml/gclosure.xml" />
<xi:include href="xml/value_arrays.xml" />
<xi:include href="xml/gbinding.xml" />
<xi:include href="xml/gbindinggroup.xml" />
</reference>
<reference label="III">
<title>Tools Reference</title>
<xi:include href="glib-mkenums.xml" />
<xi:include href="glib-genmarshal.xml" />
<xi:include href="gobject-query.xml" />
</reference>
<xi:include href="tut_howto.xml" />
<xi:include href="tut_tools.xml" />
<index id="api-index-full">
<title>Index</title>
<xi:include href="xml/api-index-full.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-deprecated" role="deprecated">
<title>Index of deprecated symbols</title>
<xi:include href="xml/api-index-deprecated.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-2" role="2.2">
<title>Index of new symbols in 2.2</title>
<xi:include href="xml/api-index-2.2.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-4" role="2.4">
<title>Index of new symbols in 2.4</title>
<xi:include href="xml/api-index-2.4.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-6" role="2.6">
<title>Index of new symbols in 2.6</title>
<xi:include href="xml/api-index-2.6.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-8" role="2.8">
<title>Index of new symbols in 2.8</title>
<xi:include href="xml/api-index-2.8.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-10" role="2.10">
<title>Index of new symbols in 2.10</title>
<xi:include href="xml/api-index-2.10.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-12" role="2.12">
<title>Index of new symbols in 2.12</title>
<xi:include href="xml/api-index-2.12.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-14" role="2.14">
<title>Index of new symbols in 2.14</title>
<xi:include href="xml/api-index-2.14.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-18" role="2.18">
<title>Index of new symbols in 2.18</title>
<xi:include href="xml/api-index-2.18.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-22" role="2.22">
<title>Index of new symbols in 2.22</title>
<xi:include href="xml/api-index-2.22.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-24" role="2.24">
<title>Index of new symbols in 2.24</title>
<xi:include href="xml/api-index-2.24.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-26" role="2.26">
<title>Index of new symbols in 2.26</title>
<xi:include href="xml/api-index-2.26.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-28" role="2.28">
<title>Index of new symbols in 2.28</title>
<xi:include href="xml/api-index-2.28.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-30" role="2.30">
<title>Index of new symbols in 2.30</title>
<xi:include href="xml/api-index-2.30.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-32" role="2.32">
<title>Index of new symbols in 2.32</title>
<xi:include href="xml/api-index-2.32.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-34" role="2.34">
<title>Index of new symbols in 2.34</title>
<xi:include href="xml/api-index-2.34.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-36" role="2.36">
<title>Index of new symbols in 2.36</title>
<xi:include href="xml/api-index-2.36.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-38" role="2.38">
<title>Index of new symbols in 2.38</title>
<xi:include href="xml/api-index-2.38.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-40" role="2.40">
<title>Index of new symbols in 2.40</title>
<xi:include href="xml/api-index-2.40.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-42" role="2.42">
<title>Index of new symbols in 2.42</title>
<xi:include href="xml/api-index-2.42.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-44" role="2.44">
<title>Index of new symbols in 2.44</title>
<xi:include href="xml/api-index-2.44.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-46" role="2.46">
<title>Index of new symbols in 2.46</title>
<xi:include href="xml/api-index-2.46.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-54" role="2.54">
<title>Index of new symbols in 2.54</title>
<xi:include href="xml/api-index-2.54.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-56" role="2.56">
<title>Index of new symbols in 2.56</title>
<xi:include href="xml/api-index-2.56.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-62" role="2.62">
<title>Index of new symbols in 2.62</title>
<xi:include href="xml/api-index-2.62.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-66" role="2.66">
<title>Index of new symbols in 2.66</title>
<xi:include href="xml/api-index-2.66.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-68" role="2.68">
<title>Index of new symbols in 2.68</title>
<xi:include href="xml/api-index-2.68.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-70" role="2.70">
<title>Index of new symbols in 2.70</title>
<xi:include href="xml/api-index-2.70.xml"><xi:fallback /></xi:include>
</index>
<index id="api-index-2-72" role="2.72">
<title>Index of new symbols in 2.72</title>
<xi:include href="xml/api-index-2.72.xml"><xi:fallback /></xi:include>
</index>
<xi:include href="xml/annotation-glossary.xml"><xi:fallback /></xi:include>
</book>

View file

@ -0,0 +1,123 @@
<refentry id="gobject-query" lang="en">
<refentryinfo>
<title>gobject-query</title>
<productname>GObject</productname>
<authorgroup>
<author>
<contrib>Developer</contrib>
<firstname>Tim</firstname>
<surname>Janik</surname>
</author>
</authorgroup>
</refentryinfo>
<refmeta>
<refentrytitle>gobject-query</refentrytitle>
<manvolnum>1</manvolnum>
<refmiscinfo class="manual">User Commands</refmiscinfo>
</refmeta>
<refnamediv>
<refname>gobject-query</refname>
<refpurpose>display a tree of types</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>gobject-query</command>
<arg choice="plain">froots</arg>
<arg choice="opt" rep="repeat">OPTION</arg>
</cmdsynopsis>
<cmdsynopsis>
<command>gobject-query</command>
<arg choice="plain">tree</arg>
<arg choice="opt" rep="repeat">OPTION</arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1><title>Description</title>
<para>
<command>gobject-query</command> is a small utility that draws a tree of
types.
</para>
<para>
<command>gobject-query</command> takes a mandatory argument that specifies
whether it should iterate over the fundamental types or print a type tree.
</para>
</refsect1>
<refsect1><title>Commands</title>
<variablelist>
<varlistentry>
<term><option>froots</option></term>
<listitem><para>
iterate over fundamental roots
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>tree</option></term>
<listitem><para>
print type tree
</para></listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1><title>Options</title>
<variablelist>
<varlistentry>
<term><option>-r</option> <replaceable>TYPE</replaceable></term>
<listitem><para>
specify the root type
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-n</option></term>
<listitem><para>
don't descend type tree
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-b</option> <replaceable>STRING</replaceable></term>
<listitem><para>
specify indent string
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-i</option> <replaceable>STRING</replaceable></term>
<listitem><para>
specify incremental indent string
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-s</option> <replaceable>NUMBER</replaceable></term>
<listitem><para>
specify line spacing
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-h</option>, <option>--help</option></term>
<listitem><para>
Print brief help and exit.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-v</option>, <option>--version</option></term>
<listitem><para>
Print version and exit.
</para></listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>

File diff suppressed because it is too large Load diff

Binary file not shown.

After

Width:  |  Height:  |  Size: 12 KiB

View file

@ -0,0 +1,68 @@
if get_option('gtk_doc')
subdir('xml')
ignore_headers = [
'tests',
'gatomicarray.h',
'gobject_probes.h',
'gobject_trace.h',
'gtype-private.h',
'glib-enumtypes.h',
]
docpath = join_paths(glib_datadir, 'gtk-doc', 'html')
version_conf = configuration_data()
version_conf.set('GLIB_VERSION', meson.project_version())
configure_file(
input: 'version.xml.in',
output: 'version.xml',
configuration: version_conf
)
gtkdocincl = include_directories('.')
gnome.gtkdoc('gobject',
main_xml : 'gobject-docs.xml',
namespace : 'g',
mode : 'none',
dependencies : [libgobject_dep, libglib_dep],
include_directories : [gtkdocincl],
src_dir : 'gobject',
scan_args : gtkdoc_common_scan_args + [
'--rebuild-types',
'--ignore-headers=' + ' '.join(ignore_headers),
],
content_files : [
'glib-mkenums.xml',
'glib-genmarshal.xml',
'gobject-query.xml',
'tut_gobject.xml',
'tut_gsignal.xml',
'tut_gtype.xml',
'tut_howto.xml',
'tut_intro.xml',
'tut_tools.xml'
],
html_assets : [
'images/glue.png'
],
fixxref_args: [
'--html-dir=' + docpath,
'--extra-dir=' + join_paths('gobject', '..', 'glib', 'html'),
],
install: true,
check: true,
)
endif
if get_option('man')
manpages = ['glib-mkenums', 'glib-genmarshal', 'gobject-query']
foreach page : manpages
custom_target(page + '-man',
input: page + '.xml',
output: page + '.1',
command: xsltproc_command,
install: true,
install_dir: man1_dir)
endforeach
endif

View file

@ -0,0 +1,728 @@
<?xml version='1.0' encoding="UTF-8"?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
]>
<chapter id="chapter-gobject">
<title>The GObject base class</title>
<para>
The previous chapter discussed the details of GLib's Dynamic Type System.
The GObject library also contains an implementation for a base fundamental
type named <link linkend="GObject"><type>GObject</type></link>.
</para>
<para>
<link linkend="GObject"><type>GObject</type></link> is a fundamental classed instantiatable type. It implements:
<itemizedlist>
<listitem><para>Memory management with reference counting</para></listitem>
<listitem><para>Construction/Destruction of instances</para></listitem>
<listitem><para>Generic per-object properties with set/get function pairs</para></listitem>
<listitem><para>Easy use of signals</para></listitem>
</itemizedlist>
All the GNOME libraries which use the GLib type system (like GTK+ and GStreamer)
inherit from <link linkend="GObject"><type>GObject</type></link> which is why it is important to understand
the details of how it works.
</para>
<sect1 id="gobject-instantiation">
<title>Object instantiation</title>
<para>
The <function><link linkend="g-object-new">g_object_new</link></function>
family of functions can be used to instantiate any GType which inherits
from the GObject base type. All these functions make sure the class and
instance structures have been correctly initialized by GLib's type system
and then invoke at one point or another the constructor class method
which is used to:
<itemizedlist>
<listitem><para>
Allocate and clear memory through <function><link linkend="g-type-create-instance">g_type_create_instance</link></function>,
</para></listitem>
<listitem><para>
Initialize the object's instance with the construction properties.
</para></listitem>
</itemizedlist>
Although one can expect all class and instance members (except the fields
pointing to the parents) to be set to zero, some consider it good practice
to explicitly set them.
</para>
<para>
Once all construction operations have been completed and constructor
properties set, the constructed class method is called.
</para>
<para>
Objects which inherit from GObject are allowed to override this
constructed class method.
The example below shows how <type>ViewerFile</type> overrides the parent's construction process:
<informalexample><programlisting>
#define VIEWER_TYPE_FILE viewer_file_get_type ()
G_DECLARE_FINAL_TYPE (ViewerFile, viewer_file, VIEWER, FILE, GObject)
struct _ViewerFile
{
GObject parent_instance;
/* instance members */
gchar *filename;
guint zoom_level;
};
/* will create viewer_file_get_type and set viewer_file_parent_class */
G_DEFINE_TYPE (ViewerFile, viewer_file, G_TYPE_OBJECT)
static void
viewer_file_constructed (GObject *obj)
{
/* update the object state depending on constructor properties */
/* Always chain up to the parent constructed function to complete object
* initialisation. */
G_OBJECT_CLASS (viewer_file_parent_class)-&gt;constructed (obj);
}
static void
viewer_file_finalize (GObject *obj)
{
ViewerFile *self = VIEWER_FILE (obj);
g_free (self->filename);
/* Always chain up to the parent finalize function to complete object
* destruction. */
G_OBJECT_CLASS (viewer_file_parent_class)-&gt;finalize (obj);
}
static void
viewer_file_class_init (ViewerFileClass *klass)
{
GObjectClass *object_class = G_OBJECT_CLASS (klass);
object_class-&gt;constructed = viewer_file_constructed;
object_class-&gt;finalize = viewer_file_finalize;
}
static void
viewer_file_init (ViewerFile *self)
{
/* initialize the object */
}
</programlisting></informalexample>
If the user instantiates an object <type>ViewerFile</type> with:
<informalexample><programlisting>
ViewerFile *file = g_object_new (VIEWER_TYPE_FILE, NULL);
</programlisting></informalexample>
If this is the first instantiation of such an object, the
<function>viewer_file_class_init</function> function will be invoked
after any <function>viewer_file_base_class_init</function> function.
This will make sure the class structure of this new object is
correctly initialized. Here, <function>viewer_file_class_init</function>
is expected to override the object's class methods and setup the
class' own methods. In the example above, the <literal>constructed</literal>
method is the only overridden method: it is set to
<function>viewer_file_constructed</function>.
</para>
<para>
Once <function><link linkend="g-object-new">g_object_new</link></function> has obtained a reference to an initialized
class structure, it invokes its constructor method to create an instance of the new
object, if the constructor has been overridden in <function>viewer_file_class_init</function>.
Overridden constructors must chain up to their parents constructor. In
order to find the parent class and chain up to the parent class
constructor, we can use the <literal>viewer_file_parent_class</literal>
pointer that has been set up for us by the
<link linkend="G-DEFINE-TYPE:CAPS"><literal>G_DEFINE_TYPE</literal></link>
macro.
</para>
<para>
Finally, at one point or another, <function>g_object_constructor</function> is invoked
by the last constructor in the chain. This function allocates the object's instance buffer
through <function><link linkend="g-type-create-instance">g_type_create_instance</link></function>
which means that the <function>instance_init</function> function is invoked at this point if one
was registered. After <function>instance_init</function> returns, the object is fully initialized and should be
ready to have its methods called by the user. When
<function><link linkend="g-type-create-instance">g_type_create_instance</link></function>
returns, <function>g_object_constructor</function> sets the construction properties
(i.e. the properties which were given to <function><link linkend="g-object-new">g_object_new</link></function>) and returns
to the user's constructor.
</para>
<para>
The process described above might seem a bit complicated, but it can be
summarized easily by the table below which lists the functions invoked
by <function><link linkend="g-object-new">g_object_new</link></function>
and their order of invocation:
</para>
<para>
<table id="gobject-construction-table">
<title><function><link linkend="g-object-new">g_object_new</link></function></title>
<tgroup cols="3">
<colspec colwidth="*" colnum="1" align="left"/>
<colspec colwidth="*" colnum="2" align="left"/>
<colspec colwidth="8*" colnum="3" align="left"/>
<thead>
<row>
<entry>Invocation time</entry>
<entry>Function invoked</entry>
<entry>Function's parameters</entry>
<entry>Remark</entry>
</row>
</thead>
<tbody>
<row>
<entry morerows="3">First call to <function><link linkend="g-object-new">g_object_new</link></function> for target type</entry>
<entry>target type's <function>base_init</function> function</entry>
<entry>On the inheritance tree of classes from fundamental type to target type.
<function>base_init</function> is invoked once for each class structure.</entry>
<entry>Never used in practice. Unlikely you will need it.</entry>
</row>
<row>
<!--entry>First call to <function><link linkend="g-object-new">g_object_new</link></function> for target type</entry-->
<entry>target type's <function>class_init</function> function</entry>
<entry>On target type's class structure</entry>
<entry>
Here, you should make sure to initialize or override class methods (that is,
assign to each class' method its function pointer) and create the signals and
the properties associated to your object.
</entry>
</row>
<row>
<!--entry>First call to <function><link linkend="g-object-new">g_object_new</link></function> for target type</entry-->
<entry>interface's <function>base_init</function> function</entry>
<entry>On interface's vtable</entry>
<entry></entry>
</row>
<row>
<!--entry>First call to <function><link linkend="g-object-new">g_object_new</link></function> for target type</entry-->
<entry>interface's <function>interface_init</function> function</entry>
<entry>On interface's vtable</entry>
<entry></entry>
</row>
<row>
<entry morerows="2">Each call to <function><link linkend="g-object-new">g_object_new</link></function> for target type</entry>
<entry>target type's class <function>constructor</function> method: <function>GObjectClass->constructor</function></entry>
<entry>On object's instance</entry>
<entry>
If you need to handle construct properties in a custom way, or implement a singleton class, override the constructor
method and make sure to chain up to the object's
parent class before doing your own initialization.
In doubt, do not override the constructor method.
</entry>
</row>
<row>
<!--entry>Each call to <function><link linkend="g-object-new">g_object_new</link></function> for target type</entry-->
<entry>type's <function>instance_init</function> function</entry>
<entry>On the inheritance tree of classes from fundamental type to target type.
the <function>instance_init</function> provided for each type is invoked once for each instance
structure.</entry>
<entry>
Provide an <function>instance_init</function> function to initialize your object before its construction
properties are set. This is the preferred way to initialize a GObject instance.
This function is equivalent to C++ constructors.
</entry>
</row>
<row>
<!--entry>Each call to <function><link linkend="g-object-new">g_object_new</link></function> for target type</entry-->
<entry>target type's class <function>constructed</function> method: <function>GObjectClass->constructed</function></entry>
<entry>On object's instance</entry>
<entry>
If you need to perform object initialization steps after all construct properties have been set.
This is the final step in the object initialization process, and is only called if the <function>constructor</function>
method returned a new object instance (rather than, for example, an existing singleton).
</entry>
</row>
</tbody>
</tgroup>
</table>
</para>
<para>
Readers should feel concerned about one little twist in the order in
which functions are invoked: while, technically, the class' constructor
method is called <emphasis>before</emphasis> the GType's <function>instance_init</function>
function (since <function><link linkend="g-type-create-instance">g_type_create_instance</link></function> which calls <function>instance_init</function> is called by
<function>g_object_constructor</function> which is the top-level class
constructor method and to which users are expected to chain to), the
user's code which runs in a user-provided constructor will always
run <emphasis>after</emphasis> GType's <function>instance_init</function> function since the
user-provided constructor <emphasis>must</emphasis> (you've been warned)
chain up <emphasis>before</emphasis> doing anything useful.
</para>
</sect1>
<sect1 id="gobject-memory">
<title>Object memory management</title>
<para>
The memory-management API for GObjects is a bit complicated but the idea behind it
is pretty simple: the goal is to provide a flexible model based on reference counting
which can be integrated in applications which use or require different memory management
models (such as garbage collection). The methods which are used to
manipulate this reference count are described below.
</para>
<sect2 id="gobject-memory-refcount">
<title>Reference count</title>
<para>
The functions <function><link linkend="g-object-ref">g_object_ref</link></function>/<function><link linkend="g-object-unref">g_object_unref</link></function> respectively
increase and decrease the reference count. These functions are
thread-safe.
<function><link linkend="g-clear-object">g_clear_object</link></function>
is a convenience wrapper around <function>g_object_unref</function>
which also clears the pointer passed to it.
</para>
<para>
The reference count is initialized to one by
<function><link linkend="g-object-new">g_object_new</link></function> which means that the caller
is currently the sole owner of the newly-created reference. (If the object is derived from <link linkend="GInitiallyUnowned"><type>GInitiallyUnowned</type></link>, this reference count is <link linkend="floating-ref">floating</link>.)
When the reference count reaches zero, that is,
when <function><link linkend="g-object-unref">g_object_unref</link></function> is called by the last client holding
a reference to the object, the <emphasis>dispose</emphasis> and the
<emphasis>finalize</emphasis> class methods are invoked.
</para>
<para>
Finally, after <emphasis>finalize</emphasis> is invoked,
<function><link linkend="g-type-free-instance">g_type_free_instance</link></function> is called to free the object instance.
Depending on the memory allocation policy decided when the type was registered (through
one of the <function>g_type_register_*</function> functions), the object's instance
memory will be freed or returned to the object pool for this type.
Once the object has been freed, if it was the last instance of the type, the type's class
will be destroyed as described in <xref linkend="gtype-instantiatable-classed"/> and
<xref linkend="gtype-non-instantiatable-classed"/>.
</para>
<para>
The table below summarizes the destruction process of a GObject:
<table id="gobject-destruction-table">
<title><function><link linkend="g-object-unref">g_object_unref</link></function></title>
<tgroup cols="3">
<colspec colwidth="*" colnum="1" align="left"/>
<colspec colwidth="*" colnum="2" align="left"/>
<colspec colwidth="8*" colnum="3" align="left"/>
<thead>
<row>
<entry>Invocation time</entry>
<entry>Function invoked</entry>
<entry>Function's parameters</entry>
<entry>Remark</entry>
</row>
</thead>
<tbody>
<row>
<entry morerows="1">Last call to <function><link linkend="g-object-unref">g_object_unref</link></function> for an instance
of target type
</entry>
<entry>target type's dispose class function</entry>
<entry>GObject instance</entry>
<entry>
When dispose ends, the object should not hold any reference to any other
member object. The object is also expected to be able to answer client
method invocations (with possibly an error code but no memory violation)
until finalize is executed. dispose can be executed more than once.
dispose should chain up to its parent implementation just before returning
to the caller.
</entry>
</row>
<row>
<!--entry>Last call to <function><link linkend="g-object-unref">g_object_unref</link></function> for an instance
of target type
</entry-->
<entry>target type's finalize class function</entry>
<entry>GObject instance</entry>
<entry>
Finalize is expected to complete the destruction process initiated by
dispose. It should complete the object's destruction. finalize will be
executed only once.
finalize should chain up to its parent implementation just before returning
to the caller.
The reason why the destruction process is split is two different phases is
explained in <xref linkend="gobject-memory-cycles"/>.
</entry>
</row>
<row>
<entry morerows="3">Last call to <function><link linkend="g-object-unref">g_object_unref</link></function> for the last
instance of target type
</entry>
<entry>interface's <function>interface_finalize</function> function</entry>
<entry>On interface's vtable</entry>
<entry>Never used in practice. Unlikely you will need it.</entry>
</row>
<row>
<!--entry>Last call to <function><link linkend="g-object-unref">g_object_unref</link></function>for the last
instance of target type
</entry-->
<entry>interface's <function>base_finalize</function> function</entry>
<entry>On interface's vtable</entry>
<entry>Never used in practice. Unlikely you will need it.</entry>
</row>
<row>
<!--entry>Last call to <function><link linkend="g-object-unref">g_object_unref</link></function> for the last
instance of target type
</entry-->
<entry>target type's <function>class_finalize</function> function</entry>
<entry>On target type's class structure</entry>
<entry>Never used in practice. Unlikely you will need it.</entry>
</row>
<row>
<!--entry>Last call to <function><link linkend="g-object-unref">g_object_unref</link></function> for the last
instance of target type
</entry-->
<entry>type's <function>base_finalize</function> function</entry>
<entry>On the inheritance tree of classes from fundamental type to target type.
<function>base_init</function> is invoked once for each class structure.</entry>
<entry>Never used in practice. Unlikely you will need it.</entry>
</row>
</tbody>
</tgroup>
</table>
</para>
</sect2>
<sect2 id="gobject-memory-weakref">
<title>Weak References</title>
<para>
Weak references are used to monitor object finalization:
<function><link linkend="g-object-weak-ref">g_object_weak_ref</link></function> adds a monitoring callback which does
not hold a reference to the object but which is invoked when the object runs
its dispose method. As such, each weak ref can be invoked more than once upon
object finalization (since dispose can run more than once during object
finalization).
</para>
<para>
<function><link linkend="g-object-weak-unref">g_object_weak_unref</link></function> can be used to remove a monitoring
callback from the object.
</para>
<para>
Weak references are also used to implement <function><link linkend="g-object-add-weak-pointer">g_object_add_weak_pointer</link></function>
and <function><link linkend="g-object-remove-weak-pointer">g_object_remove_weak_pointer</link></function>. These functions add a weak reference
to the object they are applied to which makes sure to nullify the pointer given by the user
when object is finalized.
</para>
<para>
Similarly, <link linkend="GWeakRef"><type>GWeakRef</type></link> can be
used to implement weak references if thread safety is required.
</para>
</sect2>
<sect2 id="gobject-memory-cycles">
<title>Reference counts and cycles</title>
<para>
GObject's memory management model was designed to be easily integrated in existing code
using garbage collection. This is why the destruction process is split in two phases:
the first phase, executed in the dispose handler is supposed to release all references
to other member objects. The second phase, executed by the finalize handler is supposed
to complete the object's destruction process. Object methods should be able to run
without program error in-between the two phases.
</para>
<para>
This two-step destruction process is very useful to break reference counting cycles.
While the detection of the cycles is up to the external code, once the cycles have been
detected, the external code can invoke <function><link linkend="g-object-run-dispose">g_object_run_dispose</link></function> which
will indeed break any existing cycles since it will run the dispose handler associated
to the object and thus release all references to other objects.
</para>
<para>
This explains one of the rules about the dispose handler stated earlier:
the dispose handler can be invoked multiple times. Let's say we
have a reference count cycle: object A references B which itself references object A.
Let's say we have detected the cycle and we want to destroy the two objects. One way to
do this would be to invoke <function><link linkend="g-object-run-dispose">g_object_run_dispose</link></function> on one of the
objects.
</para>
<para>
If object A releases all its references to all objects, this means it releases its
reference to object B. If object B was not owned by anyone else, this is its last
reference count which means this last unref runs B's dispose handler which, in turn,
releases B's reference on object A. If this is A's last reference count, this last
unref runs A's dispose handler which is running for the second time before
A's finalize handler is invoked !
</para>
<para>
The above example, which might seem a bit contrived, can really happen if
GObjects are being handled by language bindings — hence the rules for
object destruction should be closely followed.
</para>
</sect2>
</sect1>
<sect1 id="gobject-properties">
<title>Object properties</title>
<para>
One of GObject's nice features is its generic get/set mechanism for object
properties. When an object
is instantiated, the object's <function>class_init</function> handler should be used to register
the object's properties with <function><link linkend="g-object-class-install-properties">g_object_class_install_properties</link></function>.
</para>
<para>
The best way to understand how object properties work is by looking at a real example
of how it is used:
<informalexample><programlisting>
/************************************************/
/* Implementation */
/************************************************/
typedef enum
{
PROP_FILENAME = 1,
PROP_ZOOM_LEVEL,
N_PROPERTIES
} ViewerFileProperty;
static GParamSpec *obj_properties[N_PROPERTIES] = { NULL, };
static void
viewer_file_set_property (GObject *object,
guint property_id,
const GValue *value,
GParamSpec *pspec)
{
ViewerFile *self = VIEWER_FILE (object);
switch ((ViewerFileProperty) property_id)
{
case PROP_FILENAME:
g_free (self-&gt;filename);
self-&gt;filename = g_value_dup_string (value);
g_print ("filename: %s\n", self-&gt;filename);
break;
case PROP_ZOOM_LEVEL:
self-&gt;zoom_level = g_value_get_uint (value);
g_print ("zoom level: &percnt;u\n", self-&gt;zoom_level);
break;
default:
/* We don't have any other property... */
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, property_id, pspec);
break;
}
}
static void
viewer_file_get_property (GObject *object,
guint property_id,
GValue *value,
GParamSpec *pspec)
{
ViewerFile *self = VIEWER_FILE (object);
switch ((ViewerFileProperty) property_id)
{
case PROP_FILENAME:
g_value_set_string (value, self-&gt;filename);
break;
case PROP_ZOOM_LEVEL:
g_value_set_uint (value, self-&gt;zoom_level);
break;
default:
/* We don't have any other property... */
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, property_id, pspec);
break;
}
}
static void
viewer_file_class_init (ViewerFileClass *klass)
{
GObjectClass *object_class = G_OBJECT_CLASS (klass);
object_class-&gt;set_property = viewer_file_set_property;
object_class-&gt;get_property = viewer_file_get_property;
obj_properties[PROP_FILENAME] =
g_param_spec_string ("filename",
"Filename",
"Name of the file to load and display from.",
NULL /* default value */,
G_PARAM_CONSTRUCT_ONLY | G_PARAM_READWRITE);
obj_properties[PROP_ZOOM_LEVEL] =
g_param_spec_uint ("zoom-level",
"Zoom level",
"Zoom level to view the file at.",
0 /* minimum value */,
10 /* maximum value */,
2 /* default value */,
G_PARAM_READWRITE);
g_object_class_install_properties (object_class,
N_PROPERTIES,
obj_properties);
}
/************************************************/
/* Use */
/************************************************/
ViewerFile *file;
GValue val = G_VALUE_INIT;
file = g_object_new (VIEWER_TYPE_FILE, NULL);
g_value_init (&amp;val, G_TYPE_UINT);
g_value_set_char (&amp;val, 11);
g_object_set_property (G_OBJECT (file), "zoom-level", &amp;val);
g_value_unset (&amp;val);
</programlisting></informalexample>
The client code above looks simple but a lot of things happen under the hood:
</para>
<para>
<function><link linkend="g-object-set-property">g_object_set_property</link></function> first ensures a property
with this name was registered in <emphasis>file</emphasis>'s <function>class_init</function> handler. If so it walks the class hierarchy,
from bottom-most most-derived type, to top-most fundamental type to find the class
which registered that property. It then tries to convert the user-provided
<link linkend="GValue"><type>GValue</type></link>
into a <type>GValue</type> whose type is that of the associated property.
</para>
<para>
If the user provides a <type>signed char</type> <type>GValue</type>, as is shown
here, and if the object's property was registered as an <type>unsigned int</type>,
<function><link linkend="g-value-transform">g_value_transform</link></function> will try to transform the input signed char into
an unsigned int. Of course, the success of the transformation depends on the availability
of the required transform function. In practice, there will almost always be a transformation
<footnote>
<para>Its behaviour might not be what you expect but it is up to you to actually avoid
relying on these transformations.
</para>
</footnote>
which matches and conversion will be carried out if needed.
</para>
<para>
After transformation, the <link linkend="GValue"><type>GValue</type></link> is validated by
<function><link linkend="g-param-value-validate">g_param_value_validate</link></function> which makes sure the user's
data stored in the <link linkend="GValue"><type>GValue</type></link> matches the characteristics specified by
the property's <link linkend="GParamSpec"><type>GParamSpec</type></link>.
Here, the <link linkend="GParamSpec"><type>GParamSpec</type></link> we
provided in <function>class_init</function> has a validation function which makes sure that the GValue
contains a value which respects the minimum and maximum bounds of the
<link linkend="GParamSpec"><type>GParamSpec</type></link>. In the example above, the client's GValue does not
respect these constraints (it is set to 11, while the maximum is 10). As such, the
<function><link linkend="g-object-set-property">g_object_set_property</link></function> function will return with an error.
</para>
<para>
If the user's GValue had been set to a valid value, <function><link linkend="g-object-set-property">g_object_set_property</link></function>
would have proceeded with calling the object's
<function>set_property</function> class method. Here, since our
implementation of <type>ViewerFile</type> did override this method, execution would jump to
<function>viewer_file_set_property</function> after having retrieved from the
<link linkend="GParamSpec"><type>GParamSpec</type></link> the <emphasis>param_id</emphasis>
<footnote>
<para>
It should be noted that the param_id used here need only to uniquely identify each
<link linkend="GParamSpec"><type>GParamSpec</type></link> within the <type>ViewerFileClass</type> such that the switch
used in the set and get methods actually works. Of course, this locally-unique
integer is purely an optimization: it would have been possible to use a set of
<emphasis>if (strcmp (a, b) == 0) {} else if (strcmp (a, b) == 0) {}</emphasis> statements.
</para>
</footnote>
which had been stored by
<function><link linkend="g-object-class-install-property">g_object_class_install_property</link></function>.
</para>
<para>
Once the property has been set by the object's
<function>set_property</function> class method, execution
returns to <function><link linkend="g-object-set-property">g_object_set_property</link></function> which makes sure that
the "notify" signal is emitted on the object's instance with the changed property as
parameter unless notifications were frozen by <function><link linkend="g-object-freeze-notify">g_object_freeze_notify</link></function>.
</para>
<para>
<function><link linkend="g-object-thaw-notify">g_object_thaw_notify</link></function> can be used to re-enable notification of
property modifications through the
<link linkend="GObject-notify"><type>“notify”</type></link> signal. It is important to remember that
even if properties are changed while property change notification is frozen, the "notify"
signal will be emitted once for each of these changed properties as soon as the property
change notification is thawed: no property change is lost for the "notify"
signal, although multiple notifications for a single property are
compressed. Signals can only be delayed by the notification freezing
mechanism.
</para>
<para>
It sounds like a tedious task to set up GValues every time when one wants to modify a property.
In practice one will rarely do this. The functions <function><link linkend="g-object-set-property">g_object_set_property</link></function>
and <function><link linkend="g-object-get-property">g_object_get_property</link></function>
are meant to be used by language bindings. For application there is an easier way and
that is described next.
</para>
<sect2 id="gobject-multi-properties">
<title>Accessing multiple properties at once</title>
<para>
It is interesting to note that the <function><link linkend="g-object-set">g_object_set</link></function> and
<function><link linkend="g-object-set-valist">g_object_set_valist</link></function> (variadic version) functions can be used to set
multiple properties at once. The client code shown above can then be re-written as:
<informalexample><programlisting>
ViewerFile *file;
file = /* */;
g_object_set (G_OBJECT (file),
"zoom-level", 6,
"filename", "~/some-file.txt",
NULL);
</programlisting></informalexample>
This saves us from managing the GValues that we were needing to handle when using
<function><link linkend="g-object-set-property">g_object_set_property</link></function>.
The code above will trigger one notify signal emission for each property modified.
</para>
<para>
Equivalent <function>_get</function> versions are also available:
<function><link linkend="g-object-get">g_object_get</link></function>
and <function><link linkend="g-object-get-valist">g_object_get_valist</link></function> (variadic version) can be used to get numerous
properties at once.
</para>
<para>
These high level functions have one drawback — they don't provide a return value.
One should pay attention to the argument types and ranges when using them.
A known source of errors is to pass a different type from what the
property expects; for instance, passing an integer when the property
expects a floating point value and thus shifting all subsequent parameters
by some number of bytes. Also forgetting the terminating
<literal>NULL</literal> will lead to undefined behaviour.
</para>
<para>
This explains how <function><link linkend="g-object-new">g_object_new</link></function>,
<function><link linkend="g-object-newv">g_object_newv</link></function> and <function><link linkend="g-object-new-valist">g_object_new_valist</link></function>
work: they parse the user-provided variable number of parameters and invoke
<function><link linkend="g-object-set">g_object_set</link></function> on the parameters only after the object has been successfully constructed.
The "notify" signal will be emitted for each property set.
</para>
</sect2>
<!-- @todo tell here about how to pass use handle properties in derived classes -->
</sect1>
</chapter>

View file

@ -0,0 +1,495 @@
<?xml version='1.0' encoding="UTF-8"?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
]>
<chapter id="chapter-signal">
<title>The GObject messaging system</title>
<sect1 id="closure">
<title>Closures</title>
<para>
Closures are central to the concept of asynchronous signal delivery
which is widely used throughout GTK+ and GNOME applications. A closure is an
abstraction, a generic representation of a callback. It is a small structure
which contains three objects:
<itemizedlist>
<listitem><para>a function pointer (the callback itself) whose prototype looks like:
<informalexample><programlisting>
return_type function_callback (… , gpointer user_data);
</programlisting></informalexample>
</para></listitem>
<listitem><para>
the <parameter>user_data</parameter> pointer which is passed to the callback upon invocation of the closure
</para></listitem>
<listitem><para>
a function pointer which represents the destructor of the closure: whenever the
closure's refcount reaches zero, this function will be called before the closure
structure is freed.
</para></listitem>
</itemizedlist>
</para>
<para>
The <link linkend="GClosure"><type>GClosure</type></link> structure represents the common functionality of all
closure implementations: there exists a different closure implementation for
each separate runtime which wants to use the GObject type system.
<footnote><para>
In practice, closures sit at the boundary of language runtimes: if you are
writing Python code and one of your Python callbacks receives a signal from
a GTK+ widget, the C code in GTK+ needs to execute your Python
code. The closure invoked by the GTK+ object invokes the Python callback:
it behaves as a normal C object for GTK+ and as a normal Python object for
Python code.
</para></footnote>
The GObject library provides a simple <link linkend="GCClosure"><type>GCClosure</type></link> type which
is a specific implementation of closures to be used with C/C++ callbacks.
</para>
<para>
A <link linkend="GClosure"><type>GClosure</type></link> provides simple services:
<itemizedlist>
<listitem><para>
Invocation (<function><link linkend="g-closure-invoke">g_closure_invoke</link></function>): this is what closures
were created for: they hide the details of callback invocation from the
callback invoker.</para>
</listitem>
<listitem><para>
Notification: the closure notifies listeners of certain events such as
closure invocation, closure invalidation and closure finalization. Listeners
can be registered with <function><link linkend="g-closure-add-finalize-notifier">g_closure_add_finalize_notifier</link></function>
(finalization notification), <function><link linkend="g-closure-add-invalidate-notifier">g_closure_add_invalidate_notifier</link></function>
(invalidation notification) and
<function><link linkend="g-closure-add-marshal-guards">g_closure_add_marshal_guards</link></function> (invocation notification).
There exist symmetric deregistration functions for finalization and invalidation
events (<function><link linkend="g-closure-remove-finalize-notifier">g_closure_remove_finalize_notifier</link></function> and
<function><link linkend="g-closure-remove-invalidate-notifier">g_closure_remove_invalidate_notifier</link></function>) but not for the invocation
process.
<footnote><para>
Closures are reference counted and notify listeners of their destruction in a two-stage
process: the invalidation notifiers are invoked before the finalization notifiers.
</para></footnote></para>
</listitem>
</itemizedlist>
</para>
<sect2>
<title>C Closures</title>
<para>
If you are using C or C++
to connect a callback to a given event, you will either use simple <link linkend="GCClosure"><type>GCClosure</type></link>s
which have a pretty minimal API or the even simpler <function><link linkend="g-signal-connect">g_signal_connect</link></function>
functions (which will be presented a bit later).
</para>
<para>
<function><link linkend="g-cclosure-new">g_cclosure_new</link></function> will create a new closure which can invoke the
user-provided callback_func with the user-provided
<parameter>user_data</parameter> as its last parameter. When the closure
is finalized (second stage of the destruction process), it will invoke
the <parameter>destroy_data</parameter> function if the user has
supplied one.
</para>
<para>
<function><link linkend="g-cclosure-new-swap">g_cclosure_new_swap</link></function> will create a new closure which can invoke the
user-provided <parameter>callback_func</parameter> with the
user-provided <parameter>user_data</parameter> as its first parameter
(instead of being the
last parameter as with <function><link linkend="g-cclosure-new">g_cclosure_new</link></function>). When the closure
is finalized (second stage of the destruction process), it will invoke
the <parameter>destroy_data</parameter> function if the user has
supplied one.
</para>
</sect2>
<sect2>
<title>Non-C closures (for the fearless)</title>
<para>
As was explained above, closures hide the details of callback invocation. In C,
callback invocation is just like function invocation: it is a matter of creating
the correct stack frame for the called function and executing a <emphasis>call</emphasis>
assembly instruction.
</para>
<para>
C closure marshallers transform the array of GValues which represent
the parameters to the target function into a C-style function parameter list, invoke
the user-supplied C function with this new parameter list, get the return value of the
function, transform it into a GValue and return this GValue to the marshaller caller.
</para>
<para>
A generic C closure marshaller is available as
<link linkend="g-cclosure-marshal-generic"><function>g_cclosure_marshal_generic</function></link>
which implements marshalling for all function types using libffi. Custom
marshallers for different types are not needed apart from performance
critical code where the libffi-based marshaller may be too slow.
</para>
<para>
An example of a custom marshaller is given below, illustrating how
<type>GValue</type>s can be converted to a C function call. The
marshaller is for a C function which takes an integer as its first
parameter and returns void.
<informalexample><programlisting>
g_cclosure_marshal_VOID__INT (GClosure *closure,
GValue *return_value,
guint n_param_values,
const GValue *param_values,
gpointer invocation_hint,
gpointer marshal_data)
{
typedef void (*GMarshalFunc_VOID__INT) (gpointer data1,
gint arg_1,
gpointer data2);
register GMarshalFunc_VOID__INT callback;
register GCClosure *cc = (GCClosure*) closure;
register gpointer data1, data2;
g_return_if_fail (n_param_values == 2);
data1 = g_value_peek_pointer (param_values + 0);
data2 = closure->data;
callback = (GMarshalFunc_VOID__INT) (marshal_data ? marshal_data : cc->callback);
callback (data1,
g_marshal_value_peek_int (param_values + 1),
data2);
}
</programlisting></informalexample>
</para>
<para>
There exist other kinds of marshallers, for example there is a generic
Python marshaller which is used by all Python closures (a Python closure
is used to invoke a callback written in Python). This Python marshaller
transforms the input GValue list representing the function parameters
into a Python tuple which is the equivalent structure in Python.
</para>
</sect2>
</sect1>
<sect1 id="signal">
<title>Signals</title>
<para>
GObject's signals have nothing to do with standard UNIX signals: they connect
arbitrary application-specific events with any number of listeners.
For example, in GTK+, every user event (keystroke or mouse move) is received
from the windowing system and generates a GTK+ event in the form of a signal emission
on the widget object instance.
</para>
<para>
Each signal is registered in the type system together with the type on which
it can be emitted: users of the type are said to <emphasis>connect</emphasis>
to the signal on a given type instance when they register a closure to be
invoked upon the signal emission. The closure will be called synchronously on emission.
Users can also emit the signal by themselves or stop the emission of the signal from
within one of the closures connected to the signal.
</para>
<para>
When a signal is emitted on a given type instance, all the closures
connected to this signal on this type instance will be invoked. All the closures
connected to such a signal represent callbacks whose signature looks like:
<informalexample><programlisting>
return_type function_callback (gpointer instance, …, gpointer user_data);
</programlisting></informalexample>
</para>
<sect2 id="signal-registration">
<title>Signal registration</title>
<para>
To register a new signal on an existing type, we can use any of <function><link linkend="g-signal-newv">g_signal_newv</link></function>,
<function><link linkend="g-signal-new-valist">g_signal_new_valist</link></function> or <function><link linkend="g-signal-new">g_signal_new</link></function> functions:
<informalexample><programlisting>
guint g_signal_newv (const gchar *signal_name,
GType itype,
GSignalFlags signal_flags,
GClosure *class_closure,
GSignalAccumulator accumulator,
gpointer accu_data,
GSignalCMarshaller c_marshaller,
GType return_type,
guint n_params,
GType *param_types);
</programlisting></informalexample>
The number of parameters to these functions is a bit intimidating but they are relatively
simple:
<itemizedlist>
<listitem><para>
<parameter>signal_name</parameter>: is a string which can be used to uniquely identify a given signal.
</para></listitem>
<listitem><para>
<parameter>itype</parameter>: is the instance type on which this signal can be emitted.
</para></listitem>
<listitem><para>
<parameter>signal_flags</parameter>: partly defines the order in which closures which were connected to the
signal are invoked.
</para></listitem>
<listitem><para>
<parameter>class_closure</parameter>: this is the default closure for the signal: if it is not NULL upon
the signal emission, it will be invoked upon this emission of the signal. The
moment where this closure is invoked compared to other closures connected to that
signal depends partly on the signal_flags.
</para></listitem>
<listitem><para>
<parameter>accumulator</parameter>: this is a function pointer which is invoked after each closure
has been invoked. If it returns FALSE, signal emission is stopped. If it returns
TRUE, signal emission proceeds normally. It is also used to compute the return
value of the signal based on the return value of all the invoked closures.
For example, an accumulator could ignore
<literal>NULL</literal> returns from closures; or it
could build a list of the values returned by the
closures.
</para></listitem>
<listitem><para>
<parameter>accu_data</parameter>: this pointer will be passed down to each invocation of the
accumulator during emission.
</para></listitem>
<listitem><para>
<parameter>c_marshaller</parameter>: this is the default C marshaller for any closure which is connected to
this signal.
</para></listitem>
<listitem><para>
<parameter>return_type</parameter>: this is the type of the return value of the signal.
</para></listitem>
<listitem><para>
<parameter>n_params</parameter>: this is the number of parameters this signal takes.
</para></listitem>
<listitem><para>
<parameter>param_types</parameter>: this is an array of GTypes which indicate the type of each parameter
of the signal. The length of this array is indicated by n_params.
</para></listitem>
</itemizedlist>
</para>
<para>
As you can see from the above definition, a signal is basically a description
of the closures which can be connected to this signal and a description of the
order in which the closures connected to this signal will be invoked.
</para>
</sect2>
<sect2 id="signal-connection">
<title>Signal connection</title>
<para>
If you want to connect to a signal with a closure, you have three possibilities:
<itemizedlist>
<listitem><para>
You can register a class closure at signal registration: this is a
system-wide operation. i.e.: the class closure will be invoked during each emission
of a given signal on <emphasis>any</emphasis> of the instances of the type which supports that signal.
</para></listitem>
<listitem><para>
You can use <function><link linkend="g-signal-override-class-closure">g_signal_override_class_closure</link></function> which
overrides the class closure of a given type. It is possible to call this function
only on a derived type of the type on which the signal was registered.
This function is of use only to language bindings.
</para></listitem>
<listitem><para>
You can register a closure with the <function><link linkend="g-signal-connect">g_signal_connect</link></function>
family of functions. This is an instance-specific operation: the closure
will be invoked only during emission of a given signal on a given instance.
</para></listitem>
</itemizedlist>
It is also possible to connect a different kind of callback on a given signal:
emission hooks are invoked whenever a given signal is emitted whatever the instance on
which it is emitted. Emission hooks are used for example to get all mouse_clicked
emissions in an application to be able to emit the small mouse click sound.
Emission hooks are connected with <function><link linkend="g-signal-add-emission-hook">g_signal_add_emission_hook</link></function>
and removed with <function><link linkend="g-signal-remove-emission-hook">g_signal_remove_emission_hook</link></function>.
</para>
</sect2>
<sect2 id="signal-emission">
<title>Signal emission</title>
<para>
Signal emission is done through the use of the <function><link linkend="g-signal-emit">g_signal_emit</link></function> family
of functions.
<informalexample><programlisting>
void g_signal_emitv (const GValue *instance_and_params,
guint signal_id,
GQuark detail,
GValue *return_value);
</programlisting></informalexample>
<itemizedlist>
<listitem><para>
The <parameter>instance_and_params</parameter> array of GValues contains the list of input
parameters to the signal. The first element of the array is the
instance pointer on which to invoke the signal. The following elements of
the array contain the list of parameters to the signal.
</para></listitem>
<listitem><para>
<parameter>signal_id</parameter> identifies the signal to invoke.
</para></listitem>
<listitem><para>
<parameter>detail</parameter> identifies the specific detail of the signal to invoke. A detail is a kind of
magic token/argument which is passed around during signal emission and which is used
by closures connected to the signal to filter out unwanted signal emissions. In most
cases, you can safely set this value to zero. See <xref linkend="signal-detail"/> for
more details about this parameter.
</para></listitem>
<listitem><para>
<parameter>return_value</parameter> holds the return value of the last closure invoked during emission if
no accumulator was specified. If an accumulator was specified during signal creation,
this accumulator is used to calculate the return value as a function of the return
values of all the closures invoked during emission.
If no closure is invoked during
emission, the <parameter>return_value</parameter> is nonetheless initialized to zero/null.
</para></listitem>
</itemizedlist>
</para>
<para>
Signal emission is done synchronously and can be decomposed in 5 steps:
<orderedlist>
<listitem><para>
<literal>RUN_FIRST</literal>: if the
<link linkend="G-SIGNAL-RUN-FIRST:CAPS"><literal>G_SIGNAL_RUN_FIRST</literal></link> flag was used
during signal registration and if there exists a class closure for this signal,
the class closure is invoked.
</para></listitem>
<listitem><para>
<literal>EMISSION_HOOK</literal>: if any emission hook was added to
the signal, they are invoked from first to last added. Accumulate return values.
</para></listitem>
<listitem><para>
<literal>HANDLER_RUN_FIRST</literal>: if any closure were connected
with the <function><link linkend="g-signal-connect">g_signal_connect</link></function> family of
functions, and if they are not blocked (with the <function><link linkend="g-signal-handler-block">g_signal_handler_block</link></function>
family of functions) they are run here, from first to last connected.
</para></listitem>
<listitem><para>
<literal>RUN_LAST</literal>: if the <literal>G_SIGNAL_RUN_LAST</literal>
flag was set during registration and if a class closure
was set, it is invoked here.
</para></listitem>
<listitem><para>
<literal>HANDLER_RUN_LAST</literal>: if any closure were connected
with the <function>g_signal_connect_after</function> family of
functions, if they were not invoked during <literal>HANDLER_RUN_FIRST</literal> and if they
are not blocked, they are run here, from first to last connected.
</para></listitem>
<listitem><para>
<literal>RUN_CLEANUP</literal>: if the <literal>G_SIGNAL_RUN_CLEANUP</literal> flag
was set during registration and if a class closure was set,
it is invoked here. Signal emission is completed here.
</para></listitem>
</orderedlist>
</para>
<para>
If, at any point during emission (except in <literal>RUN_CLEANUP</literal> or
<literal>EMISSION_HOOK</literal> state), one of the closures stops the signal emission with
<function><link linkend="g-signal-stop-emission">g_signal_stop_emission</link></function>,
emission jumps to <literal>RUN_CLEANUP</literal> state.
</para>
<para>
If, at any point during emission, one of the closures or emission hook
emits the same signal on the same instance, emission is restarted from
the <literal>RUN_FIRST</literal> state.
</para>
<para>
The accumulator function is invoked in all states, after invocation
of each closure (except in <literal>RUN_EMISSION_HOOK</literal> and
<literal>RUN_CLEANUP</literal>). It accumulates
the closure return value into the signal return value and returns TRUE or
FALSE. If, at any point, it does not return TRUE, emission jumps
to <literal>RUN_CLEANUP</literal> state.
</para>
<para>
If no accumulator function was provided, the value returned by the last handler
run will be returned by <function><link linkend="g-signal-emit">g_signal_emit</link></function>.
</para>
</sect2>
<sect2 id="signal-detail">
<title>The <emphasis>detail</emphasis> argument</title>
<para>All the functions related to signal emission or signal connection have a parameter
named the <emphasis>detail</emphasis>. Sometimes, this parameter is hidden by the API
but it is always there, in one form or another.
</para>
<para>
Of the three main connection functions,
only one has an explicit detail parameter as a <link linkend="GQuark"><type>GQuark</type></link>:
<link linkend="g-signal-connect-closure-by-id"><function>g_signal_connect_closure_by_id</function></link>.
<footnote>
<para>A GQuark is an integer which uniquely represents a string. It is possible to transform
back and forth between the integer and string representations with the functions
<function><link linkend="g-quark-from-string">g_quark_from_string</link></function> and <function><link linkend="g-quark-to-string">g_quark_to_string</link></function>.
</para>
</footnote>
</para>
<para>
The two other functions,
<link linkend="g-signal-connect-closure"><function>g_signal_connect_closure</function></link> and
<link linkend="g-signal-connect-data"><function>g_signal_connect_data</function></link>
hide the detail parameter in the signal name identification.
Their <parameter>detailed_signal</parameter> parameter is a
string which identifies the name of the signal to connect to.
The format of this string should match
<emphasis>signal_name::detail_name</emphasis>. For example,
connecting to the signal named
<emphasis>notify::cursor_position</emphasis> will actually
connect to the signal named <emphasis>notify</emphasis> with the
<emphasis>cursor_position</emphasis> detail.
Internally, the detail string is transformed to a GQuark if it is present.
</para>
<para>
Of the four main signal emission functions, one hides it in its
signal name parameter:
<link linkend="g-signal-connect"><function>g_signal_connect</function></link>.
The other three have an explicit detail parameter as a
<link linkend="GQuark"><type>GQuark</type></link> again:
<link linkend="g-signal-emit"><function>g_signal_emit</function></link>,
<link linkend="g-signal-emitv"><function>g_signal_emitv</function></link> and
<link linkend="g-signal-emit-valist"><function>g_signal_emit_valist</function></link>.
</para>
<para>
If a detail is provided by the user to the emission function, it is used during emission to match
against the closures which also provide a detail.
If a closure's detail does not match the detail provided by the user, it
will not be invoked (even though it is connected to a signal which is
being emitted).
</para>
<para>
This completely optional filtering mechanism is mainly used as an optimization for signals
which are often emitted for many different reasons: the clients can filter out which events they are
interested in before the closure's marshalling code runs. For example, this is used extensively
by the <link linkend="GObject-notify"><structfield>notify</structfield></link> signal of GObject: whenever a property is modified on a GObject,
instead of just emitting the <emphasis>notify</emphasis> signal, GObject associates as a detail to this
signal emission the name of the property modified. This allows clients who wish to be notified of changes
to only one property to filter most events before receiving them.
</para>
<para>
As a simple rule, users can and should set the detail parameter to zero: this will disable completely
this optional filtering for that signal.
</para>
</sect2>
</sect1>
</chapter>

File diff suppressed because it is too large Load diff

File diff suppressed because it is too large Load diff

View file

@ -0,0 +1,185 @@
<?xml version='1.0' encoding="UTF-8"?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
]>
<chapter id="chapter-intro">
<title>Background</title>
<para>
GObject, and its lower-level type system, GType, are used by GTK+ and most GNOME libraries to
provide:
<itemizedlist>
<listitem><para>object-oriented C-based APIs and</para></listitem>
<listitem><para>automatic transparent API bindings to other compiled
or interpreted languages.</para></listitem>
</itemizedlist>
</para>
<para>
A lot of programmers are used to working with compiled-only or dynamically interpreted-only
languages and do not understand the challenges associated with cross-language interoperability.
This introduction tries to provide an insight into these challenges and briefly describes
the solution chosen by GLib.
</para>
<para>
The following chapters go into greater detail into how GType and GObject work and
how you can use them as a C programmer. It is useful to keep in mind that
allowing access to C objects from other interpreted languages was one of the major design
goals: this can often explain the sometimes rather convoluted APIs and features present
in this library.
</para>
<sect1>
<title>Data types and programming</title>
<para>
One could say
that a programming language is merely a way to create data types and manipulate them. Most languages
provide a number of language-native types and a few primitives to create more complex types based
on these primitive types.
</para>
<para>
In C, the language provides types such as <emphasis>char</emphasis>, <emphasis>long</emphasis>,
<emphasis>pointer</emphasis>. During compilation of C code, the compiler maps these
language types to the compiler's target architecture machine types. If you are using a C interpreter
(assuming one exists), the interpreter (the program which interprets
the source code and executes it) maps the language types to the machine types of the target machine at
runtime, during the program execution (or just before execution if it uses a Just In Time compiler engine).
</para>
<para>
Perl and Python are interpreted languages which do not really provide type definitions similar
to those used by C. Perl and Python programmers manipulate variables and the type of the variables
is decided only upon the first assignment or upon the first use which forces a type on the variable.
The interpreter also often provides a lot of automatic conversions from one type to the other. For example,
in Perl, a variable which holds an integer can be automatically converted to a string given the
required context:
<informalexample><programlisting>
my $tmp = 10;
print "this is an integer converted to a string:" . $tmp . "\n";
</programlisting></informalexample>
Of course, it is also often possible to explicitly specify conversions when the default conversions provided
by the language are not intuitive.
</para>
</sect1>
<sect1>
<title>Exporting a C API</title>
<para>
C APIs are defined by a set of functions and global variables which are usually exported from a
binary. C functions have an arbitrary number of arguments and one return value. Each function is thus
uniquely identified by the function name and the set of C types which describe the function arguments
and return value. The global variables exported by the API are similarly identified by their name and
their type.
</para>
<para>
A C API is thus merely defined by a set of names to which a set of types are associated. If you know the
function calling convention and the mapping of the C types to the machine types used by the platform you
are on, you can resolve the name of each function to find where the code associated to this function
is located in memory, and then construct a valid argument list for the function. Finally, all you have to
do is trigger a call to the target C function with the argument list.
</para>
<para>
For the sake of discussion, here is a sample C function and the associated 32 bit x86
assembly code generated by GCC on a Linux computer:
<informalexample><programlisting>
static void
function_foo (int foo)
{
}
int
main (int argc,
char *argv[])
{
function_foo (10);
return 0;
}
push $0xa
call 0x80482f4 &lt;function_foo>
</programlisting></informalexample>
The assembly code shown above is pretty straightforward: the first instruction pushes
the hexadecimal value 0xa (decimal value 10) as a 32-bit integer on the stack and calls
<function>function_foo</function>. As you can see, C function calls are implemented by
GCC as native function calls (this is probably the fastest implementation possible).
</para>
<para>
Now, let's say we want to call the C function <function>function_foo</function> from
a Python program. To do this, the Python interpreter needs to:
<itemizedlist>
<listitem><para>Find where the function is located. This probably means finding the binary generated by the C compiler
which exports this function.</para></listitem>
<listitem><para>Load the code of the function in executable memory.</para></listitem>
<listitem><para>Convert the Python parameters to C-compatible parameters before calling
the function.</para></listitem>
<listitem><para>Call the function with the right calling convention.</para></listitem>
<listitem><para>Convert the return values of the C function to Python-compatible
variables to return them to the Python code.</para></listitem>
</itemizedlist>
</para>
<para>
The process described above is pretty complex and there are a lot of ways to make it entirely automatic
and transparent to C and Python programmers:
<itemizedlist>
<listitem><para>The first solution is to write by hand a lot of glue code, once for each function exported or imported,
which does the Python-to-C parameter conversion and the C-to-Python return value conversion. This glue code is then
linked with the interpreter which allows Python programs to call Python functions which delegate work to
C functions.</para></listitem>
<listitem><para>Another, nicer solution is to automatically generate the glue code, once for each function exported or
imported, with a special compiler which
reads the original function signature.</para></listitem>
<listitem><para>The solution used by GLib is to use the GType library which holds at runtime a description of
all the objects manipulated by the programmer. This so-called <emphasis>dynamic type</emphasis>
<footnote>
<para>
There are numerous different implementations of dynamic type systems: all C++
compilers have one, Java and .NET have one too. A dynamic type system allows you
to get information about every instantiated object at runtime. It can be implemented
by a process-specific database: every new object created registers the characteristics
of its associated type in the type system. It can also be implemented by introspection
interfaces. The common point between all these different type systems and implementations
is that they all allow you to query for object metadata at runtime.
</para>
</footnote>
library is then used by special generic glue code to automatically convert function parameters and
function calling conventions between different runtime domains.</para></listitem>
</itemizedlist>
The greatest advantage of the solution implemented by GType is that the glue code sitting at the runtime domain
boundaries is written once: the figure below states this more clearly.
<figure>
<mediaobject>
<imageobject> <!-- this is for HTML output -->
<imagedata fileref="glue.png" format="PNG" align="center"/>
</imageobject>
<imageobject> <!-- this is for PDF output -->
<imagedata fileref="glue.jpg" format="JPG" align="center"/>
</imageobject>
</mediaobject>
</figure>
Currently, there exist at least Python and Perl generic glue code which makes it possible to use
C objects written with GType directly in Python or Perl, with a minimum amount of work: there
is no need to generate huge amounts of glue code either automatically or by hand.
</para>
<para>
Although that goal was arguably laudable, its pursuit has had a major influence on
the whole GType/GObject library. C programmers are likely to be puzzled at the complexity
of the features exposed in the following chapters if they forget that the GType/GObject library
was not only designed to offer OO-like features to C programmers but also transparent
cross-language interoperability.
</para>
</sect1>
</chapter>

View file

@ -0,0 +1,125 @@
<?xml version='1.0' encoding="UTF-8"?>
<!DOCTYPE part PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
]>
<part label="V">
<title>Related Tools</title>
<partintro>
<para>
Several useful developer tools have been build around GObject
technology. The next sections briefly introduce them and link to
the respective project pages.
</para>
<para>
For example, writing GObjects is often seen as a tedious task. It
requires a lot of typing and just doing a copy/paste requires a
great deal of care. A lot of projects and scripts have been
written to generate GObject skeleton form boilerplate code, or
even translating higher-level language into plain C.
</para>
</partintro>
<chapter id="tools-vala">
<title>Vala</title>
<para>
From the <ulink url="https://wiki.gnome.org/Projects/Vala">Vala
homepage</ulink> itself: <quote>Vala is a new programming language
that aims to bring modern programming language features to GNOME
developers without imposing any additional runtime requirements
and without using a different ABI compared to applications and
libraries written in C.</quote>
</para>
<para>
The syntax of Vala is similar to C#. The available compiler
translates Vala into GObject C code. It can also compile
non-GObject C, using plain C API.
</para>
</chapter>
<chapter id="tools-gob">
<title>GObject builder</title>
<para>
In order to help a GObject class developer, one obvious idea is
to use some sort of templates for the skeletons and then run
them through a special tool to generate the real C files. <ulink
url="http://www.5z.com/jirka/gob.html">GOB</ulink> (or GOB2) is
such a tool. It is a preprocessor which can be used to build
GObjects with inline C code so that there is no need to edit the
generated C code. The syntax is inspired by Java and Yacc or
Lex. The implementation is intentionally kept simple: the inline C
code provided by the user is not parsed.
</para>
</chapter>
<chapter id="tools-ginspector">
<title>Graphical inspection of GObjects</title>
<para>
Yet another tool that you may find helpful when working with
GObjects is <ulink
url="http://sourceforge.net/projects/g-inspector">G-Inspector</ulink>. It
is able to display GLib/GTK+ objects and their properties.
</para>
</chapter>
<chapter id="tools-refdb">
<title>Debugging reference count problems</title>
<para>
The reference counting scheme used by GObject does solve quite
a few memory management problems but also introduces new sources of bugs.
In large applications, finding the exact spot where the reference count
of an Object is not properly handled can be very difficult.
</para>
<para>
A useful tool in debugging reference counting problems is to
set breakpoints in gdb on g_object_ref() and g_object_unref().
Once you know the address of the object you are interested in,
you can make the breakpoints conditional:
<programlisting>
break g_object_ref if _object == 0xcafebabe
break g_object_unref if _object == 0xcafebabe
</programlisting>
</para>
</chapter>
<chapter id="tools-gtkdoc">
<title>Writing API docs</title>
<para>The API documentation for most of the GLib, GObject, GTK+ and GNOME
libraries is built with a combination of complex tools. Typically, the part of
the documentation which describes the behavior of each function is extracted
from the specially-formatted source code comments by a tool named gtk-doc which
generates DocBook XML and merges this DocBook XML with a set of template XML
DocBook files. These XML DocBook files are finally processed with xsltproc
(a small program part of the libxslt library) to generate the final HTML
output. Other tools can be used to generate PDF output from the source XML.
The following code excerpt shows what these comments look like.
<informalexample><programlisting>
/**
* gtk_widget_freeze_child_notify:
* @widget: a #GtkWidget
*
* Stops emission of "child-notify" signals on @widget. The signals are
* queued until gtk_widget_thaw_child_notify() is called on @widget.
*
* This is the analogue of g_object_freeze_notify() for child properties.
**/
void
gtk_widget_freeze_child_notify (GtkWidget *widget)
{
...
</programlisting></informalexample>
</para>
<para>
Thorough
<ulink url="https://developer.gnome.org/gtk-doc-manual/stable/">documentation</ulink>
on how to set up and use gtk-doc in your project is provided on the
<ulink url="https://developer.gnome.org/">GNOME developer website</ulink>.
</para>
</chapter>
</part>

View file

@ -0,0 +1 @@
@GLIB_VERSION@

View file

@ -0,0 +1,8 @@
<!ENTITY package "@PACKAGE@">
<!ENTITY package_bugreport "@PACKAGE_BUGREPORT@">
<!ENTITY package_name "@PACKAGE_NAME@">
<!ENTITY package_string "@PACKAGE_STRING@">
<!ENTITY package_tarname "@PACKAGE_TARNAME@">
<!ENTITY package_url "@PACKAGE_URL@">
<!ENTITY package_version "@PACKAGE_VERSION@">
<!ENTITY package_api_version "@PACKAGE_API_VERSION@">

View file

@ -0,0 +1,14 @@
ent_conf = configuration_data()
ent_conf.set('PACKAGE', 'glib')
ent_conf.set('PACKAGE_BUGREPORT', 'https://gitlab.gnome.org/GNOME/glib/issues/new')
ent_conf.set('PACKAGE_NAME', 'glib')
ent_conf.set('PACKAGE_STRING', 'glib')
ent_conf.set('PACKAGE_TARNAME', 'glib')
ent_conf.set('PACKAGE_URL', 'FIXME')
ent_conf.set('PACKAGE_VERSION', glib_version)
ent_conf.set('PACKAGE_API_VERSION', glib_api_version)
configure_file(
input: 'gtkdocentities.ent.in',
output: 'gtkdocentities.ent',
configuration: ent_conf
)

View file

@ -0,0 +1,62 @@
# The list of minor versions in the 2.x.x series which have had
# GLIB_AVAILABLE_IN_* macros. This should include the current unreleased stable
# version.
#
# FIXME: It would be good to be able to generate this list:
# https://github.com/mesonbuild/meson/issues/5026
stable_2_series_versions = [
'26', '28', '30', '32', '34', '36', '38',
'40', '42', '44', '46', '48', '50', '52', '54', '56', '58',
'60', '62', '64', '66', '68', '70', '72',
]
ignore_decorators = [
'GLIB_VAR',
'G_GNUC_INTERNAL',
'G_GNUC_WARN_UNUSED_RESULT',
'GLIB_AVAILABLE_IN_ALL',
]
foreach version : stable_2_series_versions
ignore_decorators += [
# Note that gtkdoc is going to use those in regex, and the longest match
# must come first. That's why '_FOR()' variant comes first.
# gtkdoc special-case '()' and replace it by a regex matching a symbol name.
'GLIB_AVAILABLE_IN_2_' + version,
'GLIB_DEPRECATED_IN_2_' + version + '_FOR()',
'GLIB_DEPRECATED_IN_2_' + version,
'GLIB_AVAILABLE_STATIC_INLINE_IN_2_' + version,
'GLIB_AVAILABLE_ENUMERATOR_IN_2_' + version,
'GLIB_DEPRECATED_ENUMERATOR_IN_2_' + version + '_FOR()',
'GLIB_DEPRECATED_ENUMERATOR_IN_2_' + version,
'GLIB_AVAILABLE_MACRO_IN_2_' + version,
'GLIB_DEPRECATED_MACRO_IN_2_' + version + '_FOR()',
'GLIB_DEPRECATED_MACRO_IN_2_' + version,
'GLIB_AVAILABLE_TYPE_IN_2_' + version,
'GLIB_DEPRECATED_TYPE_IN_2_' + version + '_FOR()',
'GLIB_DEPRECATED_TYPE_IN_2_' + version,
]
endforeach
gtkdoc_common_scan_args = [
'--ignore-decorators=' + '|'.join(ignore_decorators),
]
if get_option('gtk_doc')
if not meson.version().version_compare('>=0.52.0')
error('Building documentation requires Meson >= 0.52.0.')
endif
# Check we have the minimum gtk-doc version required. Older versions won't
# generate correct documentation.
dependency('gtk-doc', version : '>=1.32.1',
fallback : ['gtk-doc', 'dummy_dep'],
default_options : ['tests=false'])
endif
subdir('gio')
subdir('glib')
subdir('gobject')