Bouton de fermeture sur notify-osd ?

J'ai déjà lu à ce sujet et je comprends la logique de conception, mais en pratique, ils sont gênants lorsqu'ils ne peuvent pas être facilement effacés.

En utilisant https://launchpad.net/caffeine, une application de barre d'état qui peut empêcher l'économie d'énergie/de l'écran, désactivera également les popups, donc j'ai pensé suggérer cela comme solution de contournement.

Le blocage de la notification met en lumière le besoin d'un historique des notifications, mais cela a également été soulevé comme un problème résolu par la non-réparation : bugs.launchpad.net/notify-osd/+bug/382094

Diminuez le délai avec l'application notify-osd-conf.

Signet: Bouton de fermeture sur notify-osd?

réf:

• https://askubuntu.com/a/31617/89468
• https://askubuntu.com/a/14356/89468

Concepts prêts à être prouvés, le graffiti pop-up OSD "désactivé" codé en bash est imaginé et conçu comme suit:

dbus-monitor "interface='org.freedesktop.Notifications'" |             \
grep --line-buffered "member=Notify"                     |             \
sed -u -e  's/.*/killall notify-osd/g'                   |             \
bash

Ceci peut être exécuté dans un terminal ou en tâche de fond - arrêtez-le et le graffiti pop-up reprend.

L'auteur a déclaré "Non, je ne peux pas le désactiver". Si cela signifie que le système de notification NE DOIT PAS être désactivé par le demandeur, alors cette solution est cohérente avec cela. Le système est intact. Si cela signifie que le demandeur ne sait pas comment le faire, alors encore une fois la solution est pertinente.

Détails expliqués ci-dessous. L'idéal serait d'intégrer tout sur le DBus, pour invoquer directement

  qdbus    org.freedesktop.Notifications                \
          /org/freedesktop/Notifications                \
           org.freedesktop.Notifications.CloseNotification(uint id)

Une solution très, très, très naïve et rudimentaire, qui est plus une preuve de concept qu'une solution pratique, "désactive" essentiellement notify-osd (ou du moins ses effets). N'oubliez pas de le terminer lorsque vous avez fini de le tester! en appuyant sur -C ou en fermant la fenêtre du terminal etc. Il fait son travail mais pas de manière très pragmatique! puisque malheureusement d'autres tâches souffrent en essayant de faire les leurs ...

  while true; do killall notify-osd; done

(pour "entendre" une activité pertinente vous pouvez vouloir "greper" dehors

 notify-osd: no process found ....

)

Testez-le en l'exécutant dans une fenêtre de terminal et depuis une autre fenêtre de terminal essayez de faire:

  notify-send "test 1" "maintenant vous le voyez pas"
  notify-send "test 2" "vous ne le voyez plus après que le test 1 ait disparu"
  notify-send "test 3" "enfin après que le test 2 ait disparu"

Arrêtez le premier processus et essayez à nouveau les messages.

Peut-être qu'un indicateur notify-osd pour le unity-panel-service pourrait invoquer killall notify-osd. Le bouton de fermeture activé à chaud ne sera pas (et ne peut pas être!) présent sur la fenêtre de notification mais il sera disponible sur le panneau de l'indicateur. Cela est complètement analogue au même concept qu'Unity a pour les fenêtres. L'utilisation de la barre supérieure pour fermer les notifications est similaire à la manière dont Unity exlut les menus des fenêtres avec des boutons de fermeture, réduction, agrandissement vers la barre de menu supérieure.

Une solution vraiment élégante ferait apparaître l'indicateur lorsque l'activité DBus pour le notify-osd se manifeste et disparaît lorsqu'il n'y a pas de notifications en attente.

Cela pourrait également résoudre le problème des notifications empilées - une seule peut être vue à la fois et si plusieurs notifications sont en attente, chacune doit disparaître avant que la suivante n'apparaisse - elles ne peuvent généralement pas être vues simultanément.

La surveillance DBus de l'interface de notification notify-osd fournira cependant une reconnaissance immédiate des avis en attente même s'il y en a déjà un qui s'affiche. (ET si killall notify-osd est émis immédiatement - presto poof!)

Sélectionnez Tout, Faites glisser et Déposez dans une fenêtre de terminal les tests suivants:

  notify-send "test 1" "maintenant vous le voyez"
  notify-send "test 2" "vous le voyez après que le test 1 ait disparu"
  notify-send "test 3" "enfin après que le test 2 ait disparu"

faisons maintenant la même chose avec la preuve:

  notify-send "test 1" "maintenant vous ne voyez pas"
  notify-send "test 2" "vous le voyez pas! après que le test 1 ait disparu"
  notify-send "test 3" "PAS enfin après que le test 2 ait disparu"
  killall notify-osd
  notify-send "gonzo" "parti nada zip zéro"

Le killall notify-osd dans la solution suggérée serait déclenché lorsque le DBus monitor détecte l'activité des graffitis pop-up OSD.

Essayer ceci:

http://www.webupd8.org/2012/06/closable-movable-notifyosd.html

Vous n'aurez pas de bouton de fermeture, mais vous pourrez fermer la bulle et ajuster le temps pendant lequel elle est active.

C'était une décision délibérée de laisser de côté toute possibilité d'interagir avec la bulle de notification (il s'agit donc d'une notification passive), vous pouvez donc soumettre un rapport de bug sur Launchpad (il y en a peut-être déjà un) et faire pression pour que cela soit modifié.

Ce n'est pas quelque chose que je vois se produire bientôt à moins d'une demande importante (et ce n'est pas le cas).

Il pourrait également être utile d'essayer de résoudre le problème en demandant un moyen d'exclure certains programmes d'accéder au système de notification notify-osd.