[Tuto] Changer d'environnement sans devoir se déconnecter!

Elzen · Le 19/06/2008, à 15:30

Dépaysement complet en quelques clics

***Première étape: Le fichier .xsession***

Ce fichier, qui soit se trouve, soit est à créer dans votre répertoire personnel, était utilisé à l'époque où on se loguait en tty et pas en graphique: il était lu par la fameuse commande "startx" pour démarrer la session graphique. Il est encore possible de s'en servir pour lancer une session entièrement personnalisée, et c'est ce qu'on va faire (pour ceux qui se loguent via GDM, c'est l'option "Lancer le script XClient"). Il est donc impératif de commencer par comprendre comment il fonctionne.
Ce fichier se comporte comme un script shell, à savoir qu'il contient une suite de commandes (chacune sur une ligne) qui vont être appelées successivement (on attend toujours la fin d'une commande pour lancer la suivante). Lorsque le script se termine, la session fait de même.
Évidemment, dans le cadre d'une session graphique, on a peut-être envie que certaines actions soient lancées en simultané, et pas successivement (par exemple, un terminal et un gestionnaire de fenêtre). Pour cela, on fait lancer certaines commandes dans des processus séparés en plaçant une éperluette (le caractère "&") à la fin d'une commande, ainsi, celle-ci ne sera pas bloquante.
Placez donc dans ce fichier toutes les commandes qui devront être lancées au début de la session, pour éventuellement rester actives quel que soit l'environnement (par exemple, les daemons de préférences, "gnome-settings-daemon" pour Gnome et "kdeinit" pour KDE, ou bien encore un daemon de montage de périphériques, comme "gnome-volume-manager"). N'oubliez pas les éperluettes, faute de quoi votre session sera bloquée sur le daemon, ce qui n'est pas génial. Si vous aimez bien avoir un son au démarrage, vous pouvez également en lancer un, par exemple via mplayer.
Il faut cependant que la toute dernière commande soit bloquante, elle, et même qu'elle ne s'arrête pas tant qu'on ne le lui demande pas explicitement, pour que la session reste ouverte. Habituellement, on utilise comme commande bloquante le gestionnaire de fenêtres, c'est le plus simple. Mais dans notre cas, on veut justement pouvoir le fermer pour le remplacer par d'autres. On pourait utiliser un daemon quelconque, mais il est également possible de se faire un petit programme C qui ne fasse strictement rien:
sleeponly.c

#include <unistd.h>

int main() {
	while (1) {
		sleep(36000);
	}; return 1;
}

Enregistrez ce bout de code dans le fichier "sleeponly.c", puis compilez par la commande
gcc -Wall sleeponly.c -o XSession
puis placez le chemin absolu du fichier XSession, sans éperluette, à la toute fin de votre fichier .xsession, ainsi, votre session graphique restera ouverte jusqu'à ce que vous ne fermiez ce programme (par la commande assez explicite "killall XSession").
Ceci fait, nous avons donc une session graphique tout ce qu'il y a de plus respectable, dans laquelle nous pourront changer de gestionnaire de fenêtres, voire d'environnement complet. On peut donc passer à l'étape 2.

Note: le fichier .xsession ne contient pas encore tout ce qu'il faut. Dans toute la suite, à chaque fois que je vous conseillerais d'ajouter une commande à votre .xsession, il faudra l'ajouter avant la dernière ligne dont on vient de parler, et ne surtout pas oublier l'éperluette finale, même si je ne l'ai pas indiqué.

Ah, et à titre indicatif, je vous donne le contenu de mon propre .xsession:
~/.xsession

