FVWM et la gestion des sessions

Avec le tout le battage et l'attention entourant les environnements de bureau tels que KDE et Gnome, on peut se demander « pourquoi utiliser d'autres gestionnaires de fenêtres quand ces deux derniers offrent tout ce dont on a besoin » : gestionnaires de fichiers intégrés, jolis gadgets, etc. La réponse est simple. KDE et Gnome nécessitent de grandes quantités de mémoire et, si comme moi, vous avez du matériel un peu ancien, vous recherchez souvent des alternatives qui rendent votre système utilisable.

Vous pourriez penser que, KDE comme Gnome disposant de tout ce dont l'utilisateur a besoin, pourquoi s'embêter à changer ? En d'autres termes, y a t-il une autre façon d'imiter ce que font KDE et Gnome, pour un coût en mémoire plus faible ? La réponse est « Oui ». Une des fonctionnalités les plus demandées de la part des utilisateurs depuis des années concerne l'utilisation des gestionnaires de sessions, qui est l'objet de cet article.

La gestion de session permet de sauvegarder et de rappeler l'état des applications en cours. Ceci inclut la taille des fenêtres, leur position sur l'écran, et sur quel bureau/page elles se trouvent (si vous utilisez un gestionnaire de fenêtre qui supporte cette fonction).

Cela fonctionne par la récupération des identifiants des « clients » par le gestionnaire de session. L'application à partir de laquelle on récupère ces identifiants est habituellement la fenêtre principale, mais pas les autres sous-fenêtres (que nous appellerons des fenêtres transitoires), car elles sont pilotées par des évènements spécifiques et ne sont affichées que lorsque ceux-ci sont déclenchés dans l'application en cours.

Toutefois, la fenêtre parente doit s'enregistrer directement dans le gestionnaire de session, ainsi ce dernier connaît la fenêtre originelle ainsi que toutes les fenêtres transitoires rattachées. Une telle fenêtre principale comporte une propriété appelée WM_CLIENT_LEADER. Celle-ci permet de communiquer avec le gestionnaire de session. Une propriété supplémentaire, WM_WINDOW_ROLE, est utilisée par fvwm pour définir l'état de la fenêtre. Ces requêtes sous-jacentes proviennent du serveur X lui-même, qui les envoie au gestionnaire de fenêtre en cours.

Ainsi un gestionnaire de session est un programme qui gère ces protocoles, échange avec le serveur X sous-jacent et le gestionnaire de fenêtre pour déterminer comment les fenêtres doivent être paramétrées. C'est le travail du gestionnaire de fenêtres, s'il fonctionne sous un gestionnaire de session, de communiquer avec lui pour s'informer de ses indications.

Il n'y a pas beaucoup de véritables gestionnaires de session. Mais pour ceux qui existent, les faire fonctionner avec fvwm est un défi. Je vais les étudier chacun à leur tour et évaluer leur performance.

Pour que fvwm utilise la gestion de session, il doit être compilé avec --enable-sm lors du ./configure. Une fois ceci fait, vous pouvez utiliser le gestionnaire de session que vous préférez.

Quand fvwm se charge, sans l'utilisation d'un gestionnaire de session, il se configure avec un fichier précis, habituellement $HOME/.fvwm2rc ou $HOME/.fvwm/.fvwm2rc.

Mais fvwm, dans son fichier de configuration, nous permet de définir deux sections de démarrage/redémarrage. L'une pour fonctionner avec un gestionnaire de session, l'autre sans. Par exemple, voici un échantillon d'InitFunction pour fvwm :

DestroyFunc InitFunction
AddToFunc InitFunction
  + I Module FvwmBanner
  + I xsetroot -solid cyan
  + I Exec xterm
  + I PipeRead 'Wait exec run_parts.rb'

Ceci se chargera normalement à chaque démarrage de fvwm sans gestionnaire de session. Le démarrage spécifique au gestionnaire de session ressemblera à ceci :

DestroyFunc SessionInitFunction
AddToFunc SessionInitFunction
  + I Module FvwmBanner

