Les « trucs » listés ici présentent plusieurs particularités : d'abord, ils représentent des éléments de base matériels ou logiciels (processus, horloge, capteurs divers…). Ensuite, il y a (pour l'instant en tout cas) peu de moyens d'interagir avec eux (peu ou pas de requêtes, un objet control qui ne permet rien de particulier…). Enfin, ils évoluent environ en permanence, sans que ce ne soit déclenché par un événement précis, ce qui fait que les fonctions d'écoute seront automatiquement appelées arbitrairement une fois par seconde.
Le premier de ces « trucs » est le système lui-même, accessible via le chemin « system ». Il fournit les clefs « type » qui indique le type de système (généralement « posix », parce que je doute que mon code tourne sur autre chose), « arch » qui indique l'architecture processeur (« x86_64 » dans mon cas), « system » qui indique le nom d'affichage du système (« Debian GNU/Linux » chez moi), « kernel » qui indique le nom et la version du noyau, « domain » qui indique l'extension de domaine de la machine, et « hostname » qui indique le nom de base de la machine, celles-ci étant normalement fixes. Enfin, une clef « uptime » indique le nombre de secondes écoulé depuis l'allumage qui, lui, change en permanence.
TODO : ce serait probablement chouette de permettre d'éteindre/redémarrer la machine par des requêtes envoyées au système, mais je n'ai aucune idée de comment faire ça, sauf à passer par les commandes reboot et poweroff qui nécessitent les droits root (éventuellement par un SUID), ce qui n'est pas spécialement pratique à embarquer ici.
Les enfants directs du « truc » système sont, dans l'ordre, l'horloge, le réseau, les différents trucs listés par ACPI, et les processeurs, tous détaillés ci-dessous. Les processus, eux aussi détaillés ci-dessous, ont également un chemin d'accès en « system/ » mais possèdent leur propre arborescence séparée. Enfin, un « stuff » particulier dont le chemin est « system/root » permet de lister la racine de l'arborescence (qui n'est pas sélectionnable directement, puisque son chemin se termine par le / par lequel il commence).
Le chemin « system/clock » permet d'obtenir un « truc » correspondant à l'horloge système, qui connait les clefs « timestamp » (nombre de secondes depuis EPOCH, également accessible par « stamp »), « year », « yearday », « month », « monthday » (également accessible par « day »), « week », « weekday », « hour », « minute », « second », « timezone » (également accessible par « zone ») et « tzname ». Même si elles ne sont pas listées (car en nombre potentiellement infini), toutes les clefs contenant le caractère « % » sont également reconnues : dans ce cas, le résultat de la fonction strftime est renvoyé, permettant d'obtenir l'heure au format désiré.
L'icône affichée pour l'horloge est générée automatiquement : il s'agit d'un disque blanc cerclé de noir (les couleurs changeront peut-être en fonction du thème graphique) sur lequel deux aiguilles indiquent les heures et les minutes. Si la taille de l'icône est d'au moins 25 pixels de côté, une troisième aiguille est ajoutée pour les secondes.
Les différentes interfaces réseau sont accessibles par leur nom, avec des chemins comme « system/enp0s2 » ou « system/wlan0 » (l'ancienne et la nouvelle mode sont normalement reconnues). Il est possible d'obtenir un « stuff » listant toutes les interfaces réseau disponibles avec le chemin « system/network ». L'interface de loopback (« system/lo ») est listée, même si sa pertinence est généralement moindre.
Une interface réseau possède les clefs suivantes si elles sont disponibles : « status » (« up » ou « down », voire « unknown », qui est également dans les états de la carte. La valeur pourrait d'ailleurs éventuellement ici être remplacée par un booléen ?), « speed » (vitesse de transfert), « mtu » (taille maximale des paquets), « ipv6 » (tuple contenant les IPv6 utilisées), « ipv4 » (chaîne indiquant l'IPv4 utilisée), « mac » (adresse mac de la carte réseau), « sentpackets », « recvpackets », « sentbytes », « recvbytes » (nombres de paquets/d'octets envoyés et reçus), « dropout », « dropin », « errout », « errin » (nombre de paquets dropés et d'erreurs), et « type » (« wired », « wireless » ou « virtual », qui est également passé en état). Pour les cartes réseau sans fil, lorsqu'elles sont connectées, on ajoute également les clefs « essid » (nom du réseau) et « signal » (qualité de la connexion, en pourcentage)
La plupart des données concernant les interfaces réseaux sont récupérées à l'aide de la bibliothèque psutil. Si celle-ci n'est pas disponible, on récupère le statut et les adresses IPs à l'aide de la commande ip -br a, et si possible les adresses mac depuis /sys/class/net/CARTE/address, mais les détails sur les nombres de paquets ne sont pas fournis. Le essid et le signal ne proviennent pas de psutil et sont donc toujours disponibles.
Les cartes réseaux ont une icône prise dans le thème en fonction de leur type, sur laquelle on ajoute un petit symbole indiquant s'il est up ou down. Pour les cartes sans fil connectées, ce symbole est remplacé par une représentation visuelle de la qualité de la ligne. Il est possible de donner une icône plus spécifique à une interface particulière (en gardant le symbole d'état) avec la requête « reicon:X ». Les cartes sans fil peuvent également afficher une icône spécifique au ssid concerné, mais il n'y a pas encore de moyen automatique de configuré ces icônes.
TODO : il faudrait rajouter aussi un état pour indiquer si la connexion est possible ou pas, c'est-à-dire pour les interfaces filaires si le fil est branché, et pour les interfaces sans fil, si elles ont été bloquées (que ce soit logiciellement ou matériellement). Je ne sais pas encore comment détecter ça, mais je sais que c'est logiciellement détectable, une ancienne bibliothèque maintenant obsolète le faisait. Ça pourrait aussi être cool de pouvoir se (dé)connecter avec des requêtes, mais ça risque plutôt de demander un programme dédié.
Cette section regroupe quatre types de trucs qui peuvent être listés par la commande « acpi ». La bibliothèque utilise plutôt les fichiés exposés dans /sys/class pour obtenir ses informations, mais, comme ceci est a priori une spécificité du noyau Linux, la commande « acpi » peut également être utilisée comme roue de secours si les répertoires concernés n'ont pas l'air présents. Sur Linux, donc, la plupart des valeurs mentionnées ci-dessous sont lues et parsées depuis les fichiers de même nom, mais n'ayant pas trouvé de doc spécifique, j'ai cherché un peu à l'aveugle ceux qui semblaient vaguement utiles.
« system/ac0 » permet d'interagir avec l'alimentation de la machine (qui n'a d'ailleurs pas de numéro dans /sys/, mais elle en a un avec acpi, donc j'en ai mis un au cas où). Elle présente trois clefs, « present » (booléen, seul élément listé par acpi), « hid » et « type ». Les différentes batteries, accessibles par « system/batteryX », ont un peu plus de données : « present », « status » (charging, discharging ou full, repris en état), « percent » (pourcentage de charge), « charge » (charge actuelle, visiblement en microampères), « full » (dernière charge complète) et « design » (charge complète à la conception), « manufacturer », « technology », « serial », « hid » et « type ». TODO : la commande ACPI fournit aussi une estimation du temps avant décharge, même si très variable, mais je n'ai pas trouvé comment déterminer ça depuis /sys/class.
« system/thermalX » permet d'accéder aux capteurs de températures, dont on peut obtenir la température actuelle avec la clef « temp » (en degrés celsius et en nombre flottant), mais également un « mode » (qui vaut présentement « enabled » chez moi), un « type » (qui semble indiquer sur quel composant se fait la captation, peut-être ?), et une « policy ». Une clef « choices » présente un frozenset des différentes policy disponibles, mais je ne sais pas s'il est possible d'en changer. Enfin, « system/coolingX » permet d'accéder aux dispositifs de refroidissements, qui possent un « type », mais également des états (« state » pour l'état actuel et « max » pour l'état maximal, visiblement des entiers).
Il n'y a pour l'instant aucune icône particulière pour les refroidissements, et l'alimentation a l'icône « ac-adapter » du thème. En revanche, les batteries et les capteurs de température ont droit à des icônes spécialisées montrant leur état actuel, comme détaillé dans le module concerné.
La bibliothèque psutil, si elle est présente, permet également d'obtenir des informations sur les différents processeurs (qui ne sont pas listées si cette bibliothèque n'est pas disponible. Il s'agit de « trucs » plutôt simples, listant les informations suivantes :
Enfin, les processus du système sont accessibles avec un chemin de type « system/PID », où PID est leur numéro. Il est possible de récupérer tous les processus actifs d'un coup avec le stuff « system/process ». Cependant, les processus ne sont pas des enfants du système, ayant leur propre arborescence (dont la racine est « system/1 »).
Un processus expose autant que possible des clefs suivantes : « pid » (entier), « command » (tuple des arguments du programme, le premier correspondant généralement à l'exécutable), « name » (nom du programme appelé), « exe » (adresse absolue de l'exécutable), « path » (répertoire de travail actuel), « status » (état, également exposé en état du truc), « user » (nom d'utilisateur), « cpu » (entier indiquant sur quel processeur le programme tourne), « terminal » (PTY associé au programme, ou None), « load » (pourcentage de charge), « memory » (pourcentage de mémoire utilisée), « threads » (nombre de threads), « files » (nombre de fichiers ouverts), « environ » (frozendict contenant les variables d'environnements).
Il est possible d'utiliser une requête pour envoyer un signal à un processus. Celle-ci doit débuter par « signal: », puis indiquer soit le numéro (par exemple, « signal:15 ») soit le nom du signal (par exemple, « signal:term » ou « signal:SIGTERM », la casse n'est pas prise en compte). On peut également utiliser une requête « reicon:X » pour associer une icône spécifique au nom du processus (par défaut, si ce nom correspond à une icône du thème, celle-ci est utilisée, sinon on utilise « gtk-execute » qui présente généralement des engrenages).
Évidemment, si la bibliothèque psutil est présente, c'est elle qui sert à lire les informations sur les processus. Dans le cas contraire, j'ai tenté autant que possible de récupérer les mêmes informations en allant lire les fichiers dans /proc/PID, même si certaines des informations présentes dans ces répertoires semblent être des spécifictés du noyau Linux.