-- Leo's gemini proxy
-- Connecting to unbon.cafe:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini;
Entre la croyance populaire et la micro-optimisation, j'ai choisi de sortir le niveau audio et de rétro-éclairage de ma barre d'état pour seulement les afficher lors de modifications de valeurs. Non seulement pour créer (encore) de l'espace (libre d'information) sur mon écran (pour quoi faire ?), mais cela pourrait théoriqument réduire la consommation d'énergie du système. Le résultat se trouve dans mes dotfiles[dot] via deux scripts du dossier `/bin` associés à des combinaisons définies dans `.config/sway/config`.
La barre d'état, ou de statut, `swaybar` est fournie de base avec `swaywm`. Elle s'affiche sous la forme d'une barre mise à jour à chaque seconde (par défaut) et pouvant contenir différentes informations. Dans mes dotfiles, on trouve ainsi le fichier `.config/sway/config` qui appelle `.config/sway/status.sh` pour les informations au sein d'une boucle.
Ma configuration bien que fonctionnelle me dérangeait, d'une part via la présence constante de ces informations qui n'ont pas vocation à changer sans mon intervention (sans parler de la valeur de luminosité qui n'est pas un multiple de 5 de par un seuil limite que j'ai défini à 1 %), mais plus généralement qui n'ont pas vocation à changer régulièrement. Que le système aille chercher ces valeurs toutes les secondes m'irritait au plus haut point en me disant que c'était des ressources dans le vent.
La solution la plus simple serait de modifier la valeur de `sleep` pour réduire le nombre d'appels des informations. Cela a malheureusement pour inconvénient de perdre le retour instantané des modifications à l'écran qui peut être utile pour garder le compte sur les valeurs.
La seconde solution sur laquelle je me suis orienté est un déplacement vers les notifications. Celles-ci ont naturellement pour vocation la fonction de retour d'information en temps-réel, et disparaissent. Juste ce qu'il me faut. Des solutions toutes faites existent (sûrement), j'ai choisi d'expérimenter en associant des combinaisons de touche vers `notify-send` en réutilisant la configuration de ma barre d'état.
Même si l'information est importante, je lui ai donné une faible priorité par rapport à d'autres notifications potentielles (option `-u low` pour `notify-send`).
Pour la même raison, j'ai réduit le temps par défaut de la notification par rapport aux autres du système (défini via `mako` à 5 secondes) à 1000 ms (option `-t 1000`).
La luminosité est obtenue via `brightnessctl -m | awk -F, '{print $4}'`, qui récupère la 4ème des valeurs séparées par des virgules dans la sortie demandée.
Le volume est obtenu via `pulsemixer --get-volume | awk '{print $1}'`, qui sélectionne la valeur de la première sortie audio (mes enceintes gauche et droite étant de niveau équivalent).
La valeur est associée à une variable qui est aisément appelé via `notify-send`.
audio_state=$(pulsemixer --get-mute) if [ $audio_state = "1" ]; then audio_icon='🔇' else audio_icon='🔈' fi
Bien qu'ayant une DEL sur mon clavier m'indiquant l'état des enceintes, cela reste un petit détail qui fait son effet de pouvoir voir son état directement sur l'écran. Mon script en fait ainsi la demande et associe un symbole unicode selon l'état – l'utilisation d'un symbole réduit la dépendance à un jeu d'icônes.
Par défaut, et lié aux réglages de `mako`, les notifications affichaient comme titre `notify-send` ce qui n'est pas des plus esthétiques. Cela peut-être modifié via l'argument `--app-name` pour un titre personnalisé.
En l'état, les scripts fonctionnent et affichent les valeurs demandées en notification lorsque les touches de modification sont pressées. Deux éléments pourraient être améliorés pour plus de confort :
Ajouter une barre pour un design plus usuel. Je ne sais pas encore comment cela se ferait, j'ai cru voir des `seq` se balader ;
Implémenter un « flood-control » pour remplacer les notifications similaires. Lorsque les scripts sont appelés plusieurs fois cela crée plusieurs notifications là où une seule suffirait. La solution serait d'attribuer un identifiant aux notifications issues de ces scripts et de pouvoir les cibler. Cela semble exister sous `notify-send` via les options `-p`, `-r`, et `-h`, mais pour une raison qui m'échappe ne marche pas pour moi.
Plus généralement vient la question de la combinaison de touches, où doit-elle être définie ?
---
-- Response ended
-- Page fetched on Sun May 19 03:19:07 2024