wmaker & #WindowMaker (voir l'étape suivante)
wmclock & #Petit utilitaire qui affiche une horloge dans WindowMaker
/home/seth/Scripts/SessionDaemon -jar /home/seth/Scripts/SessionDaemon.jar &
#SessionDaemon est un lien symbolique vers java, qui permet de changer le nom d'execution du programme, pour éviter qu'une éventuelle commande "killall java" vienne terminer ce daemon.
#Le jar contient donc un daemon qui va gérer le relancement de windowmaker (voir plus bas) et gérer également un genre de lanceur d'applications que je me suis programmé.
timidity -iA -Os -B2,8 & #Ça, c'est pour le bon fonctionnement de NoteEdit.
gnome-settings-daemon & #Préférences GTK.
kdeinit & #Préférences Qt.
bash -i -c "sleep 5 ; guidance-power-manager" &
#Mon gestionnaire de batterie. Lancé ainsi car son iconisation dans le system tray est un peu capricieuse.
gnome-volume-manager --sm-disable & #Montage de périphériques.
gnome-keyring-daemon & #Trousseau de clef.
nm-applet --sm-disable & #Gestionnaire de connexions (ordi portable oblige).
update-notifier & #Le gestionnaire de mises à jour, quand même.
trayer --edge bottom --align right --widthtype request --heighttype request --expand true --distance 24 &
#Ça, c'est mon System Tray, j'y reviendrais à l'étape 3 ;)
/home/seth/Scripts/XSession #Le fameux programme bloquant.

***Deuxième étape: Un environnement de base qui revient tout seul***

Pour commencer, il nous faut choisir le gestionnaire de fenêtre qui sera lancé au démarrage de la session, et auquel on reviendra en fermant les autres environnements. Mon choix s'est porté sur WindowMaker, qui présente l'avantage d'être léger et plutôt convivial, et surtout de démarrer extrêmement rapidement.
Il est parfaitement fonctionnel à lui tout seul, donc si vous voulez juste vous connecter quelques secondes pour vérifier vos mails ou quelque chose comme ça, vous n'aurez même pas besoin de lancer un autre environnement, et ce sera autant de temps de gagné. Il faudra par contre probablement l'installer, il n'est pas forcément de base sur votre distribution. Mais ça, je suppose que vous savez comment faire
Il se lance simplement par la commande "wmaker" (pensez à l'ajouter à votre .xsession si ce n'est pas déjà fait), et se termine par la commande "killall WindowMaker". Il va maintenant falloir faire en sorte qu'il revienne automatiquement après avoir été fermé, pour ne pas laisser votre session ouverte sans environnement graphique, ce qui risquerait d'être assez gênant. Pas besoin de tout mon programme Java, en théorie, une simple commande shell suffit:
bash -c "while test 1 -eq 1; do wmaker; sleep 1; done" &
Vous pouvez déjà copier cette ligne dans votre .xsession, cela fonctionnera. L'inconvénient, c'est que si on se contente de ça, WindowMaker se relancera systématiquement trop vite, et vous ne pourrez pas profiter de compiz, enlightenment ou metacity. Il va donc falloir ruser.
Pour cela, on va se créer un script unique qui permette de lancer tous les environnements, et surtout de ne réagir qu'au bon moment. Je vous indique le mien, correctement commenté, et je vous laisse le soin de vous constituer le vôtre selon vos besoins.
envlaunch

FILE=/tmp/envlaunched #Une adresse de fichier temporaire.
if test -e $FILE
   then exit 0
