Ajouter d'une fonctionnalité : suppression des anciennes notifications ou configuration d'un nombre maximum de notifications

[Odecam1]

Peut-on faire en sorte que dans le -c ou --check, les anciennes notifications soient supprimées avant d'envoyer la nouvelle ? Ou dans .conf/arch-update/arch-update, mettre une configuration possible avec un nom comme max-notifications pour paramétrer cela, et si la variable n'existe pas, garder le même comportement qu'auparavant.

[Antiz96]

Hello,

Il n'est pas possible pour Arch-Update d'agir sur le nombre maximum de notifications à envoyer et il ne peut pas non plus supprimer d'anciennes notifications déjà envoyées (du moins à ma connaissance).

Cependant, le -c/--check n'envoie une notification que s'il y a une (ou plusieurs) nouvelle mise à jour disponible depuis le dernier check. Ainsi, le nombre de notifications envoyées par Arch-Update ne devrait théoriquement pas être trop conséquent.

En revanche, si jamais vous trouvez que le check une fois par heure génère trop de notifications malgré cela, il est possible de modifier le cycle de vérification automatique.

Exemple, pour passer à un check par jour:

systemctl --user edit arch-update.timer

Puis insérer ce qui suit dans le fichier:

[Timer]
OnUnitActiveSec=
OnUnitActiveSec=1d

[Odecam1]

Ok merci.
Je vais essayer de voir par moi-même s'il est quand même possible de le faire sans installer de paquet supplémentaire

[Antiz96]

Ok merci. Je vais essayer de voir par moi-même s'il est quand même possible de le faire sans installer de paquet supplémentaire

Pour être tout à fait honnête, je ne suis pas certains de comprendre ce que vous cherchez à accomplir ou l'éventuel "problème" que vous cherchez à corriger. Si vous faites référence à l'historique des notifications qui est stocké dans le "centre de notifications" de votre environnement de bureau, c'est une chose totalement séparée et complètement indépendante d'Arch-Update.

Arch-Update ne fait qu'envoyer une notification si une ou plusieurs nouvelle(s) mise(s) à jour est/sont disponible(s) lors du check. Au niveau d'Arch-Update, il n'y a aucune notion d'historique ou de potentiel "nombre maximum" pour les notifications. Ce n'est qu'un envoie ponctuel de notification (via la commande notify-send). Il n'y a aucune possibilité pour Arch-Update d'être conscient des notifications envoyées par le passé, et par conséquent aucune possibilité non plus d'agir sur ces dernières (du moins à ma connaissance).

Si vous cherchez "à faire le tri" dans l'historique de notifications stockées dans le centre de notification de votre environnement de bureau lors de la réception d'une nouvelle notification, cela devra se gérer au niveau de celui-ci et sera propre à votre environnement de bureau (et votre configuration). En résumé, si j'ai bien compris ce que vous cherchez à accomplir, c'est quelque chose qui ne peut se gérer au niveau d'Arch-Update lui même (à ma connaissance) mais qui doit se gérer au niveau de votre environnement de bureau/centre de notifications.

Mais peut-être ai-je mal interprété votre requête?

[Odecam1]

Ce que je cherche réellement à faire, c'est d'avoir seulement une notification pour Arch-Update, car seule la dernière notification est utile pour moi. Il m'arrive parfois de laisser mon PC allumé toute la nuit, et je me retrouve envahi de notifications d'Arch-Update lorsque je me réveille.

[Antiz96]

D'accord, merci pour la précision :)

Dans ce cas, je confirme qu'il n'est pas possible pour Arch-Update d'intervenir ou de supprimer les précédentes notifications au profit de la dernière en date uniquement (du moins pas à ma connaissance, mais si vous trouvez une manière propre et simple de le faire, n'hésitez pas à me la partager afin que je puisse considérer l'ajouter).

Comme proposé plus haut, vous pouvez augmenter le cycle de vérification automatique des mises à jours comme solution de contournement.
En passant le cycle de vérification à 8 heures (par exemple), le check ne sera effectué qu'une fois durant la nuit et vous ne recevrez donc qu'une notification.
Il doit même être possible de paramétrer le cycle du timer systemd pour que le check soit lancé toutes les heures en journée et seulement une fois toutes les X heures la nuit par exemple (afin de conserver un check régulier en journée et éviter les trop nombreuses notifications la nuit lorsque vous laissez votre PC allumé). Je vous laisse vous référer à cette documentation pour plus de détails.