Ainsi l'utilisateur peut définir des instances séparées pour démarrer ou non avec un gestionnaire de session. Mais il faut remarquer que si fvwm fonctionne avec un gestionnaire de session, il exécutera uniquement les sections SessionInitFunction et celles qui leur sont liées, et pas du tout les sections InitFunction.

C'est également une mauvaise idée de lancer xterm et d'autres applications à l'intérieur des fonctions de session, car ceci interfère souvent avec la manière dont le gestionnaire de fenêtre interprète comment manipuler la fenêtre.

Pour nous permettre cependant d'utiliser le gestionnaire de session, nous devons nous assurer qu'il est chargé dans le bon ordre. A chaque démarrage du serveur X, que cela vienne de la ligne de commande (startx) ou d'une interface graphique telle que xdm, kdm, gdm ou wdm, un certain fichier est lu : $HOME/.xsession. Normalement, il ressemblerait à ceci :

 #!/bin/bash

program1 &
program2 &
exec fvwm

Afin que le gestionnaire de session fonctionne correctement, nous devons nous assurer qu'il s'agit du dernier programme exécuté, comme ci-dessous :

 #!/bin/bash

program1 &
program2 &
smproxy &
fvwm
exec gestionnaire_de_session

Le terme gestionnaire_de_session ci-dessus doit être remplacé par le véritable nom du gestionnaire de session.

smproxy est obligatoire dès qu'il y a des programmes ne supportant pas nativement les appels de programme qui font partie de la gestion de session. Dans de tels cas, smproxy tentera les appels à leur place.

Voici le gestionnaire de session originel, assez limité comparé aux autres gestionnaires que nous allons étudier. Son utilisation avec fvwm est exactement celle décrite ci-dessus. Quand tout est chargé, vous devriez voir une fenêtre ressemblant à la suivante...

La fenêtre est assez claire en elle-même. En cliquant sur le bouton Load Session, vous pourrez charger la session précédente. Quand vous démarrez le serveur X au début, voici donc ce que vous verrez. Vous pouvez supprimer cette fenêtre, mais pour cela vous devez créer une session.

La figure 2 montre ce qui s'affiche après que tout a été chargé. En utilisant cette fenêtre, vous pouvez vous faire une idée des applications qui sont déjà reconnues, sauvegarder la session, etc... Le seul inconvénient avec xsm est le peu d'applications qu'il reconnaît. Si l'application n'est pas strictement compatible avec X, alors xsm ne sera pas capable de la manipuler.

Pour sauvegarder l'état de votre session, et ainsi savoir si xsm peut identifier d'autres fenêtres, appuyez sur le bouton checkpoint pour obtenir un écran comme dans la figure 3.

A partir de là vous pouvez saisir le nom de la session que vous voulez sauvegarder. J'ai déjà indiqué que vous pouviez supprimer la Figure 2, en ayant chargé le nom de session de votre choix. Une fois la session sauvée, éditez le fichier : $HOME/.xsession et modifiez la ligne : exec xsm en : exec xsm -session [nom] où "[nom]" est le nom de la session.

xsm cause également des problèmes avec fvwm car vous devez quitter xsm pour sauvegarder la session, puisque xsm est le processus maître. J'ai trouvé ceci passablement ennuyeux. Je recommande toutefois xsm pour tout ceux qui utilisent des applications simples, ou qui désirent seulement exécuter certains programmes et ne veulent pas installer Gnome ou KDE pour utiliser les caractéristiques des sessions dont ils disposent.

Voici le meilleur gestionnaire de session à utiliser avec fvwm. Ceci parce que fvwm est compatible Gnome et fonctionnera bien avec (il faut supporter spécifiquement EWMH). A la différence d'xsm, Gnome-Session manipule les sessions beaucoup plus efficacement. Sous Debian©, on peut l'installer avec la commande : apt-get install Gnome-Session. Mais tout comme xsm, le fichier ~/.xsession devra être modifié, cette fois-ci pour ressembler à ce qui suit :

#!/bin/bash