fi #Si le fichier temporaire existe, un environnement est en cours d'exécution, on s'arrête là.
case $* in
	WindowMaker) wmaker;; #Ça, c'est tout simple.
	Gnome) touch $FILE #On crée le fichier de blocage.
		killall wmclock #Cet utilitaire ne sert que sous WindowMaker.
		killall WindowMaker #On va changer de gestionnaire de fenêtres.
		gnome-session #Lancement de la session Gnome.
		killall gnome-power-manager #Ce truc se lance systématiquement quand Gnome se termine, je ne sais pas pourquoi, et j'en veux pas.
		wmclock & #On relance l'utilitaire.
		rm $FILE;; #Suppression du fichier de blocage pour relancer WindowMaker.
	KDE) touch $FILE
		killall wmclock
		killall WindowMaker
		startkde #Lancement de la session KDE
		bash -i -c "sleep 2; guidance-power-manager" & #KDE termine guidance-power-manager en se terminant, donc je le relance.
		wmclock &
		rm $FILE;;
	Xfce) touch $FILE
		killall wmclock
		killall WindowMaker
		startxfce4 #Lancement de la session Xfce
		wmclock &
		rm $FILE;;
	e17) touch $FILE
		killall wmclock
		killall WindowMaker
		enlightenment_start #Lancement d'Enlightenment
		wmclock &
		rm $FILE;;
esac

