Bug 1213392 - All notifications are persistent in GNOME
Summary: All notifications are persistent in GNOME
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-shell
Version: 23
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Owen Taylor
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-04-20 13:01 UTC by Martin Kyral
Modified: 2016-05-25 09:58 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-25 09:58:48 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Martin Kyral 2015-04-20 13:01:29 UTC
Description of problem:
I am unable to create non-persistent notifications in GNOME. Non persistent means that only the banner pops-up but the notification won't stay in the overview after the banner closes due to timeout.

Easily reproducible by notify-send:
(1) notify-send -t 0 aaa bbb ---> timeout 0 means persistent per the specification -> banner shows and if the timeout misses, the notification resides in the overview
(2) notify-send -t 1 aaa bbb ---> timeout explicitly defined which means the user (or application developer) wants the notification to perish after the timeout -> banner shows and if the timeout misses, the notification resides in the overview
(3) notify-send aaa bbb ---> no timeout specified  -> banner shows and if the default timeout misses, the notification resides in the overview

while in KDE:
(1) notify-send -t 0 aaa bbb ---> timeout 0 means persistent per the specification -> pop-up shows and if the timeout misses, the notification resides in the overview
(2) notify-send -t 1 aaa bbb ---> timeout explicitly defined which means the user (or application developer) wants the notification to perish after the timeout -> pop-up shows and if the timeout misses, the notification perishes
(3) notify-send aaa bbb ---> no timeout specified  -> pop-up shows and if the timeout misses, the notification perishes

While I believe case (3) is up to the DE developers to set the sane default, I am strongly convinced that if the timeout is explicitly requested (2), DE must obey it and make the notification non-persistent.

Version-Release number of selected component (if applicable):
gnome-shell-3.16.0-1.fc22

Comment 1 Andrea Vai 2016-05-25 07:44:05 UTC
Same behaviour in gnome-shell 3.18.5 (Fedora 23), and also

notify-send -t 0 aaa bbb
notify-send -t 1000 aaa bbb
notify-send -t 10000 aaa bbb
notify-send -t 100000 aaa bbb

all of them give the same result (notification popup shows for some seconds, then disappears)

Comment 2 Florian Müllner 2016-05-25 09:58:48 UTC
This is intentional:
https://wiki.gnome.org/Design/OS/Notifications/#Non-Goals

The notification timeout has not been configurable in GNOME since gnome-shell 3.0, you would need to convince upstream designers to change that. But note that there have been two major redesigns to address various issues with previous iterations, where a user/app specified timeout never came up - so chances to bring them back after five years are rather slim.


Note You need to log in before you can comment on or make changes to this bug.