program1 &
program2 &
exec Gnome-Session

Notez bien que démarrer les « program1 » et « program2 » ci-dessus, avant le gestionnaire de session, chargera deux instances du même programme à chaque fois puisque fvwm les lance d'abord de manière normale, et ensuite le gestionnaire de session les chargera car il aura (on l'espère) sauvegardé leur état. C'est juste pour avoir ceci à l'esprit.

Quand vous vous connectez à X, Gnome se chargera—ne paniquez pas. La douleur ne durera pas longtemps. Nous avons besoin de remplacer sawfish ou metacity (selon que vous utilisiez Gnome1 ou Gnome2) par fvwm, pendant que Gnome-Session s'exécute. Ainsi quand nous sauvegarderons la session il saura qu'il faut charger fvwm et pas un autre gestionnaire de fenêtre.

Pour réaliser cela nous pouvons essayer de supprimer le gestionnaire de fenêtre actuel et le remplacer à la volée par fvwm. La commande :

fvwm --replace &

lancée dans un terminal pourrait réussir. Dans le cas contraire il faudra communiquer avec Gnome-Session directement. Assez bizarrement, il existe une application Gnome qui fournit cette interface : gnome-session-properties. C'est une application vraiment utile pour personnaliser le gestionnaire de session. Mais dans le but de faire fonctionner fvwm avec Gnome-Session, nous devons explicitement supprimer soit sawfish soit metacity

Bien qu'assez vide, la figure 4 montre les programmes que le gestionnaire de session a enregistré et chargé. Tout ce qui reste à faire est de « tuer » le fvwm qui fonctionnait précédemment, en saisissant dans un terminal :

killall fvwm

Puis, en retournant dans la fenêtre gnome-session-properties, sélectionnez le gestionnaire de fenêtre en cours (sawfish ou metacity), et cliquez sur le bouton Style qui ramène l'état actif à normal. Vous devez ensuite cliquer sur Apply. Ce qui vient d'être fait c'est de s'assurer que lors du redémarrage de la session le gestionnaire de fenêtre précédemment chargé ne le sera plus. Puis dans un terminal saisissez :

killall [wm] && sleep 5s && fvwm &

où wm est à remplacer par sawfish ou metacity. Aussitôt fait, sauvegardez la session. Il faut signaler que pour les applications qui ne sont pas vraiment compatibles avec la gestion de session, il existe une option pour que Gnome-Session lance ces programmes, en utilisant l'onglet "startup programs" (figure 4).

Il existe un problème connu avec tous les gestionnaires de session (Gnome-Session en particulier) : ceux-ci engendrent de multiples instances de certains programmes. Le cas notoire avec fvwm est xclock. Toutes les informations sur les programmes à lancer, etc... , sont stockées dans un fichier, et il est facile de résoudre ce problème. Ce script (écrit en Ruby) réparera cette anomalie qui devient vite ennuyeuse. Pour l'utiliser, il suffit de suivre les instructions suivantes :

1. copier le script dans /usr/local/bin
2. exécuter la commande : chmod 711 /usr/local/bin/cprocess.rb
3. modifier la ligne #! dans le script pour pointer vers le binaire Ruby
4. ouvrir ~/.xsession et ajouter la ligne suivante : ruby /usr/local/bin/cprocess.rb

avant de charger Gnome-Session.

C'est vraiment tout ce qu'il y a à faire pour paramétrer et utiliser Gnome-Session avec fvwm.

C'était un bref aperçu de la manière dont différents gestionnaires de session sont utilisables avec fvwm. Il en existe d'autres tels que ksmserver de KDE et xfce-session de XFCE4, mais je ne les ai pas essayés avec fvwm et je ne sais pas à quoi ils ressemblent. A côté des gestionnaires de session, il y a également deux modules natifs de fvwm intéressants, nommés : FvwmSave et FvwmSaveDesk. Bien que ce ne soient pas des gestionnaires de session, ils fournissent des fonctionnalités très similaires. On en discutera dans d'autres articles les prochains mois.