Il n'y a plus qu'à rendre ce script exécutable (chmod +x envlaunch) et à remplacer dans la commande citée ci-dessus "wmaker" par "envlaunch WindowMaker" (en précisant le chemin d'accès pour envlaunch, quand même), et notre environnement multi-session fonctionnera.
Ensuite, plus qu'à créer des boutons dans le "dock" intégré à WindowMaker qui lanceront envlaunch avec le bon paramètre (donc ici, Gnome, KDE, Xfce ou e17), et cliquer sur ces boutons fermera WindowMaker pour lancer l'environnement indiqué.
Pour quitter l'environnement en question, il suffit d'utiliser le bouton de logout habituel pour que celui-ci se termine et que l'on revienne sur WindowMaker. (Attention, pour Enlightenment, choisissez "Quitter enlightenment", il me semble que "Déconnecter" est un peu trop violent).
Il ne reste plus que quelques petits problèmes à régler... c'est notre dernière étape.

***Troisième étape: Résoudre les bugs***

Premier problème: fermeture trop efficace.
L'un des avantages de ce système est de pouvoir avoir des fenêtres qui restent ouvertes au changement d'environnement. Seulement voilà, les environnements complets comme Gnome vont avoir tendance, quand on les arrête, à fermer toutes les applications qu'ils ont ouvert. C'est-à-dire que si vous lancez par exemple Firefox depuis le bouton prévu à cet effet dans gnome-panel ou depuis le menu application, Firefox se fermera quand vous fermerez Gnome.
Par contre, les applications lancées autrement, par exemple celles qui avaient été lancées sous WindowMaker avant le passage à Gnome, elles, restent en place. De même que les applications lancées par ces applications-là.
La solution est donc simple: un genre de dock (c'est à ça que sert mon truc en Java) qui se lance au démarrage de la session et qui reste démaré quel que soit l'environnement, et tout ce qui est lancé par ce dock restera ouvert au changement d'environnement... ou presque.

Second problème: KDE ne joue pas le jeu.
Eh oui, car il y a ça. Vous avez dû le remarquer dans mes commentaires là-haut: certaines applications de KDE, comme guidance-power-manager ou AmaroK, sont fermées au démarrage de KDE, et si on les relance, elles le sont de nouveau à sa fermeture.
Je ne sais pas à quoi c'est dû, et la seule solution que j'y ai trouvé pour l'instant, c'est de les relancer manuellement.

Troisième problème: Stabilité du System Tray.
Le System Tray, aussi appelé boite à miniatures ou zone de notifications, c'est l'applet de kicker, gnome-panel, xfce4-panel ou autre qui reçoit les icônes de certaines applications, comme les gestionnaires de mises à jour, de batterie ou de connexion, ou bien les clients de messagerie instantanée comme Emesene ou aMSN.
Or, Enlightenment ou WindowMaker, par exemple, n'ont rien pour gérer ce genre de choses. De plus, certaines applications n'apprécient pas trop que le System Tray soit fermé puis redémarré (comme c'est forcément le cas si on passe de Gnome à KDE, par exemple).
La solution est de supprimer ces applets de tous les panels, et à la place, de lancer un System Tray au démarrage de la session, qui va rester ouvert tout le temps. Pour cela, j'ai choisi trayer, un petit utilitaire très sympa pouvant être lancé avec pas mal d'options (installez-le puis consultez le man). Une fois choisi les options qui vont bien (n'oubliez pas qu'il restera actif dans tous les environnements, sans être relancé, il faut donc choisir un placement et une apparence qui s'intègrera partout), il vous suffit de rajouter la commande dans votre .xsession, et ce problème est résolu.
Pour ceux qui aiment scripter, l'utilitaire wmctrl permet entre autres de déplacer les fenêtres, vous pouvez vous bricoler un petit quelque chose pour masquer trayer s'il vous dérange.

Voilà, je crois que j'ai à peu près fait le tour de tout ce qu'il m'a été donné de remarquer pendant mes quelques jours d'utilisation de ce système.
Notez que vous pouvez également vous bricoler des environnement sur mesure également avec ce système. Par exemple, utilisant metacity comme gestionnaire de fenêtre de Gnome, je prévois de me créer également un environnement utilisant Beryl (pas Compiz, parce que je suis encore sous Feisty Fawn, et que Compiz ne tourne pas extrêmement bien dessus, mais bref) ainsi qu'un dock (que je n'ai pas encore choisi, d'où son absence actuelle dans mon script envlaunch).
Il suffit simplement de se créer un nouveau cas dans votre envlaunch, commençant par la création du fichier de blocage et terminant par sa suppression (n'oubliez pas le ";;" final indiquant au shell que le cas est terminé), dans lequel vous lancerez les différents utilitaires avec une éperluette et le gestionnaire de fenêtre sans éperluette, puis les lignes pour fermer vos utilitaires avant le retour à WindowMaker.

Si vous avez des questions, des conseils ou des retours, n'hésitez pas...

Hiéroglyphe · Le 23/06/2008, à 14:28

En fait si j'ai bien suivit, toute la difficulté vient du fait que Gnome et KDE ne sont pas que des WM mais des environnements complets. Sinon on peut passer très facilement de IceWM à WMaker et autre DWM (la plupart le propose d'ailleurs via un simple clic dans un menu)...

D'ailleurs ce serait possible de remplacer Metacity par Ion3 ? Histoire de profiter de tous les petits plus bien pratique de Gnome tout en ayant le plus efficace des WM

Elzen · Le 27/06/2008, à 23:09

Oh, oui, ça, bien sur, c'est faisable. Tout simple, même(modification d'une seule petite variable d'environnement) par divers moyen et sans perturber ton Gnome habituel si tu veux y retourner (un .xsession de deux lignes, un fichier .desktop en plus...)
Ceci dit, dire que c'est le meilleur des WM... ça dépend pour qui, quoi

Pour le passage d'un WM à un autre, c'est en effet possible sur certains, mais c'est pas universel. Je cherchais à mettre en place une solution qui puisse vraiment permettre de passer de n'importe quel environnement à n'importe quel autre.
D'ailleurs, le daemon en shell pour relancer WindowMaker n'est pas obligatoire, même si c'est une sécurité.

Je réécrirais peut-être ce tuto un peu plus proprement quand j'aurais le temps.

o7a · Le 29/06/2008, à 14:20

C'est exactement le genre d'astuces que je recherche.

Ça a l'air vraiment sympa, je vais essayer. Merci de partager ce travail.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 19/06/2008, à 15:30

[Tuto] Changer d'environnement sans devoir se déconnecter!

#2 Le 23/06/2008, à 14:28

Re : [Tuto] Changer d'environnement sans devoir se déconnecter!

#3 Le 27/06/2008, à 23:09

Re : [Tuto] Changer d'environnement sans devoir se déconnecter!

#4 Le 29/06/2008, à 14:20

Re : [Tuto] Changer d'environnement sans devoir se déconnecter!

Pied de page des forums