&kde; pour les administrateurs

Waldo Bastian bastian@kde.org &Philip.Rodrigues; &Philip.Rodrigues.mail; &kde; pour les administrateurs Au cœur de &kde; Vue d'ensemble À écrire Disposition des dossiers &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. Par défaut, &kde; utilise deux arborescences : une au niveau du système (par exemple /opt/kde3), une au niveau utilisateur dans le dossier personnel de l'utilisateur (généralement ~/.trinity). En tant qu'administrateur système, vous pouvez créer des branches additionnelles. Les arborescences additionnelles peuvent être utilisées en tant que profils &SuSE; &Linux;, par exemple, utilise : $HOME/.trinity /opt/kde3. (ceci est propre à &SuSE;, il se peut que d'autres distributions emploient /usr ou /usr/kde3) /etc/opt/kde3. (ceci a été ajouté par &SuSE;). 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 : kiosktool-tdedirs &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. Pour obtenir des informations sur le type &MIME; text/plain, une recherche est effectuée sur les fichiers suivants : $HOME/.trinity/share/mimelnk/text/plain.desktop /opt/kde3/share/mimelnk/text/plain.desktop /etc/opt/kde3/share/mimelnk/text/plain.desktop Si un utilisateur apporte un changement, celui-ci est écrit dans $HOME/.trinity/share/mimelnk/text/plain.desktop 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é. Par exemple, si les deux fichiers suivants existent, avec ces contenus : $HOME/.trinity/share/config/foobar Color=red Shape=circle /etc/opt/kde3/share/config/foobar Position=10,10 Les fichiers seront fusionnés pour produire : Color=red Shape=circle Position=10,10 Spécifier des dossiers Variable d'environnement Exemples de réglage(s) Commentaire TDEHOME ~/.trinity TDEROOTHOME /root/.trinity Variable différente pour empêcher root d'écrire dans la variable $TDEHOME de l'utilisateur après avoir exécuté su. TDEDIR /opt/kde3, /usr, /usr/kde3 Dépend du distributeur. Utilisée par &kde; 2. Si elle n'est pas définie, revient à une valeur compilée en dur par défaut. TDEDIRS /opt/kde3, /usr, /usr/kde3 Nouvelle dans &kde;3. Peut répertorier des emplacements multiples séparés par un caractère « : ». Si elle n'est pas définie, revient à $TDEDIR N'a pas besoin d'être définie, les valeurs par défaut fonctionnent de manière satisfaisante. Vous exécutez &kde;2 en parallèle avec &kde;3 ? Faites pointer $TDEDIR sur &kde; 2 et $TDEDIRS sur &kde; 3. Un membre du personnel d'une université pourrait avoir les réglages suivants : TDEHOME='~/.trinity3' TDEROOTHOME='/root/.trinity3' TDEDIRS='/opt/kde_staff:/opt/kde3' Profils utilisateur Dans l'exemple précédent, /opt/kde_staff contenait des réglages et des applications additionnels pour des membres du personnel. Les profils utilisateur vous permettent de n'ajouter ce dossier que pour certains utilisateurs et non pour d'autres. Ajoutez ce qui suit à /etc/tderc : [Directories-staff] prefixes=/opt/kde_staff Ceci crée un profil nommé « staff », qui ajoute l'arborescence de dossier /opt/kde_staff. (Notez que &SuSE; &Linux; utilise /etc/kde3rc au lieu de /etc/tderc). Maintenant que nous avons un profil nommé, il est possible de l'affecter à des utilisateurs. Pour faire correspondre des profils à des utilisateurs, il faut spécifier un fichier de correspondance dans /etc/tderc : [Directories] userProfileMapFile=/etc/kde-user-profile 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. Pour affecter le profil « staff » à tous les utilisateurs qui sont membres du groupe staff_members &UNIX;, ajouter ce qui suit à /etc/kde-user-profile : [General] groups=staff_members [Groups] staff_members=staff Il est également possible d'affecter un profil à un seul utilisateur : [Users] bastian=staff Disposition des dossiers revisitée 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 $TDEHOME, mais non dans n'importe quelle autre arborescence de dossiers. Dossiers propres à une architecture Dossiers propres à une architecture (type de système d'exploitation et de processeur) : bin Utilisé pour les exécutables &kde;. lib Utilisé pour les bibliothèques &kde;. lib/kde3 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.x. Dossiers partagés Partagé : non propre à une architecture, peut être partagé entre différentes architectures. share/applnk fichiers .desktop pour le menu &kde; (ancien) share/applications fichiers .desktop pour le menu &kde; (depuis &kde; 3.2) share/apps Contient des fichiers de données propres à une application. Chaque application a ici un sous-dossier pour stocker des fichiers de données additionnels. share/config Fichiers de configuration. Les fichiers de configuration sont normalement nommés après l'application à laquelle ils appartiennent, plus les lettres rc. Un cas spécial est kdeglobals. Ce fichier est lu par toutes les applications &kde;. share/config/session Ce dossier est utilisé par la gestion de session et n'est normalement disponible que sous $TDEHOME. À 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 ksmserver stocke les références à ces nombres lors de l'enregistrement d'une session dans ksmserverrc. share/doc/HTML 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 : index.docbook, qui contient la documentation au format DocBook non formaté et index.cache.bz2, qui contient la même documentation au format &HTML; compactée sous bzip2. 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. share/icons Sous ce dossier, sont stockées les icônes. Les icônes sont classées par catégories de thème, dimension et utilisation. share/mimelnk Dans ce dossier, sont stockés les fichiers .desktop qui décrivent les types &MIME;. &kde; fait appel aux types &MIME; pour identifier le type d'un fichier. share/services Ce dossier contient les fichiers .desktop, 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; share/servicetypes Ce dossier contient les fichiers .desktop 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 >.desktop les servicetypes qu'ils fournissent. share/sounds Ce dossier contient les fichiers son. share/templates Ce dossier contient les modèles permettant de créer des fichiers de divers types. Un modèle se compose d'un fichier .desktop, qui décrit le fichier et renferme une référence à un fichier dans le sous-dossier .source. Les modèles de ce dossier apparaissent dans le menu Créer un nouveau 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é. share/wallpapers Ce dossier contient des images que l'on peut employer comme fond d'écran. Dossiers propres à un hôte 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 lnusertemp : $TDEHOME/socket-$HOSTNAME Habituellement, /tmp/tdesocket-$USER/ est utilisé pour divers sockets &UNIX;. $TDEHOME/tmp-$HOSTNAME Habituellement, /tmp/tde-$USER/ est utilisé pour les fichiers temporaires. $TDEHOME/cache-$HOSTNAME Habituellement, /var/tmp/tdecache-$USER/ : est utilisé pour les fichiers mis en cache. Du fait que les deux fichiers /tmp et /var/tmp 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 lnusertemp crée un nouveau dossier avec un autre nom et un lien vers celui-ci à la place. Fichiers de configuration &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 UTF-8 pour le texte en dehors de la plage ASCII. 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. L'exemple suivant montre un fichier de configuration qui se compose de deux groupes. Le premier groupe contient les clés LargeCursor et SingleClick, tandis que le second groupe contient les clés Show hidden files et Sort by : [KDE] LargeCursor=false SingleClick=true [KFileDialog Settings] Show hidden files=false Sort by=Name 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 : élément=valeur 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 s. Il y a plusieurs autres codes de barres obliques inverses. En voici une liste complète : \s peut servir d'espace, \t peut servir à insérer une tabulation, \r pour un caractère retour chariot, \n pour un caractère saut de ligne (retour à la ligne), \\ pour insérer la barre oblique inverse proprement dite. Dans l'exemple suivant, la valeur de l'élément Caption commence par deux espaces, tandis que l'élément Description contient trois lignes de texte. Les sauts de ligne en notation barre oblique inverse sont utilisés pour séparer les différentes lignes. [Preview Image] Caption=\s Ma légende Description=Ceci est\nune très longue\ndescription. 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 ne sont pas préservés. Il peut y avoir de multiples fichiers de configuration du même nom dans le sous-dossier share/config 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 $TDEHOME 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. Si $HOME/.trinity/share/config/foobar contient : [MyGroup] Color=red Shape=circle et si /etc/opt/kde3/share/config/foobar contient [MyGroup] Color=blue Position=10,10 , le résultat sera : [MyGroup] Color=red Shape=circle Position=10,10 Si $HOME/.trinity/share/config/foobar contient [MyGroup] Color=red Shape=circle [MyGroup] Color=green et si /opt/kde_staff/share/config/foobar contient [MyGroup] Color=purple Position=20,20 et si /etc/opt/kde3/share/config/foobar contient [MyGroup] Color=blue Position=10,10 , le résultat sera : [MyGroup] Color=green Shape=circle Position=20,20 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 [$i] à côté de la clé, &pex; : Color[$i]=blue On peut verrouiller un groupe d'éléments en plaçant [$i] à côté du nom du groupe, &pex; : [MyGroup][$i] Pour verrouiller le fichier entier, commencez-le par [$i] sur une seule ligne, &cad; : [$i] Si $HOME/.trinity/share/config/foobar contient : [MyGroup] Color=red Shape=circle et si /etc/opt/kde3/share/config/foobar contient : [MyGroup][$i] Color=blue Position=10,10 , le résultat sera : [MyGroup] Color=blue Position=10,10 Si $HOME/.trinity/share/config/foobar contient : [MyGroup] Color=red Shape=circle et si /opt/kde_staff/share/config/foobar contient [MyGroup] Color=purple Shape=rectangle et si /etc/opt/kde3/share/config/foobar contient [MyGroup][$i] Color=blue Position=10,10 le résultat sera [MyGroup] Color=purple Shape=rectangle Position=10,10 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 [$e]. 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 [$ie]. L'utilisateur ne peut évidemment pas le changer ensuite. Dans l'exemple suivant, la valeur de l'élément Host est déterminée par la sortie du programme hostname Ce paramètre est également verrouillé pour garantir que la valeur est toujours déterminée dynamiquement. La valeur concernant l'élément Email est déterminée en remplissant les valeurs des variables d'environnement $USER et $HOST. Quand joseph est connecté sur joseph_host, on obtient une valeur égale à joseph@joseph_host. Le paramètre n'est pas verrouillé. [Mail Settings] Host[$ie]=$(hostname) Email[$e]=${USER}@${HOST} 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é. Dans l'exemple suivant, la valeur de l'élément Caption dépend de la langue. Si l'utilisateur a choisi le français (code de langue fr), la valeur de l'élément sera « Ma légende ». Dans tous les autres cas, la valeur « My Caption » sera utilisée. [Preview Image] Caption=My Caption Caption[fr]=Ma légende Dans cet exemple, la valeur de l'élément Caption dépend de la langue. Si l'utilisateur a choisi le français (code de langue fr), la valeur de l'élément sera « Ma légende ». Dans tous les autres cas, la valeur « My Caption » sera utilisée. [Preview Image] Caption=My Caption Caption[fr]=Ma légende 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 $TDEDIR/share/config.kcfg, 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. Voici un exemple de fichier de configuration &XML; : <?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> <default>true</default> </entry> <entry type="Int" key="Auto Save Interval"> <default>10</default> </entry> </group> </kcfg> Il a le même effet que : [General] Auto Save=false Auto Save Interval=25 Séquence de démarrage de &kde; &tdm; Il s'exécute toujours en tant que root et utilise $TDEDIR/share/config/tdmrc et /etc/X11/xdm/Xservers. Ce dernier contient des éléments comme : :0 local /usr/X11R6/bin/X :0 vt07 D'autres fichiers sont utiles au démarrage : La section [X-*-Core] dans tdmrc Configuration - /etc/X11/xdm/Xsetup L'utilisateur entre le nom d'utilisateur et le mot de passe Démarrage - /etc/X11/xdm/Xstartup - en tant que superutilisateur Session - /etc/X11/xdm/Xsession - démarre la session en tant qu'utilisateur = Pour une session KDE : kde ou starttde = Si présent ~/.xsession ou ~/.xinitrc Reset - /etc/X11/xdm/Xreset - après que la session soit terminée Le script de démarrage &kde; : <command >starttde</command > La séquence de démarrage de &kde; commence par le script starttde. 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 starttde : LD_BIND_NOW=true tdeinit +kcminit +knotify and kwrapper ksmserver $TDEWM La première ligne commence par le processus maître tdeinit. Le processus maître tdeinit est utilisé pour démarrer tous les autres processus &kde;. Il apparaît dans la sortie de ps en tant que tdeinit: Running.... Les arguments placés après tdeinit sont les noms des processus additionnels à démarrer. Le + indique que tdeinit doit attendre que le processus ait terminé. tdeinit démarre aussi dcopserver, klauncher et kded. La seconde ligne demande à tdeinit de démarrer le processus du gestionnaire de session ksmserver. Le gestionnaire de session détermine la durée de vie de la session. Quand ce processus se termine, l'utilisateur est déconnecté. Processus d'arrière-plan 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 : dcopserver Communication avec le bureau kded Démon générique des services. Active les mises à jour de la base de données Sycoca lorsque c'est nécéssaire kcminit Service d'initialisation Voir pour plus d'informations. klauncher Lancement du programme (ce n'est pas la boîte de dialogue &Alt;F2 !) Voir pour plus d'informations. knotify Notifications à l'utilisateur. Voir pour plus d'informations. ksmserver Gestion de la session voir pour plus d'informations. <command >tdeinit</command > tdeinit sert à démarrer tous les autres programmes &kde;. tdeinit peut démarrer les fichiers des programmes exécutables normaux ainsi que les modules chargeables tdeinit (KLM). Les KLM fonctionnent exactement comme les fichiers exécutables des programmes, mais peuvent être démarrés plus efficacement. Les KLM résident dans $TDEDIR/lib/kde3. L'inconvénient est que les programmes démarrés de cette manière apparaissent en tant que tdeinit dans la sortie de top et ps. Utilisez top ou ps pour voir le nom véritable du programme : %ps waba 23184 0.2 2.1 23428 11124 ? S 21:41 0:00 tdeinit: Running... waba 23187 0.1 2.1 23200 11124 ? S 21:41 0:00 tdeinit: dcopserver --nosid waba 23189 0.2 2.4 25136 12496 ? S 21:41 0:00 tdeinit: klauncher waba 23192 0.7 2.8 25596 14772 ? S 21:41 0:00 tdeinit: kded waba 23203 0.8 3.4 31516 17892 ? S 21:41 0:00 tdeinit: knotify tdeinit: Running... indique le processus maître tdeinit. Les autres processus répertoriés sont les programmes démarrés en tant que KLM. Lorsque tdeinit démarre pour la première fois, il lance dcopserver, klauncher et kded, ainsi que des programmes additionnels spécifiés sur sa ligne de commande dans le script starttde, normalement kcminit et knotify. <command >dcopserver</command > dcopserver 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 dcop. &DCOP; est essentiel pour la totalité des applications &kde;. Certains fichiers connexes : $HOME/.DCOPserver_$HOSTNAME_$DISPLAY &pex; .DCOPserver_linux__0. Contrôlé par $DCOPAUTHORITY /tmp/.ICE-unix/dcoppid-nombre &pex; dcop7634-1069677856. C'est le fichier sur lequel le fichier DCOPserver ci-dessus pointe. $HOME/.ICEauthority Informations d'autorisation contrôlées par $ICEAUTHORITY kcminit kcminit exécute les services d'initialisation pendant le démarrage. Les services d'initialisation sont spécifiés dans les fichiers .desktop des applications ou des services via la ligne X-TDE-Init : [Desktop Entry] Encoding=UTF-8 Exec=kcmshell energy Icon=energy_star Type=Application X-TDE-Library=energy X-TDE-Init=energy Les services d'intialisation servent généralement à initialiser le matériel en fonction de paramètres spécifiés par l'utilisateur. kcminit peut être utilisé pour montrer tous les services d'initialisation et kcminit service pour exécuter un seul service de façon explicite. Ce comportement peut être utile lorsqu'on fait une analyse des problèmes de démarrage. <command >klauncher</command > klauncher est un démon respondable de l'activation des services au sein de &kde;. Il opère en liaison étroite avec le processus maître tdeinit pour démarrer de nouveaux processus. Les applications &kde; communiquent avec klauncher au travers de &DCOP; afin de démarrer de nouveaux services ou applications. Le plus connu des messages d'erreur : KLauncher could not be reached via DCOP qui indique soit un problème grave avec le dcopserver, soit que klauncher a « planté ». klauncher peut être redémarré en redémarrant tdeinit depuis d'une fenêtre de console. Assurez-vous que $HOME, $DISPLAY et les diverses $TDEDIR sont définies correctement en faisant cela ! <command >knotify</command > La tâche principale de knotify est de transmettre les notifications sonores au serveur de son. Elle fournit également des méthodes de notification de remplacement. KSMServer ksmserver 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 .desktop dans le dossier $TDEDIR/share/autostart. 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 X-TDE-autostart-condition dans le fichier .desktop. Le fichier ktip.desktop, &pex;, contient : X-TDE-autostart-condition=ktiprc:TipOfDay:RunOnStart:true Cela signifie qu'une vérification est effectuée sur le fichier de configuration ktiprc pour rechercher un élément RunOnStart dans la section [TipOfDay]. Si elle ne trouve aucun élément de ce genre, true est supposé, ce qui signifie que ktip est une des applications démarrées automatiquement par défaut. Certaines des applications démarrées automatiquement par ksmserver sont : kdesktop Le bureau &kde; &kicker; Le tableau de bord de &kde; ktip Un programme d'astuces du jour kwrited Un utilitaire permettant de recevoir les messages du système envoyés à l'utilisateur &klipper; Un utilitaire presse-papiers qui s'intègre au tableau de bord kalarm Un utilitaire qui avertit des événements et des rendez-vous prochains kdesktop démarre à son tour les applications stockées dans $TDEHOME/Autostart. kdesktop ouvre automatiquement tout fichier stocké dans ce dossier, y compris les documents, fichiers exécutables ou applications sous forme de fichiers .desktop. 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 ksmserverrc, qui contient des références aux informations d'état propres à une application. Les informations d'état propres à une application sont enregistrées dans $TDEHOME/share/config/session. Les informations d'état de &twin; contiennent l'emplacement des fenêtres d'application de toutes les autres applications de la session. Variables d'environnement Quelques variables d'environnement importantes que &kde; utilise : $TDEDIR Doit être positionnée si TDEDIRS 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. $TDEDIRS Annule TDEDIR 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;. $TDEHOMESi elle n'est pas définie, &kde; utilise ~/.trinity comme dossier où sont stockées les données personnelles. $TDEROOTHOMESi elle n'est pas définie, &kde; utilise ~root/.trinity comme dossier pour les données personnelles de root. 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 su à root. $TDEWMSi la variable d'environnement TDEWM a été définie, alors elle sera utilisée comme gestionnaire de fenêtres de &kde; dans le script starttde à la place de &twin;. $TDE_LANGAnnule la configuration de la langue de &kde;, &pex; TDE_LANG=fr kprogram & démarre un programme comportant une traduction en français si les fichiers nécessaires sont installés. $TDE_MULTIHEADDéfinissez cette variable à true pour indiquer que &kde; tourne sur un système « multifonctions » (multi-head). $TDE_FORK_SLAVES (Depuis &kde; 3.2.3) Définissez cette variable pour donner naissance à des processus esclaves KIO directement depuis le processus de l'application lui-même. Par défaut, les esclaves KIO sont générés à l'aide de klauncher/tdeinit. Cette option est utile si l'esclave KIO doit s'exécuter dans le même environnement que l'application. Ce peut être le cas avec Clearcase. $TDE_HOME_READONLY Définissez cette variable pour indiquer que votre dossier personnel est monté en lecture seule. $TDE_NO_IPV6(Depuis &kde; 3.2.3) - Définissez cette variable pour désactiver la prise en charge d'IPv6 et les recherches DNS IPv6. $TDE_IS_PRELINKED(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 tdeinit. $TDE_UTF8_FILENAMESSi cette variable d'environnement est définie, &kde; part du principe que tous les noms de fichiers sont encodés en UTF-8, quelle que soit la locale C actuelle. $TDE_FULL_SESSION(Depuis &kde; 3.2) Définie automatiquement à true 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). $TDESYCOCAVous permet de spécifier le chemin d'accès et le nom du fichier de cache de configuration système &kde; généré. $TDETMPPermet de spécifier un autre chemin d'accès que /tmp où &kde; stocke ses fichiers temporaires. $TDEVARTMPPermet de spécifier un autre chemin d'accès que /var/tmp où &kde; stocke ses fichiers de variables. $XDG_DATA_HOME(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 $HOME/.local/share. $XDG_DATA_DIRS(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 $XDG_DATA_HOME. Par défaut, il s'agit de /usr/local/share/:/usr/share/. &kde; ajoute des emplacements à partir de $TDEDIRS ainsi que des profils. Utilisée pour les fichiers de menu .desktop et .directory. Les fichiers .desktop sous $XDG_DATA_DIRS/applications. Les fichiers .directory sous $XDG_DATA_DIRS/desktop-directories. $XDG_CONFIG_HOME(&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 $HOME/.config. $XDG_CONFIG_DIRS(&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 $XDG_CONFIG_HOME. Le dossier par défaut est /etc/xdg. &kde; ajoute des emplacements à partir de $TDEDIRS et des profils également. Utilisée par les descriptions .menu dans $XDG_CONFIG_DIRS/menus. Le mystère tdeinit tdeinit sert à démarrer tous les autres programmes &kde;. tdeinit peut démarrer les fichiers des programmes exécutables normaux ainsi que les modules chargeables tdeinit (KLM). Les KLM fonctionnent exactement comme les fichiers exécutables des programmes, mais peuvent être démarrés plus efficacement. Les KLM résident dans $TDEDIR/lib/kde3. L'inconvénient est que les programmes démarrés de cette manière apparaissent en tant que tdeinit dans la sortie de top et ps. Utilisez top ou ps pour voir le nom véritable du programme : % ps aux | grep bastian bastian 26061 0.0 2.2 24284 11492 ? S 21:27 0:00 tdeinit: Running... bastian 26064 0.0 2.2 24036 11524 ? S 21:27 0:00 tdeinit: dcopserver bastian 26066 0.1 2.5 26056 12988 ? S 21:27 0:00 tdeinit: klauncher bastian 26069 0.4 3.2 27356 16744 ? S 21:27 0:00 tdeinit: kded bastian 26161 0.2 2.7 25344 14096 ? S 21:27 0:00 tdeinit: ksmserver bastian 26179 1.1 3.4 29716 17812 ? S 21:27 0:00 tdeinit: kicker bastian 26192 0.4 3.0 26776 15452 ? S 21:27 0:00 tdeinit: klipper bastian 26195 1.0 3.5 29200 18368 ? S 21:27 0:00 tdeinit: kdesktop Ceci a un autre effet de bord, il complique la suppession un process qui cause des problèmes : % killall kdesktop kdesktop: no process killed Vous pouvez essayer killall tdeinit, pour tuer tous les process tdeinit qui aura pour effet d'arrêter tout &kde;. Une véritable destruction totale ! Il y a deux solutions simples pour ceci : % kdekillall kdesktop ou le bon vieux % kill 26195 kdekillall fait partie du paquet SDK de &kde;. Personnaliser &kde; Icônes du bureau &kde; utilise plusieurs types d'icônes : Documents Liens vers des sites web (en utilisant le fichier .desktop) Liens vers des applications (en utilisant le fichier .desktop) Périphériques - Disques, partitions, &etc; : Explicite en utilisant le fichier .desktop Automatique via devices:// io-slave Propre au fournisseur (&pex; My Computer de &SuSE;) Sites web Liens vers des sites web en utilisant le fichier .desktop : Créer un nouveauLien vers une URL.... Changez d'icône à l'aide des boîtes de dialogue Propriétés. Le fichier obtenu .desktop : [Desktop Entry] Encoding=UTF-8 Icon=/opt/kde3/share/apps/kdesktop/pics/ksslogo.png Type=Link URL=http://www.kde.org/ Applications Liens vers des applications en utilisant le fichier .desktop : Créer un nouveauLien vers une application.... 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. [Desktop Entry] Encoding=UTF-8 GenericName=IRC Client GenericName[af]=Irc Kliët GenericName[de]=IRC Programm ... GenericName[zu]=Umthengi we IRC SwallowExec= Name=KSirc Name[af]=Ksirc Name[de]=KSirc ... Texte stéréotypé Description traduite de manière générique, non utilisée sur le bureau Hérité, ne peut pas être supprimé Nom traduit, tel qu'il apparaît sur le bureau Icônes du bureau ... Name[zu]=Ksirc MimeType= Exec=ksirc %i %m Icon=ksirc TerminalOptions= Path= Type=Application Terminal=0 X-TDE-StartupNotify=true X-DCOP-ServiceType=Multi Categories=Qt;KDE;Network Types &MIME; pris en charge, non utilisé sur le bureau La ligne de commande à exécuter L'icône, provenant du thème des icônes ou du chemin d'accès complet Utilisée seulement si un terminal est nécessaire Dossier de travail pour une commande Texte plus stéréotypé Utilisé réellement si un terminal est nécessaire, une application texte Affiche un curseur animé, désactivé s'il ne fonctionne pas. L'application a-t-elle démarré correctement ? Supprimé s'il ne fonctionne pas Catégories pour le menu &kde;, non utilisé sur le bureau L'option <varname >Exec</varname > dans les fichiers <literal role="extension" >.desktop</literal > 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 : %f Un seul nom de fichier : utilisée lorsqu'on fait glisser un fichier sur une icône ou avec des associations de fichiers. %F Une liste de fichiers : utilisée pour les applications qui peuvent ouvrir plusieurs fichiers locaux en même temps. %u Une seule &URL; : si l'application peut gérer &pex; des &URL; &FTP; ou &HTTP; elle-même, sinon &kde;. %U Une liste d'&URL; : téléchargera le fichier d'abord puis transmettra un fichier local à l'application ! %d Le dossier du fichier à ouvrir : utile si l'application doit avoir un fichier dans le dossier de travail en cours. %D Une liste de dossiers : pas très pratique. %i L'icône avec l'option : l'application &kde; utilisera l'icône provenant de la ligne Icon= dans la barre des tâches. %m La mini-icône : héritée. %c La légende avec l'option : l'application &kde; utilisera le nom provenant de la ligne Name= dans la barre d'outilsr. Exemples : Ligne exec Commande exécutée ksirc %iksirc --icon ksirc cd %d; kedit $(basename %f)cd /tmp; kedit file.txt Périphériques Liens vers les périphériques en utilisant le fichier .desktop : Créer un nouveau périphérique Où définir quoi ? De nombreux endroits pour définir les icônes du bureau : ~/Desktop : copié depuis /etc/skel/Desktop $TDEDIR/apps/kdesktop/Desktop (fusionné) $TDEDIR/apps/kdesktop/DesktopLinks (copié) Icônes des périphériques (fusionnées dynamiquement) La distribution SUSE Linux copie certaines icônes dans starttde.theme depuis /opt/kde3/share/config/SuSE/default/ Menu &kde; Comment fonctionne-t-il Dans &kde; 3.2, un format de menu commun est introduit à http://freedesktop.org/Standards/menu-spec/ Avant &kde; 3.2 : Structure des dossiers sous share/applnk La structure des dossiers représente la structure des menus Chaque fichier .desktop représente une seule application Comme il a été difficile de réorganiser la structure dans &kde; 3.2, le nouveau format de menu : Définit une structure dans un seule fichier .menu Est basé sur des catégories Est partagé entre GNOME et &kde; Prend en charge les menus dans le style applnk également Exemple de applications.menu : <Menu> <Name>Office</Name> <Directory>suse-office.directory</Directory> <Include> <Filename>Acrobat Reader.desktop</Filename> <Filename>tde-kpresenter.desktop</Filename> <Filename>tde-kword.desktop</Filename> </Include> <Menu> Élément de menu avec 3 applications : /usr/share/applications/Acrobat Reader.desktop /opt/kde3/share/applications/kde/kpresenter.desktop /opt/kde3/share/applications/kde/kword.desktop Stocké où ? Les fichiers .menu décrivant la structure des menus. Les fichiers sont stockés dans $TDEDIR/etc/xdg/menus et /etc/xdg/menus. Ceux-ci stockent la structure des menus à l'échelle du système et sont contrôlés par $XDG_CONFIG_DIRS. $HOME/.config/menus stocke les changements propres à l'utilisateur dans la structure des menus et est contrôlé par $XDG_CONFIG_HOME. Pour plus d'informations, reportez-vous à http://www.freedesktop.org/Standards/basedir-spec. Les fichiers .desktop décrivent les applications et sont stockés dans : $TDEDIR/share/applications, /usr/share/applications, /usr/local/share/applications. Ce sont des fichiers .desktop d'application à l'échelle du système, qui sont contrôlés par $XDG_DATA_DIRS. $HOME/.local/applications contient les fichiers .desktop propres au système et les changements propres à l'utilisateur. Il est contrôlé par $XDG_DATA_HOME. Pour plus d'informations, reportez-vous à http://www.freedesktop.org/Standards/basedir-spec Les fichiers .directory décrivant les sous-menus sont stockés dans : $TDEDIR/share/desktop-directories, /usr/share/desktop-directories, /usr/local/share/desktop-directories. Ce sont des fichiers .directory à l'échelle du système, contrôlés par $XDG_DATA_DIRS. Les changements propres à l'utilisateur sont stockés dans $HOME/.local/desktop-directories. Ceux-ci sont contrôlés par $XDG_DATA_HOME. Pour plus d'informations, reportez-vous à http://www.freedesktop.org/Standards/basedir-spec Exemple de applications.menu : <Menu> <Name>Art</Name> <Directory>suse-edutainment-art.directory</Directory> <Include> <Category>X-SuSE-Art</Category> </Include> </Menu> Art est le nom interne de ce menu. suse-edutainment-art.directory définit le nom et l'icône de ce menu et le menu regroupe toutes les applications qui ont X-SuSE-Art répertorié comme catégorie, &pex; : Categories=Qt;KDE;Education;X-SuSE-Art suse-edutainment-art.directory définit le nom et l'icône de ce menu : [Desktop Entry] Name=Art and Culture Icon=kcmsystem Pièges courants Les applications qui ne sont pas dans le menu n'existent pas 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. Quand des applications sont indésirables dans le menu, placez-les soit dans le menu .hidden, soit dans un menu dédié avec NoDisplay=true dans le fichier .directory Menus essentiels $TDEDIR/etc/xdg/menus/applications-merged/ contient kde-essential.menu regroupant certains menus essentiels qui ne sont normalement pas affichés dans le menu &kde; lui-même : Le Centre de configuration a un menu Configuration caché dont le contenu est défini par kde-settings.menu et dont l'icône ainsi que le nom sont définis par kde-settings.directory. Le Centre d'informations comporte un menu Informations caché dont le contenu est défini par kde-information.menu et dont l'icône ainsi que le nom sont définis par kde-information.directory. Le menu Écrans de veille contient un menu Système / Écrans de veille caché, dont le contenu est défini par kde-screensavers.menu et dont l'icône ainsi que le nom sont définis par kde-system-screensavers.directory. $TDEDIR/share/desktop-directories/kde-system-screensavers.directory contient : NoDisplay=true Menus de style ancien &kde; continue à gérer les menus de style ancien qui sont définis par les structures de dossiers dans $TDEDIR/share/applnk (à l'échelle du système) et $HOME/.trinity/share/applnk (propre à l'utilisateur). Ceci est observé à moins que le fichier .desktop comporte une ligne Categories=. Dans ce cas, les catégories déterminent l'emplacement dans le menu. <application >KSycoca</application > KSycoca met en cache la structure des menus et les informations sur toutes les applications disponibles. Vous pouvez reconstruire la base de données avec kbuildsycoca. La base de données construite réside dans /var/tmp/tdecache-${USER}/ksycoca. Elle est automatiquement mise à jour par KDED, vérifiée pendant la connexion à &kde; et KDED surveille les changements au cours de l'ouverture de session. Pour désactiver la surveillance des changements (puisqu'il y a un risque de problème sur NFS), ajoutez ce qui suit à kdedrc : [General] CheckSycoca=false Pour forcer la régénération, exécutez touch $TDEDIR/share/services/update_ksycoca. &kmenuedit; &kmenuedit; est destiné à la configuration pour un seul utilisateur. Les changements apportés à la structure des menus sont enregistrés dans ~/.config/menus/applications-kmenuedit.menu, ceux des applications le sont dans ~/.local/share/applications/ et ceux qui concernent les sous-menus (icône, nom) dans ~/.local/share/desktop-directories/. 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. Tableau de bord de &kde; Le tableau de bord de &kde; est également connu comme &kicker;. Il est modulaire et repose sur les composants suivants : Applets, Boutons d'applications, Boutons spéciaux. Par défaut, le tableau de bord contient les applets suivantes : Pager - affiche les bureaux virtuels, Barre des tâches, Boîte à miniatures, Horloge. et les boutons spéciaux suivants : Menu &kde;, Bouton Bureau. Divers boutons d'applications sont également ajoutés : Bouton Dossier personnel, Bouton Navigateur, Bouton KMail. Associations de fichiers 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 $TDEDIR/share/mimelnk et chaque fichier .desktop de l'application contient une liste de types &MIME; pris en charge par cette application. kview.desktop: MimeType=image/gif;image/x-xpm;image/x-xbm;image/jpeg; image/x-bmp;image/png;image/x-ico;image/x-portable-bitmap; image/x-portable-pixmap;image/x-portable-greymap; image/tiff;image/jp2 kuickshow.desktop: MimeType=image/gif;image/x-xpm;image/x-xbm;image/jpeg; image/png;image/tiff;image/x-bmp;image/x-psd;image/x-eim; image/x-portable-bitmap;image/x-portable-pixmap; image/x-portable-greymap Les deux peuvent ouvrir image/gif. Laquelle est utilisée pour ouvrir un fichier .gif ? L'application ayant la préférence la plus élevée ! kview.desktop contient InitialPreference=3 alors que kuickshow.desktop contient InitialPreference=6 Par conséquent, &kuickshow; sera utilisé pour ouvrir les fichiers .gif. Comment pouvons-nous créer les paramètres par défaut de &kview; ? Un utilisateur peut changer les associations de fichiers dans le ¢reConfiguration;. Ces changements sont stockés dans $HOME/.trinity/share/config/profilerc. 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. Verrouiller &kde; Les bases de fonctionnement Les fonctionnalités de verrouillage de &kde; sont centrées autour des options suivantes : rendre les options de configuration immuables, restreindre des actions spécifiques, restreindre l'accès à certaines &URL;, restreindre l'accès à certains modules de configuration. Options de configuration immuables Verrouiller &kde; 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. Les options de configuration préexistantes de l'utilisateur sont ignorées dès lors qu'une option de configuration est rendue immuable. Les options peuvent être contrôlées par élément, par groupe d'éléments ou par fichier. 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. 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. Restrictions des actions 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. Enregistrer le document 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 Enregistrer le document est . 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 qui désactive toute la fonctionnalité qui offrirait l'accès utilisateur à un interpréteur &UNIX;. Restreindre l'accès utilisateur aux interpréteurs Pour empêcher l'accès utilisateur à un interpréteur de commandes, nous pouvons restreindre l'action en ajoutant ce qui suit à kdeglobals : [KDE Action Restrictions] shell_access=false Puisque ceci affecte le menu &kde; et les applications disponibles, nous devons forcer une mise à jour de la base de données sycoca : touch $TDEDIR/share/services/update_ksycoca Reconnectons-nous à &kde; et vérifions les points suivants : le &menuk;, dans &konqueror;, OutilsOuvrir un terminal, la commande d'exécution &Alt;F2. Vous trouverez une documentation complète sur les actions disponibles à l'adresse http://www.kde.org/areas/sysadmin/. Quelques-unes des actions les plus intéressantes sont répertoriées ci-dessous : L'option Configurer du menu Configuration L'option Rapport de bogue... du menu Aide. Le menu du &BDS; sur le bureau. Le menu du &BGS; sur le tableau de bord. Cache toutes les actions ou applications qui nécessitent un accès root. Cache toutes les actions ou applications qui fournissent un accès à l'interpréteur de commandes. Désactive l'option permettant de sélectionner le système d'impression (backend). Décide si l'utilisateur sera ou non en mesure de verrouiller l'écran Décide si l'utilisateur peut démarrer une deuxième session X (voir aussi &tdm;) Décide si l'utilisation des économiseurs d'écran OpenGL est autorisée Autorise les économiseurs d'écran qui ne masquent pas l'écran entier Restrictions sur les &URL; Il y a trois types de restrictions susceptibles de s'appliquer aux &URL; : list Pour contrôler si un listage de dossiers est autorisé. open Pour contrôler si certaines &URL; peuvent être ouvertes Redirect Pour contrôler si une &URL; peut ouvrir une autre &URL;, automatiquement ou via un lien hypertexte. 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;. Les règles suivantes désactivent l'ouverture des &URL; http et https en dehors de .notreentreprise.com : [KDE URL Restrictions] rule_count=2 rule_1=open,,,,http,,,false rule_2=open,,,,http,*.notreentreprise.com,,true 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. interdit l'ouverture de toute &URL; http ou https. autorise l'ouverture de n'importe quelle &URL; http et https dans le domaine .notreentreprise.com. Notez que le joker * n'est autorisé qu'au début d'un domaine. 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 $HOME : [KDE URL Restrictions] rule_count=2 rule_1=list,,,,file,,,false rule_2=list,,,,file,,$HOME,true interdit le listage de tout dossier local. autorise le listage des dossiers sous le dossier $HOME propre des utilisateurs. $HOME et $TMP sont des valeurs spéciales pour indiquer le dossiers personnel des utilisateurs et le dossier temporaire &kde; de l'utilisateur, &pex; /tmp/tde-bastian. Les règles suivantes font que l'utilisateur ne peut plus ouvrir les fichiers locaux qui sont en dehors de son dossier $HOME : [KDE URL Restrictions] rule_count=3 rule_1=open,,,,file,,,false rule_2=open,,,,file,,$HOME,true rule_3=open,,,,file,,$TMP,true interdit l'ouverture de tout fichier local. autorise l'ouverture des fichiers sous le dossier $HOME propre des utilisateurs. 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. 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. Par exemple, si nous voulons donner au serveur intranet www.monentreprise.com la possibilité de renvoyer à des fichiers locaux, nous pourrions ajouter la règle suivante : [KDE URL Restrictions] rule_count=1 rule_1=redirect,http,www.monentreprise.com,,file,,,true 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 : :local Les protocoles qui accèdent aux informations stockées en local : des exemples sont file:/, man:/, fonts:/, floppy:/ :internet Protocoles internet courants tels que http et ftp Les informations sur les protocoles sont stockées dans les fichiers *.protocol, qui se trouvent dans $TDEDIR/share/services. L'élément = définit le groupe auquel un protocole appartient : grep $TDEDIR/share/services/*.protocol Règles générales : Les protocoles :local peuvent renvoyer n'importe quel autre protocole Il est toujours autorisé de renvoyer à un protocole :internet Tous les protocoles ne font pas partie d'un groupe, fish:/ par exemple Modules de configuration &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. Le module de configuration Serveur mandataire apparaît dans le Centre de configuration mais fait également partie de la boîte de dialogue Configuration de Konqueror dans &konqueror;. Les modules de configuration individuels peuvent être démarrés via kcmshell module Pour démarrer le serveur mandataire, utilisez : kcmshell tde-proxy.desktop kcmshell proxy 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. Tous les modules de configuration font partie à proprement parler du menu &kde;. Les modules que l'on peut voir dans le Centre de configuration comportent normalement un fichier .desktop dans $TDEDIR/share/applications/kde et sont triés sous le menu Configuration-Modules par le kde-settings.menu, inclus depuis kde-essential.menu. kbuildsycoca 2> /dev/null | grep Configuration-Modules Les modules propres à une application comportent normalement un fichier .desktop sous $TDEDIR/share/applnk/.hidden, qui correspond au menu caché .hidden, inclus à la suite de <KDELegacyDirs/> kbuildsycoca 2> /dev/null | grep .hidden Dans &kde; 3.3, il est possible de modifier le Centre de configuration avec kcontroledit. kcontroledit fonctionne exactement comme kmenuedit, mais ne change que pour l'utilisateur actuel. Utilisez kiosktool pour effectuer les changements pour chacun. Les modules de configuration individuels peuvent être désactivés en ajoutant ce qui suit à kdeglobals : [KDE Control Module Restrictions] module-id=false Par exemple, pour désactiver le serveur mandataire, utilisez [KDE Control Module Restrictions] tde-proxy.desktop=false Vérifiez le Centre de configuration et la boîte de dialogue Configurer Konqueror... si la configuration du serveur mandataire est encore présente. L'administrateur paresseux &kde; DIY - Construisez vos propres outils DCOP Desktop COmmunication Protocol, DCOP (protocole de communication du bureau) est un mécanisme léger permettant la communication inter-processus. DCOP permet à l'utilisateur d'interagir avec les applications qui s'exécutent actuellement. &kde; fournit deux programmes pour tirer parti de DCOP : dcop, un programme en ligne de commande et kdcop, un programme d'interface graphique (GUI). Voici quelques remarques sur l'utilisation de dcop : dcop [options] [application [object [function [arg1] [arg2] ... ] ] ] Les applications qui peuvent ouvrir plusieurs fenêtres à la fois seront répertoriées sous la forme d'un PID d'<application> Tous les arguments sont sensibles à la casse. 'setFullScreen' et 'setfullscreen' sont deux fonctions différentes. Le jeton (token) de l'expression rationnelle * peut être utilisé dans l'application et les arguments de l'objet. % dcop konqueror-16006 konsole-8954 Voici quelques exemples de commandes et leur sortie : % dcop konsole-8954 Une &konsole; s'exécute avec un PID de 8954. % dcop KBookmarkManager-.../share/apps/kfile/bookmarks.xml KBookmarkManager-.../share/apps/konqueror/bookmarks.xml KBookmarkNotifier KDebug MainApplication-Interface konsole (default) konsole-mainwindow#1 ksycoca session-1 session-2 session-3 session-4 Vous voyez ici qu'il y a quatre sessions actives. % dcop QCStringList interfaces() QCStringList functions() int sessionCount() QString currentSession() QString newSession() QString newSession(QString type) QString sessionId(int position) void activateSession(QString sessionId) void nextSession() void prevSession() void moveSessionLeft() void moveSessionRight() bool fullScreen() void setFullScreen(bool on) ASYNC reparseConfiguration() Voici les options du programme &konsole; principal. % dcop QCStringList interfaces() QCStringList functions() bool closeSession() bool sendSignal(int signal) void clearHistory() void renameSession(QString name) QString sessionName() int sessionPID() QString schema() void setSchema(QString schema) QString encoding() void setEncoding(QString encoding) QString keytab() void setKeytab(QString keyboard) QSize size() void setSize(QSize size) Voici les options de la première session, session-1. % dcop true Cette commande place &konsole; en mode plein écran. Quand il y a plusieurs applications/objets, lequel devrez-vous utiliser ? Avez-vous une référence ? % echo DCOPRef(konsole-7547,konsole) % dcop session-6 % dcopstart konsole-9058 #!/bin/sh konsole=$(dcopstart konsole-script) session=$(dcop $konsole konsole currentSession) dcop $konsole $session renameSession Local session=$(dcop $konsole konsole newSession) dcop $konsole $session renameSession Remote session=$(dcop $konsole konsole newSession) dcop $konsole $session renameSession Code dcop $konsole $session sendSession 'cd /my/work/directory' KDialog &kde; DIY - Construisez vos propres outils 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;. kdialog kdialog Le composant KDialog peut être remplacé par l'option kdialog Enregistre ce qu'il faut ou non afficher à nouveau dans $TDEHOME/share/config/myfile (en insérant dans ce fichier les lignes suivantes : [Notification Messages] mykey=false À la place de , vous pouvez également faire appel à et , comme approprié. Par exemple, vous pourriez utiliser kdialog ou kdialog . Il est également possible de créer des boîtes de messages qui acceptent une réponse oui ou non. kdialog echo $? Valeur de retour Signification 0Oui, OK, Continuer 1Non 2Annuler 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 à 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. Les autres variations sont : comme , mais avec une icône différente Avec les boutons Continuer et Annuler. Avec les boutons Oui, Non et Annuler. Par exemple : kdialog kdialog Le résultat s'affiche sur la sortie standard. Pour le placer dans une variable, vous pouvez utiliser name=$(kdialog --inputbox "Saisissez votre nom :" "VotreNom"). Le dernier argument est optionnel, il sert à préremplir la boîte de dialogue. mot_de_passe=$(kdialog ) L'option ne fonctionne pas avec ou Il y a deux boîtes de dialogue qui permettent à l'utilisateur de faire un choix dans une liste : Permet à l'utilisateur de sélectionner un seul élément dans une liste. Permet à l'utilisateur de sélectionner un ou plusieurs éléments dans une liste. ville=$(kdialog ) $ville sera a, b, c ou d. ville=$(kdialog ) Madrid et Paris seront présélectionnées. Le résultat avec Madrid et Paris sélectionnées sera "b" "c". Si vous ajoutez l'option , elle placera b etc chacune sur une ligne propre, ce qui rend le résultat plus facile à traiter. file=$(kdialog --getopenfilename $HOME) file=$(kdialog --getopenfilename $HOME "*.png *.jpg|Image Files") file=$(kdialog --getsavefilename $HOME/SaveMe.png) file=$(kdialog --getexistingdirectory $HOME) &groupware-with-kontact;