[Odecam1]

Merci pour toutes ces informations.
Je vais voir de mon côté s'il est possible de seulement garder la dernière notification et, si possible, de l'ajouter à votre script.
Mais sinon, comme solution de contournement, cela me va.
Je vais également voir pour paramétrer le cycle du timer systemd.

[Odecam1]

Je pense avoir trouvé une solution, mais je ne suis pas sûr si c'est la plus propre et la plus simple.

Lorsque l'on crée une notification, on utilise notify-send -p "Le Titre" "Le Contenu". Le paramètre -p est utilisé pour obtenir l'identifiant de la notification (il faut le stocker).

Ensuite, pour supprimer la notification, on utilise dbus-send --session --dest=org.freedesktop.Notifications --type=method_call /org/freedesktop/Notifications org.freedesktop.Notifications.CloseNotification uint32:${ID_Notification}. Cette méthode fonctionne avec les environnements de bureau GNOME mais je n'ai pas tester avec les autres. Je peux vous expliquer plus en détaille cette commande si vous le souhaitez.

Je ne pense pas que ce soit très simple, mais il est possible de résoudre cela avec ces deux commandes. Si vous le souhaitez, je peux essayer de modifier la fonction check et l'envoyer dans cette issue.

[Antiz96]

Merci beaucoup pour la recherche et pour la piste d'implémentation !

J'étais dubitatif quant au fait qu'il soit possible d'influer sur des notifications précédemment envoyées au niveau d'Arch-Update mais la méthode que vous mentionnez semble fonctionner correctement et sur tout environnement de bureau à priori. Veuillez m'excuser 🙂

J'ai ré-ouvert ce ticket et je travaillerai à l'implémentation de cette méthode pour les notifications prochainement. J'ai une idée claire de son intégration au niveau d'Arch-Update, cela devrait être relativement simple et trivial.

Bien sûr, si vous souhaitez essayer de modifier vous-même la fonction check en conséquence et ouvrir une pull request, faites moi signe et je vous laisse la main avec plaisir 😉

[Antiz96]

En fouillant la man page de notify-send, j'ai trouvé l'option -r/--replace-id qui permet de remplacer une notification précédemment envoyée via son ID. Cela me semble être la solution la plus propre et simple puisque ça évite l'étape supplémentaire de devoir supprimer la notification précédente au préalable via un appel dbus.

J'ajouterai ceci dans le script prochainement 😉

[Odecam1]

J'aimerais savoir comment vous envisagez d'implémenter cette fonctionnalité : préférez-vous l'approche via une configuration externe comme je l'ai proposé, ou préférez-vous l'intégrer directement dans le script ? Personnellement, les deux options me conviennent.

En effectuant des recherches sur les notifications, j'ai découvert que l'identifiant revient à 0 à chaque redémarrage et que les notifications sont également supprimées à chaque redémarrage, du moins sur GNOME

[Antiz96]

J'aimerais savoir comment vous envisagez d'implémenter cette fonctionnalité : préférez-vous l'approche via une configuration externe comme je l'ai proposé, ou préférez-vous l'intégrer directement dans le script ? Personnellement, les deux options me conviennent.

Après réflexion, ce comportement (remplacer la notification précédente) me semble être le plus pertinent. Je préfère donc l'intégrer directement au script comme comportement par défaut.

En effectuant des recherches sur les notifications, j'ai découvert que l'identifiant revient à 0 à chaque redémarrage et que les notifications sont également supprimées à chaque redémarrage, du moins sur GNOME

En effet, j'avais remarqué ceci également. Ce sera bien pris en compte dans l'intégration au script.

[Antiz96]

Fonctionnalité ajoutée au script via #134 et incluse dans la nouvelle version 1.14.1. 😉

Comme écrit dans les "release notes" de la version 1.14.1, merci beaucoup pour la suggestion et les recherches d'implémentation ! 🙂

[Odecam1]

Merci beaucoup pour cette ajout, cela va grandement m'aider.

Cependant, cela n'a rien à voir avec cet issue. Je suis en train de travailler pour déterminer s'il est possible de factoriser la partie "# Checking options in arch-update.conf" et comment le faire.