>&kde; définit une hiérarchie de systèmes de fichiers que l'environnement &kde; lui-même ainsi que toutes les applications &kde; utilisent. En général, &kde; stocke tous ses fichiers dans une arborescence de dossiers avec une structure fixe. </para>
<para
>Par défaut, &kde; utilise deux arborescences:</para>
<itemizedlist>
<listitem
><para
>une au niveau du système (par exemple <filename class="directory"
>/opt/kde3</filename
>),</para
></listitem>
<listitem
><para
>une au niveau utilisateur dans le dossier personnel de l'utilisateur (généralement <filename class="directory"
>En tant qu'administrateur système, vous pouvez créer des branches additionnelles. Les arborescences additionnelles peuvent être utilisées en tant que <link linkend="user-profiles"
>. (ceci est propre à &SuSE;, il se peut que d'autres distributions emploient <filename class="directory"
>/usr</filename
> ou <filename class="directory"
>/usr/kde3</filename
>)</para
></listitem>
<listitem
><para
><filename class="directory"
>/etc/opt/kde3</filename
>. (ceci a été ajouté par &SuSE;).</para
></listitem>
</itemizedlist>
<para
>Si vous avez installé la version 0.7 ou supérieure de l'outil d'administration KIOSK, vous pouvez vérifier quelles sont les arborescences de dossiers utilisées avec la commande suivante: <userinput
>&kde; et les applications &kde; applications examinent les fichiers en analysant toutes les arborescences de dossiers &kde;. Ces dernières sont vérifiées par ordre de priorité. Quand un fichier est présent dans plusieurs arborescences de dossiers, le fichier provenant de la dernière arborescence prend la priorité. Normalement, l'arborescence située dans le dossier personnel de l'utilisateur a la priorité la plus élevée. C'est également l'arborescence de dossiers dans laquelle les changements sont enregistrés.</para>
<informalexample>
<para
>Pour obtenir des informations sur le type &MIME; <literal
>text/plain</literal
>, une recherche est effectuée sur les fichiers suivants:</para>
>Pour les fichiers de configuration, les choses sont un peu différentes. Si des fichiers de configuration multiples du même nom sont trouvés dans les arborescences de dossiers, leur contenu est combiné. L'ordre de priorité des arborescences de dossiers joue un rôle ici. Quand deux fichiers définissent la même clé de configuration, le fichier ayant la priorité la plus élevée est utilisé pour la clé.</para>
<informalexample
><para
>Par exemple, si les deux fichiers suivants existent, avec ces contenus:</para>
>Il est à présent possible d'affecter un profil en fonction soit du nom de l'utilisateur, soit du groupe &UNIX; dont l'utilisateur fait partie.</para
>
<para
>Pour affecter le profil «staff» à tous les utilisateurs qui sont membres du groupe staff_members &UNIX;, ajouter ce qui suit à <filename
>/etc/kde-user-profile</filename
>:</para>
<programlisting
>[General]
groups=staff_members
[Groups]
staff_members=staff
</programlisting>
<para
>Il est également possible d'affecter un profil à un seul utilisateur:</para>
<programlisting
>[Users]
bastian=staff
</programlisting>
</sect1>
<sect1 id="directory-layout-revisited">
<title
>Disposition des dossiers revisitée</title>
<para
>Chaque arborescence de dossiers qu'emploie &kde; a une structure de dossier fixe. Il est néanmoins possible de laisser de côté les dossiers sans rapport avec un dossier donné ou qui ne sont simplement pas utilisés. Par exemple, les dossiers auxquels les fichiers temporaires font appel se trouvent habituellement sous <filename class="directory"
>, mais non dans n'importe quelle autre arborescence de dossiers.</para>
</sect1>
<sect1 id="architecture-specific-directories">
<title
>Dossiers propres à une architecture</title>
<para
>Dossiers propres à une architecture (type de système d'exploitation et de processeur):</para>
<variablelist>
<varlistentry>
<term
><filename class="directory"
>bin</filename
></term>
<listitem
><para
>Utilisé pour les exécutables &kde;.</para
></listitem>
</varlistentry>
<varlistentry>
<term
><filename class="directory"
>lib</filename
></term>
<listitem
><para
>Utilisé pour les bibliothèques &kde;.</para>
</listitem>
</varlistentry>
<varlistentry>
<term
><filename class="directory"
>lib/kde3</filename
></term>
<listitem
><para
>Ce dossier contient des composants, modules externes et autres objets qu'il est possible de charger au moment de l'exécution, à l'usage des applications &kde;3.<replaceable
>x</replaceable
>.</para
></listitem
>
</varlistentry>
</variablelist>
</sect1>
<sect1 id="shared-directories">
<title
>Dossiers partagés</title>
<para
>Partagé: non propre à une architecture, peut être partagé entre différentes architectures.</para>
<variablelist>
<varlistentry>
<term
><filename class="directory"
>share/applnk</filename
></term>
<listitem
><para
>fichiers <literal role="extension"
>.desktop</literal
> pour le menu &kde; (ancien)</para
></listitem>
</varlistentry>
<varlistentry>
<term
><filename class="directory"
>share/applications</filename
></term>
<listitem
><para
>fichiers <literal role="extension"
>.desktop</literal
> pour le menu &kde; (depuis &kde;3.2)</para>
</listitem>
</varlistentry>
<varlistentry>
<term
><filename class="directory"
>share/apps</filename
></term>
<listitem
><para
>Contient des fichiers de données propres à une application. Chaque application a ici un sous-dossier pour stocker des fichiers de données additionnels.</para
></listitem>
</varlistentry>
<varlistentry>
<term
><filename class="directory"
>share/config</filename
></term>
<listitem
><para
>Fichiers de configuration. Les fichiers de configuration sont normalement nommés après l'application à laquelle ils appartiennent, plus les lettres <quote
>rc</quote
>. Un cas spécial est <filename
>kdeglobals</filename
>. Ce fichier est lu par toutes les applications &kde;.</para
></listitem>
</varlistentry>
<varlistentry>
<term
><filename
class="directory"
>share/config/session</filename
></term>
<listitem
><para
>Ce dossier est utilisé par la gestion de session et n'est normalement disponible que sous <filename class="directory"
>. À la fin d'une session, les applications &kde; y enregistrent leur état. Les noms des fichiers se composent du nom de l'application suivi d'un nombre. Le gestionnaire de session <command
>ksmserver</command
> stocke les références à ces nombres lors de l'enregistrement d'une session dans <filename
>ksmserverrc</filename
>.</para
></listitem>
</varlistentry>
<varlistentry>
<term
><filename class="directory"
>share/doc/HTML</filename
></term>
<listitem
><para
>Ce dossier contient de la documentation pour les applications &kde;. La documentation est classifiée par langue et selon l'application à laquelle elle appartient. Normalement, on trouve au moins deux fichiers dans un dossier: <filename
>index.docbook</filename
>, qui contient la documentation au format DocBook non formaté et <filename
>index.cache.bz2</filename
>, qui contient la même documentation au format &HTML; compactée sous <command
>bzip2</command
>. La version &HTML; est celle qu'utilise le ¢reAide;. Si elle est absente, le ¢reAide; la régénère à partir de la version DocBook, mais c'est un processus qui prend du temps.</para>
</listitem>
</varlistentry>
<varlistentry>
<term
><filename class="directory"
>share/icons</filename
></term>
<listitem
><para
>Sous ce dossier, sont stockées les icônes. Les icônes sont classées par catégories de thème, dimension et utilisation.</para
></listitem>
</varlistentry>
<varlistentry>
<term
><filename class="directory"
>share/mimelnk</filename
></term>
<listitem
><para
>Dans ce dossier, sont stockés les fichiers <literal role="extension"
>.desktop</literal
> qui décrivent les types &MIME;. &kde; fait appel aux types &MIME; pour identifier le type d'un fichier.</para>
</listitem>
</varlistentry>
<varlistentry>
<term
><filename class="directory"
>share/services</filename
></term>
<listitem
><para
>Ce dossier contient les fichiers <literal role="extension"
>.desktop</literal
>, qui décrivent des services. Les services sont comme les applications, mais ce sont habituellement d'autres applications au lieu de l'utilisateur qui les lancent. Ils n'apparaissent pas dans le menu &kde;</para>
</listitem>
</varlistentry>
<varlistentry>
<term
><filename class="directory"
>share/servicetypes</filename
></term>
<listitem
><para
>Ce dossier contient les fichiers <literal role="extension"
>.desktop</literal
> qui décrivent les servicetypes. Un servicetype représente d'ordinaire une certaine interface de programmation. Les applications et les services regroupent dans leurs fichiers <literal role="extension"
>
>.desktop</literal
> les servicetypes qu'ils fournissent.</para
> </listitem
></varlistentry>
<varlistentry>
<term
><filename class="directory"
>share/sounds</filename
></term>
<listitem
><para
>Ce dossier contient les fichiers son.</para
></listitem>
</varlistentry>
<varlistentry>
<term
><filename class="directory"
>share/templates</filename
></term>
<listitem
><para
>Ce dossier contient les modèles permettant de créer des fichiers de divers types. Un modèle se compose d'un fichier <literal role="extension"
>.desktop</literal
>, qui décrit le fichier et renferme une référence à un fichier dans le sous-dossier <filename class="directory"
>.source</filename
>. Les modèles de ce dossier apparaissent dans le menu <guimenu
>Créer un nouveau</guimenu
> disponible sur le bureau et dans l'explorateur de fichiers. Quand un utilisateur sélectionne un modèle dans le menu, son fichier source est copié.</para>
</listitem>
</varlistentry>
<varlistentry>
<term
><filename class="directory"
>share/wallpapers</filename
></term>
<listitem
><para
>Ce dossier contient des images que l'on peut employer comme fond d'écran.</para
></listitem>
</varlistentry>
</variablelist>
</sect1>
<sect1 id="host-specific-directories">
<title
>Dossiers propres à un hôte</title
>
<para
>Il y a trois dossiers propres à un hôte, qui sont l'objet d'un lien symbolique vers d'autres emplacements. Si les dossiers n'existent pas déjà, les liens symboliques et les dossiers suivants seront créés à l'aide de l'utilitaire <command
>: est utilisé pour les fichiers mis en cache.</para>
</listitem>
</varlistentry>
</variablelist>
<para
>Du fait que les deux fichiers <filename class="directory"
>/tmp</filename
> et <filename class="directory"
>/var/tmp</filename
> sont universellement inscriptibles, il est possible que les dossiers ci-dessus existent déjà, mais qu'ils soient la propriété d'un autre utilisateur. Dans ce cas, l'utilitaire <command
>lnusertemp</command
> crée un nouveau dossier avec un autre nom et un lien vers celui-ci à la place.</para>
</sect1>
<sect1 id="configuration-files">
<title
>Fichiers de configuration</title
> <para
>&kde; utilise un format de fichiers de type texte simple pour tous ses fichiers de configuration. Il se compose de paires clé-valeur qui sont placées dans des groupes. Tous les fichiers de configuration &kde; font appel à l'encodage <acronym
>UTF</acronym
>-8 pour le texte en dehors de la plage <acronym
>ASCII</acronym
>.</para>
<para
>Le début d'un groupe est indiqué par un nom de groupe qui est placé entre crochets. Tous les éléments clé-valeur qui suivent appartiennent au groupe. Le groupe se termine soit quand un autre groupe commence, soit quand la fin du fichier est atteinte. Les éléments situés au début du fichier qui ne sont pas précédés d'un nom de groupe appartiennent au groupe par défaut.</para>
<informalexample
><para
>L'exemple suivant montre un fichier de configuration qui se compose de deux groupes. Le premier groupe contient les clés <varname
>LargeCursor</varname
> et <varname
>SingleClick</varname
>, tandis que le second groupe contient les clés <varname
>Show hidden files</varname
> et <varname
>Sort by</varname
>:</para>
<programlisting
>[KDE]
LargeCursor=false
SingleClick=true
</programlisting>
<programlisting
>[KFileDialog Settings]
Show hidden files=false
Sort by=Name
</programlisting>
</informalexample>
<para
>Les éléments d'un groupe se composent d'une clé et d'une valeur séparées par un signe égal. La clé peut contenir des espaces et être suivie d'options placées entre crochets. La partie après le signe égal est la valeur de l'élément. Tout blanc entourant le signe égal est ignoré, comme s'il s'agissait d'un espace de fin quelconque. En bref, le format est:</para>
<programlisting
><replaceable
>élément</replaceable
>=<replaceable
>valeur</replaceable
>
</programlisting>
<para
>Si une valeur est censée inclure un espace au début ou à la fin, il est possible de l'obtenir à l'aide d'une barre oblique inverse suivie d'un <quote
>s</quote
>.</para>
<para
>Il y a plusieurs autres codes de barres obliques inverses. En voici une liste complète: <itemizedlist>
<listitem
><para
><token
>\s</token
> peut servir d'espace,</para>
</listitem>
<listitem
><para
><token
>\t</token
> peut servir à insérer une tabulation,</para>
</listitem>
<listitem
><para
><token
>\r</token
> pour un caractère retour chariot,</para>
</listitem>
<listitem
><para
><token
>\n</token
> pour un caractère saut de ligne (retour à la ligne),</para>
</listitem>
<listitem
><para
><token
>\\</token
> pour insérer la barre oblique inverse proprement dite.</para>
</listitem>
</itemizedlist
></para>
<informalexample
><para
>Dans l'exemple suivant, la valeur de l'élément <varname
>Caption</varname
> commence par deux espaces, tandis que l'élément <varname
>Description</varname
> contient trois lignes de texte. Les sauts de ligne en notation barre oblique inverse sont utilisés pour séparer les différentes lignes.</para>
<programlisting
>[Preview Image]
Caption=\s Ma légende
Description=Ceci est\nune très longue\ndescription.
</programlisting>
</informalexample>
<para
>Les lignes vides dans les fichiers de configuration sont ignorées, puisque ce sont des lignes qui commencent par un caractère dièse (« # »). Le caractère dièse peut être utilisé pour ajouter des commentaires aux fichiers de configuration. On notera que quand une application &kde; met à jour un fichier de configuration, les commentaires <emphasis
>ne</emphasis
> sont <emphasis
>pas</emphasis
> préservés.</para>
<para
>Il peut y avoir de multiples fichiers de configuration du même nom dans le sous-dossier <filename class="directory"
>share/config</filename
> des diverses arborescences de dossiers &kde;. Dans ce cas, les informations de tous ces fichiers de configuration sont combinées selon un principe clé par clé. Si la même clé au sein d'un groupe donné est définie dans plusieurs endroits, la valeur clé lue depuis l'arborescence des dossiers ayant la priorité la plus élevée sera utilisée. Les fichiers de configuration sous <filename class="directory"
> ont toujours la priorité la plus élevée. Si une clé dans un groupe donné est définie plusieurs fois dans un seul fichier, la valeur du dernier élément est utilisée.</para>
>Pour empêcher les utilisateurs de pouvoir annuler les réglages par défaut, il est possible de marquer ces réglages comme immuables. On peut rendre les réglages immuables individuellement, par groupe ou par fichier. Un élément individuel peut être verrouillé en ajoutant <userinput
>[$i]</userinput
> à côté de la clé, &pex;: <programlisting
>Color[$i]=blue
</programlisting>
</para>
<para
>On peut verrouiller un groupe d'éléments en plaçant <userinput
>[$i]</userinput
> à côté du nom du groupe, &pex;: <programlisting
>[MyGroup][$i]
</programlisting>
</para>
<para
>Pour verrouiller le fichier entier, commencez-le par <userinput
>On peut faire intervenir ce qu'on appelle l'«expansion du shell» pour fournir plus de valeurs par défaut dynamiques. Avec l'expansion du shell, la valeur d'une clé de configuration peut être construite à partir de la valeur d'une variable d'environnement ou de la sortie d'une commande shell. Pour activer l'expansion du shell pour un élément de configuration, la clé doit être suivie de <token
>[$e]</token
>. Normalement, la forme étendue est écrite dans le fichier de configuration de l'utilisateur après la première utilisation. Pour empêcher cela, il est recommandé de verrouiller l'élément de configuration à l'aide de <token
>[$ie]</token
>. L'utilisateur ne peut évidemment pas le changer ensuite.</para>
<informalexample>
<para
>Dans l'exemple suivant, la valeur de l'élément <varname
>Host</varname
> est déterminée par la sortie du programme <command
>hostname</command
> Ce paramètre est également verrouillé pour garantir que la valeur est toujours déterminée dynamiquement.</para>
<para
>La valeur concernant l'élément <varname
>Email</varname
> est déterminée en remplissant les valeurs des variables d'environnement $<envar
>USER</envar
> et $<envar
>HOST</envar
>. Quand <systemitem class="username"
>joseph</systemitem
> est connecté sur <systemitem class="systemname"
>joseph_host</systemitem
>, on obtient une valeur égale à <literal
>joseph@joseph_host</literal
>. Le paramètre n'est pas verrouillé.</para>
<programlisting
>[Mail Settings]
Host[$ie]=$(hostname)
Email[$e]=${USER}@${HOST}
</programlisting>
</informalexample>
<para
>La plupart des éléments de configuration peuvent être indexés avec un code de langue. Dans ce cas, la langue que l'utilisateur a choisie sur le bureau sert à rechercher la valeur de la clé. Si l'on a choisi la langue par défaut (anglais américain) ou s'il n'a pas d'index qui correspond à la langue choisie, l'élément clé sans index est utilisé.</para>
<informalexample>
<para
>Dans l'exemple suivant, la valeur de l'élément <varname
>Caption</varname
> dépend de la langue. Si l'utilisateur a choisi le français (code de langue <literal
>fr</literal
>), la valeur de l'élément sera «Ma légende». Dans tous les autres cas, la valeur «My Caption» sera utilisée.</para>
<programlisting
>[Preview Image]
Caption=My Caption
Caption[fr]=Ma légende
</programlisting>
</informalexample>
<informalexample>
<para
>Dans cet exemple, la valeur de l'élément <varname
>Caption</varname
> dépend de la langue. Si l'utilisateur a choisi le français (code de langue <literal
>fr</literal
>), la valeur de l'élément sera «Ma légende». Dans tous les autres cas, la valeur «My Caption» sera utilisée.</para>
<programlisting
>[Preview Image]
Caption=My Caption
Caption[fr]=Ma légende
</programlisting>
</informalexample>
<para
>En général, les éléments susceptibles d'apparaître dans un fichier de configuration ne sont pas documentés. &kde;3.2 a permis de commencer à changer cet état de choses. Dans <filename class="directory"
>, se trouvent des fichiers qui fournissent une description formelle des éléments possibles dans un fichier de configuration. Le nouvel éditeur de configuration &kde; s'en sert quand ils sont disponibles.</para>
<informalexample>
<para
>Voici un exemple de fichier de configuration &XML;: <programlisting
><markup>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE kcfg SYSTEM "http://www.kde.org/standards/kcfg/1.0/kcfg.dtd">
<kcfg>
<kcfgfile name="korganizerrc"/>
<group name="General">
<entry type="Bool" key="Auto Save">
<label>Enable automatic saving of calendar</label>
>. Dans la plupart des cas, il est appelé depuis le gestionnaire d'affichage (&tdm;) une fois que l'utilisateur a été authentifié. On trouve deux lignes très importantes dans le script <filename
> de démarrer le processus du gestionnaire de session <command
>ksmserver</command
>. Le gestionnaire de session détermine la durée de vie de la session. Quand ce processus se termine, l'utilisateur est déconnecté.</para>
</sect2>
</sect1>
<sect1 id="background-processes">
<title
>Processus d'arrière-plan</title>
<para
>Tous les services d'arrière-plan de &kde; sont propres à l'utilisateur: contrairement aux démons système, ils ne sont pas partagés entre les utilisateurs. Ils sont non seulement particuliers à chaque utilisateur, mais également à chaque affichage du serveur X. Les processus sont:</para>
> est un démon qui fournit des fonctions de communication inter-processus (&DCOP;) à toutes les applications &kde;. Les fonctions &DCOP; sont accessibles depuis l'interpréteur de commandes via l'outil en ligne de commande <command
>dcop</command
>. &DCOP; est essentiel pour la totalité des applications &kde;.</para>
<para
>Certains fichiers connexes:</para>
<variablelist>
<varlistentry>
<term
><filename
>$<envar
>HOME</envar
>/.DCOPserver_$<envar
>HOSTNAME</envar
>_$<envar
>DISPLAY</envar
></filename
></term>
<listitem
><para
>&pex; <filename
>.DCOPserver_linux__0</filename
>. Contrôlé par $<envar
>DCOPAUTHORITY</envar
></para>
</listitem>
</varlistentry>
<varlistentry>
<term
><filename
>/tmp/.ICE-unix/dcop<replaceable
>pid</replaceable
>-<replaceable
>nombre</replaceable
></filename
></term>
<listitem
><para
>&pex; <filename
>dcop7634-1069677856</filename
>. C'est le fichier sur lequel le fichier <filename
>DCOPserver</filename
> ci-dessus pointe.</para>
</listitem>
</varlistentry>
<varlistentry>
<term
><filename
>$<envar
>HOME</envar
>/.ICEauthority</filename
></term>
<listitem
><para
>Informations d'autorisation contrôlées par $<envar
>ICEAUTHORITY</envar
></para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
<sect2 id="kcminit">
<title
>kcminit</title>
<para
><command
>kcminit</command
> exécute les services d'initialisation pendant le démarrage. Les services d'initialisation sont spécifiés dans les fichiers <filename
>.desktop</filename
> des applications ou des services via la ligne <varname
> sont définies correctement en faisant cela!</para>
</sect2>
<sect2 id="knotify">
<title
><command
>knotify</command
></title>
<para
>La tâche principale de <command
>knotify</command
> est de transmettre les notifications sonores au serveur de son. Elle fournit également des méthodes de notification de remplacement.</para>
</sect2>
</sect1>
<sect1 id="ksmserver">
<title
>KSMServer</title>
<para
><command
>ksmserver</command
> est le gestionnaire de session de &kde;. Au démarrage, le gestionnaire de session lance les applications démarrant automatiquement et restaure les applications de la session précédente. Les applications à démarrer automatiquement sont indiquées par les fichiers <literal role="extension"
>. Quelle soit à démarrer automatiquement ou non, il est possible de rendre conditionnelle une application en fonction de certains éléments de configuration déterminés par l'élément <varname
> ouvre automatiquement tout fichier stocké dans ce dossier, y compris les documents, fichiers exécutables ou applications sous forme de fichiers <literal role="extension"
>.desktop</literal
>.</para>
<para
>Le gestionnaire de session &kde; restaure également une des sessions précédentes. Une session contient une collection d'applications, ainsi que des informations propres à une application qui reflètent l'état des applications au moment où la session a été enregistrée. Les sessions sont stockées dans le fichier de configuration <filename
>ksmserverrc</filename
>, qui contient des références aux informations d'état propres à une application. Les informations d'état propres à une application sont enregistrées dans <filename class="directory"
> n'est pas définie et doit pointer sur la racine de l'arborescence d'installation de &kde;. Permet à &kde; de chercher ses données comme les icônes, les menus et les bibliothèques.</para>
> et vous permet de spécifier de multiples dossiers où &kde; recherche ses données. Utile si vous voulez ou devez installer certains programmes avec un préfixe autre que le reste de &kde;.</para
> comme dossier pour les données personnelles de <systemitem class="username"
>root</systemitem
>. A été introduite pour empêcher &kde; d'écraser accidentellement les données utilisateur ayant des droits d'accès root quand l'utilisateur exécute un programme &kde; après être passé avec <command
>(Depuis &kde;3.2) - Définissez cette variable pour indiquer que vous avez prélié vos exécutables et vos bibliothèques &kde;. Cela désactivera <command
> au démarrage de &kde;, elle est utilisée par &konqueror;, &pex;, pour savoir s'il doit envisager de rester en mémoire pour une réutilisation future au moment de sa fermeture. Si elle n'est pas définie, &konqueror; sort après avoir été fermé (&pex; &tdesu; le fait, c'est également utile pour le débogage).</para>
>Permet de spécifier un autre chemin d'accès que <filename class="directory"
>/var/tmp</filename
> où &kde; stocke ses fichiers de variables.</para>
</listitem>
</varlistentry>
<varlistentry
><term
>$<envar
>XDG_DATA_HOME</envar
></term
><listitem
><para
>(Depuis &kde;3.2) Définit le dossier de base précisant où les fichiers de données propres à l'utilisateur devraient être stockés. Par défaut, il s'agit de <filename class="directory"
>$<envar
>HOME</envar
>/.local/share</filename
>.</para>
</listitem>
</varlistentry>
<varlistentry
><term
>$<envar
>XDG_DATA_DIRS</envar
></term
><listitem
><para
>(Depuis &kde;3.2) Définit l'ensemble des dossiers de base définis par ordre de préférence pour rechercher les fichiers de données en plus du dossier de base <filename class="directory"
>$<envar
>XDG_DATA_HOME</envar
></filename
>. Par défaut, il s'agit de <literal
>/usr/local/share/:/usr/share/</literal
>.</para>
<para
>&kde; ajoute des emplacements à partir de $<envar
> ainsi que des profils. Utilisée pour les fichiers de menu <literal role="extension"
>.desktop</literal
> et <literal role="extension"
>.directory</literal
>. Les fichiers <literal role="extension"
>.desktop</literal
> sous <filename class="directory"
>$<envar
>XDG_DATA_DIRS</envar
>/applications</filename
>. Les fichiers <literal role="extension"
>.directory</literal
> sous $XDG_DATA_DIRS/desktop-directories. </para>
</listitem>
</varlistentry>
<varlistentry
><term
>$<envar
>XDG_CONFIG_HOME</envar
></term
><listitem
><para
>(&kde;3.2) - Définit le dossier de base précisant où les fichiers de configuration propres à l'utilisateur devraient être stockés. Par défaut, il s'agit de <filename class="directory"
>$<envar
>HOME</envar
>/.config</filename
>.</para>
</listitem>
</varlistentry>
<varlistentry
><term
>$<envar
>XDG_CONFIG_DIRS</envar
></term
><listitem
><para
>(&kde;3.2) - Définit l'ensemble des dossiers de base définis par ordre de préférence pour rechercher les fichiers de données en plus du dossier de base $<envar
>XDG_CONFIG_HOME</envar
>. Le dossier par défaut est <filename class="directory"
>/etc/xdg</filename
>. &kde; ajoute des emplacements à partir de $<envar
>Liens vers des applications en utilisant le fichier <literal role="extension"
>.desktop</literal
>: <menuchoice
><guimenu
>Créer un nouveau</guimenu
><guimenuitem
>Lien vers une application...</guimenuitem
></menuchoice
>. Vous devez fournir les détails vous-même. Faites glisser depuis le menu &kde;: copiez ou liez (cette action crée un lien symbolique), beaucoup plus facile.</para>
<!-- Perhaps legacy and translated should be the other way around, but -->
<!-- this is how it appears in Waldo's presentation. Need to check -->
<!-- this -->
<programlisting
>[Desktop Entry]<co id="boilerplate"/>
Encoding=UTF-8
GenericName=IRC Client<co id="generic-desc"/>
GenericName[af]=Irc Kliët
GenericName[de]=IRC Programm
...
GenericName[zu]=Umthengi we IRC<co id="legacy"/>
SwallowExec=<co id="translated"/>
Name=KSirc
Name[af]=Ksirc
Name[de]=KSirc
...
</programlisting>
<calloutlist>
<callout arearefs="boilerplate"
><para
>Texte stéréotypé</para>
</callout>
<callout arearefs="generic-desc"
><para
>Description traduite de manière générique, non utilisée sur le bureau</para>
</callout>
<callout arearefs="legacy"
><para
>Hérité, ne peut pas être supprimé</para>
</callout>
<callout arearefs="translated"
><para
>Nom traduit, tel qu'il apparaît sur le bureau</para>
>Affiche un curseur animé, désactivé s'il ne fonctionne pas.</para>
</callout>
<callout arearefs="co-x-dcop-servicetype"
><para
>L'application a-t-elle démarré correctement? Supprimé s'il ne fonctionne pas</para>
</callout>
<callout arearefs="co-categories"
><para
>Catégories pour le menu &kde;, non utilisé sur le bureau</para>
</callout>
</calloutlist>
</sect2>
<sect2 id="desktop-icons-exec">
<title
>L'option <varname
>Exec</varname
> dans les fichiers <literal role="extension"
>.desktop</literal
></title>
<para
>Après la commande, vous pouvez avoir plusieurs paramètres fictifs qui seront remplacés par les valeurs réelles lorsque le programme réel s'exécute: <variablelist>
<varlistentry>
<term
>%f</term
> <listitem
><para
>Un seul nom de fichier: utilisée lorsqu'on fait glisser un fichier sur une icône ou avec des associations de fichiers.</para>
</listitem>
</varlistentry>
<varlistentry>
<term
>%F</term>
<listitem
><para
>Une liste de fichiers: utilisée pour les applications qui peuvent ouvrir plusieurs fichiers locaux en même temps.</para>
</listitem>
</varlistentry>
<varlistentry>
<term
>%u</term>
<listitem
><para
>Une seule &URL;: si l'application peut gérer &pex; des &URL; &FTP; ou &HTTP; elle-même, sinon &kde;.</para>
</listitem>
</varlistentry>
<varlistentry>
<term
>%U</term>
<listitem
><para
>Une liste d'&URL;: téléchargera le fichier d'abord puis transmettra un fichier local à l'application!</para>
</listitem>
</varlistentry>
<varlistentry>
<term
>%d</term>
<listitem
><para
>Le dossier du fichier à ouvrir: utile si l'application doit avoir un fichier dans le dossier de travail en cours.</para>
</listitem>
</varlistentry>
<varlistentry>
<term
>%D</term>
<listitem
><para
>Une liste de dossiers: pas très pratique.</para>
</listitem>
</varlistentry>
<varlistentry>
<term
>%i</term
>
<listitem
><para
>L'icône avec l'option <option
>--icon</option
>: l'application &kde; utilisera l'icône provenant de la ligne <varname
>Icon</varname
>= dans la barre des tâches.</para>
</listitem>
</varlistentry>
<varlistentry>
<term
>%m</term>
<listitem
><para
>La mini-icône: héritée.</para>
</listitem>
</varlistentry>
<varlistentry>
<term
>%c</term
>
<listitem
><para
>La légende avec l'option <option
>--caption</option
>: l'application &kde; utilisera le nom provenant de la ligne <varname
>Name</varname
>= dans la barre d'outilsr.</para>
</listitem>
</varlistentry>
</variablelist>
</para>
<informalexample>
<para
>Exemples: <segmentedlist>
<segtitle
>Ligne <varname
>exec</varname
></segtitle>
<segtitle
>Commande exécutée</segtitle>
<seglistitem
><seg
>ksirc %i</seg
><seg
><command
>ksirc --icon ksirc</command
></seg>
</seglistitem>
<seglistitem
><seg
>cd %d; kedit $(basename %f)</seg
><seg
><command
>cd /tmp; kedit file.txt</command
></seg>
</seglistitem>
</segmentedlist>
</para>
</informalexample>
<!--Dont' know what this refers to: -->
<!--See What's This (Shift-F1) in Properties Dialog-->
</sect2>
<sect2 id="desktop-icons-devices">
<title
>Périphériques</title>
<para
>Liens vers les périphériques en utilisant le fichier <literal role="extension"
>.desktop</literal
>: Créer un nouveau périphérique </para>
</sect2>
<sect2 id="where-to-define">
<title
>Où définir quoi?</title>
<para
>De nombreux endroits pour définir les icônes du bureau: <itemizedlist>
> définit le nom et l'icône de ce menu: <programlisting
>[Desktop Entry]
Name=Art and Culture
Icon=kcmsystem
</programlisting>
</para>
</informalexample>
</sect2>
<sect2 id="common-pitfalls">
<title
>Pièges courants</title>
<para
>Les applications qui ne sont <emphasis
>pas</emphasis
> dans le menu n'existent <emphasis
>pas</emphasis
> par rapport aux autres applications ou associations de fichiers: si vous supprimez une application du menu, &kde; part du principe que vous ne voulez pas l'utiliser.</para>
<para
>Quand des applications sont indésirables dans le menu, placez-les soit dans le menu <filename
> met en cache la structure des menus et les informations sur toutes les applications disponibles. Vous pouvez reconstruire la base de données avec <userinput
>&kmenuedit; est destiné à la configuration pour un seul utilisateur. Les changements apportés à la structure des menus sont enregistrés dans <filename
>, ceux des applications le sont dans <filename class="directory"
>~/.local/share/applications/</filename
> et ceux qui concernent les sous-menus (icône, nom) dans <filename class="directory"
>~/.local/share/desktop-directories/</filename
>. L'outil d'administration KIOSK utilise &kmenuedit; et copie les changements ci-dessus dans des emplacements à l'échelle d'un profil ou du système. </para>
</sect2>
</sect1>
<!-- This section might be redundant. If it isn't, it needs some screenies -->
<sect1 id="kde-panel">
<title
>Tableau de bord de &kde;</title>
<para
>Le tableau de bord de &kde; est également connu comme &kicker;. Il est modulaire et repose sur les composants suivants: <itemizedlist>
<listitem
><para
>Applets,</para
></listitem>
<listitem
><para
>Boutons d'applications,</para
></listitem>
<listitem
><para
>Boutons spéciaux.</para
></listitem>
</itemizedlist>
</para>
<para
>Par défaut, le tableau de bord contient les applets suivantes: <itemizedlist
> <listitem
><para
>Pager - affiche les bureaux virtuels,</para
></listitem
> <listitem
><para
>Barre des tâches,</para
></listitem
> <listitem
><para
>Boîte à miniatures,</para
></listitem
> <listitem
><para
>Horloge.</para
></listitem
> </itemizedlist
> et les boutons spéciaux suivants: <itemizedlist>
<listitem
><para
>Menu &kde;,</para
></listitem>
<listitem
><para
>Bouton Bureau.</para
></listitem>
</itemizedlist>
</para>
<para
>Divers boutons d'applications sont également ajoutés: <itemizedlist>
<listitem
><para
>Bouton Dossier personnel,</para
></listitem>
<listitem
><para
>Bouton Navigateur,</para
></listitem>
<listitem
><para
>Bouton KMail.</para
></listitem>
</itemizedlist>
</para>
</sect1>
<sect1 id="file-associations">
<title
>Associations de fichiers</title>
<para
>Les associations de fichiers associent un type de fichier avec une application ou des applications. Le type d'un fichier est établi en déterminant son type &MIME;. Les types &MIME; connus de &kde; sont stockés dans <filename class="directory"
>. Pour utiliser les mêmes réglages pour des utilisateurs multiples, stockez ces réglages dans le dossier des profils des utilisateurs ou le dossier de configuration globale de &kde; auquel faire appel en tant que dossier par défaut pour des utilisateurs multiples.</para>
</informalexample>
</sect1>
</chapter>
<chapter id="locking-down-kde">
<title
>Verrouiller &kde;</title>
<sect1 id="how-it-works-the-basics">
<title
>Les bases de fonctionnement</title>
<para
>Les fonctionnalités de verrouillage de &kde; sont centrées autour des options suivantes:</para>
<itemizedlist>
<listitem
><para
><link linkend="immutable-configuration-options"
>rendre les options de configuration immuables,</link
></para
></listitem>
<listitem
><para
><link linkend="action-restrictions"
>restreindre des actions spécifiques,</link
></para
></listitem>
<listitem
><para
><link linkend="url-restrictions"
>restreindre l'accès à certaines &URL;,</link
></para
></listitem>
<listitem
><para
><link linkend="configuration-modules"
>restreindre l'accès à certains modules de configuration.</link
></para
></listitem>
</itemizedlist>
</sect1>
<sect1 id="immutable-configuration-options">
<title
>Options de configuration immuables</title>
<subtitle
>Verrouiller &kde;</subtitle>
<para
>Les options immuables permettent à l'administrateur système de fournir des paramètres par défaut qui ne peuvent pas être changés par l'utilisateur.</para>
<para
>Les options de configuration préexistantes de l'utilisateur sont ignorées dès lors qu'une option de configuration est rendue immuable.</para>
<para
>Les options peuvent être contrôlées par élément, par groupe d'éléments ou par fichier.</para>
<para
>Si un fichier ou un groupe est immuable, toutes les options de configuration pour ce fichier ou ce groupe sont immuables, même les options pour lesquelles l'administrateur système n'a pas de valeurs par défaut prévues.</para>
<note
><para
>La prise en charge des options immuables dans les applications peut varier d'une application à l'autre. Bien que l'utilisateur ne soit pas en mesure de rendre permanents les changements des options de configuration immuables, l'utilisateur peut encore obtenir une option d'interface utilisateur pour apporter ce type de changement.</para
></note>
</sect1>
<sect1 id="action-restrictions">
<title
>Restrictions des actions</title>
<para
>Les applications &kde; sont construites autour de la notion d'action. Les actions peuvent être activées de différentes façons, généralement via la barre de menus, une des barres d'outils ou un raccourci clavier. <action
>Enregistrer le document</action
> est un exemple d'action. Si vous connaissez le nom interne d'une action, il est possible de restreindre cette action. Quand une action est restreinte, elle n'apparaît plus dans la barre de menus ou la barre d'outils. Le nom interne de l'action <action
>Enregistrer le document</action
> est <option
>action/file_save</option
>. La fenêtre de verrouillage fournit aussi un ensemble de restrictions plus abstraites qui peuvent servir à désactiver la fonctionnalité non assurée par une seule action. Un exemple est la restriction <option
>shell_access</option
> qui désactive toute la fonctionnalité qui offrirait l'accès utilisateur à un interpréteur &UNIX;.</para>
<example>
<title
>Restreindre l'accès utilisateur aux interpréteurs</title>
<para
>Pour empêcher l'accès utilisateur à un interpréteur de commandes, nous pouvons restreindre l'action <option
>shell_access</option
> en ajoutant ce qui suit à <filename
>kdeglobals</filename
>: </para
>
<screen
>[KDE Action Restrictions]
shell_access=false</screen>
<para
>Puisque ceci affecte le menu &kde; et les applications disponibles, nous devons forcer une mise à jour de la base de données sycoca:</para>
>Décide si l'utilisation des économiseurs d'écran OpenGL est autorisée</para
></listitem>
</varlistentry>
<varlistentry>
<term
><option
>manipulatescreen_screensavers</option
></term>
<listitem
><para
>Autorise les économiseurs d'écran qui ne masquent pas l'écran entier</para
></listitem>
</varlistentry>
</variablelist>
</sect1>
<sect1 id="url-restrictions">
<title
>Restrictions sur les &URL;</title>
<para
>Il y a trois types de restrictions susceptibles de s'appliquer aux &URL;:</para>
<variablelist>
<varlistentry>
<term
>list</term>
<listitem
><para
>Pour contrôler si un listage de dossiers est autorisé.</para
></listitem>
</varlistentry>
<varlistentry>
<term
>open</term>
<listitem
><para
>Pour contrôler si certaines &URL; peuvent être ouvertes</para
></listitem>
</varlistentry>
<varlistentry>
<term
>Redirect</term>
<listitem
><para
>Pour contrôler si une &URL; peut ouvrir une autre &URL;, automatiquement ou via un lien hypertexte.</para
></listitem>
</varlistentry>
</variablelist>
<para
>Les règles sont vérifiées dans l'ordre dans lequel elles sont définies. La dernière règle qui est applicable à une &URL; définit s'il est possible d'accéder à l'&URL;.</para>
<para
>Les règles suivantes désactivent l'ouverture des &URL; http et https en dehors de <systemitem class="domainname"
>Les quatre premières virgules sautent les critères de sélection par rapport à l'&URL; d'origine. Cette partie n'est nécessaire qu'avec les règles de type redirection.</para
>
</callout>
<callout arearefs="url_rule1"
><para
><option
>rule_1</option
> interdit l'ouverture de toute &URL; http ou https.</para
></callout>
<callout arearefs="url_rule2"
><para
><option
>rule_2</option
> autorise l'ouverture de n'importe quelle &URL; http et https dans le domaine <systemitem class="domainname"
>.notreentreprise.com</systemitem
>. Notez que le joker <token
>*</token
> n'est autorisé qu'au début d'un domaine.</para
></callout>
</calloutlist>
<para
>Les règles suivantes font que l'utilisateur ne peut plus naviguer dans les dossiers sur le système de fichiers local qui sont en dehors de son dossier $<envar
>HOME</envar
>:</para>
<screenco
><areaspec>
<area id="home_rule1" coords="3"/>
<area id="home_rule2" coords="4"/>
</areaspec>
<screen
>[KDE URL Restrictions]
rule_count=2
rule_1=list,,,,file,,,false
rule_2=list,,,,file,,$HOME,true</screen
></screenco>
<calloutlist>
<callout arearefs="home_rule1"
><para
><option
>rule_1</option
> interdit le listage de tout dossier local.</para
></callout>
<callout arearefs="home_rule2"
><para
><option
>rule_2</option
> autorise le listage des dossiers sous le dossier $<envar
>HOME</envar
> propre des utilisateurs.</para
></callout>
</calloutlist>
<para
>$<envar
>HOME</envar
> et $<envar
>TMP</envar
> sont des valeurs spéciales pour indiquer le dossiers personnel des utilisateurs et le dossier temporaire &kde; de l'utilisateur, &pex; <filename class="directory"
>Les règles suivantes font que l'utilisateur ne peut plus ouvrir les fichiers locaux qui sont en dehors de son dossier $<envar
>HOME</envar
>:</para>
<screenco
><areaspec>
<area id="local_rule1" coords="3"/>
<area id="local_rule2" coords="4"/>
<area id="local_rule3" coords="5"/>
</areaspec>
<screen
>[KDE URL Restrictions]
rule_count=3
rule_1=open,,,,file,,,false
rule_2=open,,,,file,,$HOME,true
rule_3=open,,,,file,,$TMP,true</screen
></screenco>
<calloutlist>
<callout arearefs="local_rule1"
><para
><option
>rule_1</option
> interdit l'ouverture de tout fichier local.</para
></callout>
<callout arearefs="local_rule2"
><para
><option
>rule_2</option
> autorise l'ouverture des fichiers sous le dossier $<envar
>HOME</envar
> propre des utilisateurs.</para
></callout>
<callout arearefs="local_rule3"
><para
><option
>rule_3</option
> autorise l'ouverture des fichiers dans le dossier temporaire &kde; de l'utilisateur. Celle-ci est exigée par certaines applications &kde; qui téléchargent d'abord un fichier ou un document dans le dossier temporaire puis l'ouvrent dans une application.</para
></callout>
</calloutlist>
<para
>L'option de redirection contrôle si les documents d'un emplacement donné peuvent renvoyer, automatiquement ou manuellement via un lien hypertexte, à un autre emplacement donné. Un ensemble de règles par défaut est présent à titre de mesure de sécurité générale. Par exemple, des documents qui se trouvent sur l'Internet peuvent ne pas renvoyer à des documents stockés en local.</para>
<para
>Par exemple, si nous voulons donner au serveur intranet <systemitem class="systemname"
>www.monentreprise.com</systemitem
> la possibilité de renvoyer à des fichiers locaux, nous pourrions ajouter la règle suivante:</para>
>Au lieu de lister un protocole par nom, il est également possible de spécifier un groupe entier de protocoles. Pour ce faire, les groupes suivants ont été définis:</para>
<variablelist>
<varlistentry>
<term
>:local</term>
<listitem
><para
>Les protocoles qui accèdent aux informations stockées en local: des exemples sont file:/, man:/, fonts:/, floppy:/</para
></listitem>
</varlistentry>
<varlistentry>
<term
>:internet</term>
<listitem
><para
>Protocoles internet courants tels que http et ftp</para
></listitem>
</varlistentry>
</variablelist>
<para
>Les informations sur les protocoles sont stockées dans les fichiers <literal role="extension"
>*.protocol</literal
>, qui se trouvent dans <filename class="directory"
>Les protocoles :local peuvent renvoyer n'importe quel autre protocole</para
></listitem>
<listitem
><para
>Il est toujours autorisé de renvoyer à un protocole :internet</para
></listitem>
<listitem
><para
>Tous les protocoles ne font pas partie d'un groupe, fish:/ par exemple</para
></listitem>
</itemizedlist>
</sect1>
<sect1 id="configuration-modules">
<title
>Modules de configuration</title>
<para
>&kde; comporte des modules de configuration permettant de configurer divers aspects de l'environnement &kde;. Les modules de configuration apparaissent dans le Centre de configuration, dans la boîte de dialogue Configuration d'une application ou les deux.</para>
<informalexample>
<para
>Le module de configuration Serveur mandataire apparaît dans le Centre de configuration mais fait également partie de la boîte de dialogue <guilabel
>Configuration de Konqueror</guilabel
> dans &konqueror;.</para>
<para
>Les modules de configuration individuels peuvent être démarrés via <command
>Toutes les applications n'utilisent pas les modules de configuration. Souvent la boîte de dialogue fait partie intégrante de l'application elle-même.</para
></note
></para>
</informalexample>
<para
>Tous les modules de configuration font partie à proprement parler du menu &kde;.</para>
<itemizedlist>
<listitem>
<para
>Les modules que l'on peut voir dans le Centre de configuration comportent normalement un fichier <literal role="extension"
>Le partage de bureau distant permet à des utilisateurs distants de voir et éventuellement de contrôler le bureau de l'utilisateur courant. L'utilisateur distant doit avoir reçu une invitation et il est possible de créer un mot de passe pour protéger une invitation en attente. Cela convient parfaitement pour des équipes de support technique ou des administrateurs pour obtenir l'accès aux bureaux des utilisateurs afin de les dépanner ou les guider dans une procédure.</para>
<para
>Le partage de bureau distant repose sur deux applications: &krfb; (&kde; remote frame buffer, un serveur VNC) et &krdc; (&kde; remote desktop connection, un client VNC).</para>
<para
>&krfb; peut être utilisé par tout utilisateur pour créer et gérer des invitations. Les invitations créent un mot de passe à usage unique qui permet au destinataire de se connecter à votre bureau. Par défaut elle est valable pour une seule connexion réussie et expire au bout d'une heure de non utilisation.</para>
<para
>Les connexions entrantes sont gérées par le module kinetd kded. Vous pouvez utiliser la commande <userinput
><command
>dcop</command
> kded kinetd services</userinput
> pour vérifier que &krfb; est en cours d'exécution et attend par défaut les connexions sur le port 5900. Quand une connexion entrante est établie, une boîte de dialogue apparaît pour demander confirmation à l'utilisateur courant.</para>
<!-- TODO: Write a bit more here, with a walk through maybe? -->
</sect1>
<sect1 id="kde-diy">
<title
>&kde; DIY - Construisez vos propres outils</title>
<sect2 id="dcop">
<title
>DCOP</title>
<para
>Desktop COmmunication Protocol, <acronym
>DCOP</acronym
> (protocole de communication du bureau) est un mécanisme léger permettant la communication inter-processus. <acronym
>DCOP</acronym
> permet à l'utilisateur d'interagir avec les applications qui s'exécutent actuellement. &kde; fournit deux programmes pour tirer parti de <acronym
>DCOP</acronym
>: <application
>dcop</application
>, un programme en ligne de commande et <application
>kdcop</application
>, un programme d'interface graphique (<acronym
>GUI</acronym
>). </para>
<para
>Voici quelques remarques sur l'utilisation de <command
>&kde; DIY - Construisez vos propres outils</subtitle>
<para
>Vous pouvez utiliser les boîtes de dialogue &kde; depuis vos propres scripts pour combiner la puissance du scriptage shell d'&UNIX; à la facilité d'utilisation de &kde;.</para>
<screen
><userinput
><command
>kdialog</command
> <option
>--msgbox 'Vous avez de nouveaux messages!'</option
></userinput
></screen>
<screen
><userinput
><command
>kdialog</command
> <option
>--title 'Nouveaux messages'</option
> <option
>--msgbox 'Vous avez de nouveaux messages!'</option
></userinput
></screen>
<para
>Le composant <application
>KDialog</application
> peut être remplacé par l'option <option
>--caption</option
></para>
<screen
><userinput
><command
>kdialog</command
> <option
>--title 'Nouveaux messages'</option
> <option
>--msgbox 'Vous avez de nouveaux messages!'</option
> <option
>--dontagain myfile:mykey</option
></userinput
></screen>
<para
>Enregistre ce qu'il faut ou non afficher à nouveau dans <filename
> (en insérant dans ce fichier les lignes suivantes:</para>
<screen
>[Notification Messages]
mykey=false</screen>
<para
>À la place de <option
>--msgbox</option
>, vous pouvez également faire appel à <option
>--sorry</option
> et <option
>--error</option
>, comme approprié. Par exemple, vous pourriez utiliser <command
>kdialog</command
> <option
>--sorry 'Le réseau est inaccessible'</option
> ou <command
>kdialog</command
> <option
>--error 'Impossible d'ouvrir la boîte aux lettres'</option
>.</para>
<para
>Il est également possible de créer des boîtes de messages qui acceptent une réponse oui ou non.</para>
<screen
><command
>kdialog</command
> <option
>--yesno 'Voulez-vous vous connecter
à l'Internet?'</option
> <command
>echo</command
> <returnvalue
>$?</returnvalue
></screen>
<informaltable>
<tgroup cols="2">
<thead>
<row>
<entry
>Valeur de retour</entry>
<entry
>Signification</entry>
</row>
</thead>
<tbody>
<row
><entry
>0</entry
><entry
>Oui, OK, Continuer</entry
></row>
<row
><entry
>1</entry
><entry
>Non</entry
></row>
<row
><entry
>2</entry
><entry
>Annuler</entry
></row>
</tbody>
</tgroup>
</informaltable>
<para
>Veillez à enregistrer le résultat dans une variable si vous ne l'utilisez pas directement, la prochaine commande complète $? avec une nouvelle valeur. Vous pouvez faire appel à <option
>--dontagain</option
> ici également, car elle retient le choix de l'utilisateur et le retourne les fois suivantes sans jamais plus afficher la boîte de dialogue.</para>
