On 6/19/23 15:06, Michel Verdier wrote:
Le 19 juin 2023 Bernard Schoenacker a écrit :
Ce n'est pas une histoire de window desktop manager, mais simplement une
histoire
qui concerne le système freedesktop...
Je vous invite à consulter le tutoriel concernant xdg-open, voici un exemple :
Je connais xdg, mais la demande initiale précise :
Après un redémarrage, j'ai besoin de retrouver mon poste de travail
dans l'état où il était avant ce redémarrage.
Chaque logiciel ouvert et ses fenêtres.
Je peux m'arranger avec un environnement choisi/fixe.
Car je n'ai pas encore besoin que l'environnement, dans son état
quelconque obtenu en travaillant, soit automatiquement mémorisé et
restauré au redémarrage.
C'est pourquoi un lancement automatique des applis à partir d'un window
manager suffit. En toute bonne logique via un .xsession ou autre script
de démarrage ça irait aussi. Et si le window manager est dynamique (comme
dwm entre autres) ça couvre les problèmes de fenêtrage cités.
A mon sens, cette solution ne restaure pas un GNU emacs (avec tous ses
fichiers précédemment ouverts et affichés) et ne restaure pas le contenu
affiché dans un émulateur de terminal comme xfce4-terminal (et encore
moins un éventuel programme, comme un make, qui y tournait au moment de
l'arrêt précédent).
Je me permets d'insister: la persistence (hors hibernation du système
Linux entier en zone de swap) de tous les processus actifs à un instant
T n'est pas facilement possible sur un Linux usuel.
Si toutes les processus et applications actives sont graphiques (ce qui
exclut un compilateur GCC, une base de donnée PostGreSQL, un serveur web
comme lighttpd, un débogueur comme GDB, etc) et si elles sont toutes
bien codées et conformes à https://tronche.com/gui/x/icccm/ on peut
espérer que le gestionnaire de fenêtres communiquera élégamment avec elles.
Mais dans le cas général, un Linux a aussi des processus en ligne de
commandes, et ceux-là ne sont pas restaurés par le gestionnaire de fenêtre.
Pour s'en convaincre, compiler un gros logiciel, par exemple
http://gcc.gnu.org/ ... depuis son code source (ça prend des heures) et
éteindre sa machine (proprement, par le menu ) pendant la
compilation. Au redémarrage, cette grosse compilation ne reprendra pas.
La preuve en est est la complexité de systemd qui a été inventé pour
gérer ce genre de choses.
Du point de vue du dévelopeur, chaque programme et chaque processus
devrait traiter correctement le signal SIGTERM et SIGPWR. C'est complexe
à coder. Voir https://man7.org/linux/man-pages/man7/signal.7.html et
https://man7.org/linux/man-pages/man7/pthreads.7.html et
https://man7.org/linux/man-pages/man7/signal-safety.7.html
Dans la vraie vie, les administrateurs systèmes ont du boulot, et les
onduleurs sont utiles sur des machines Debian dont on voudrait qu'elle
gérent fiablement les coupures de courant.
Librement.
--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/
