61

Maybe I'm doing something wrong, but shouldn't the commands (run separately)

notify-send -t 1 "test"
notify-send -t 1000 "test"
notify-send -t 10000 "test"

have different timeouts? The first being nearly instantaneous, the second taking 1 sec and the third 10 seconds? In all cases it seems to take about six seconds for me.

Is there a way around this behaviour? As the developers label this as a "feature" instead of a bug, I would like some alternatives.

BeastOfCaerbannog
  • 16,703
Hooked
  • 2,362

8 Answers8

55

This is a known bug: https://bugs.launchpad.net/ubuntu/+source/notify-osd/+bug/390508

(It is considered a 'design decision' by the maintainer.)

Boris Bukh
  • 751
24

As mentioned in one of the posts above, there is a design decision to disallow this feature. Fortunately for you, other people disagree as well and have set up a PPA and you can reverse this decision for your system as well.

To solve your problem just:

sudo add-apt-repository ppa:leolik/leolik 
sudo apt-get update
sudo apt-get dist-upgrade
sudo apt-get install libnotify-bin
pkill notify-osd

Optional

To add even more features to send-notify than you currently have:

From Ubuntu 16.04 onwards:

sudo add-apt-repository ppa:nilarimogard/webupd8
sudo apt update
sudo apt install notifyosdconfig

For versions 9.10-14.10:

sudo add-apt-repository ppa:amandeepgrewal/notifyosdconfig
sudo apt-get update
sudo apt-get install notifyosdconfig

For more information on the solution above, read this article:

Configurable Notification Bubbles for Ubuntu

Fabby
  • 35,017
4

This was an intentionally implemented contravention of established conventions without disqualification in the host terminal environment. ie. notify-send should no longer exist since it compromises the well-established expected and documented functionality, so instead, a new command notify-graffiti should now exist - What???? Wait a second ... all those scripts that use the "conventional" command name spelling will be compromised!?! by changing the convention of how the command name is spelled?!?! - hmmm This philosophy is exceptionally, paradoxically hypocritical as espoused by the Unity desktop terminal interface.

It can't be done both ways - preserving some conventions ie. the name of a command and yet not others, the functionality of a command as documented. If the functionality is to be compromised then so too should the command name so as to maintain integrity, conventionality, consistency, etc. of the user "experience", or is that user "frustration", "annoyance", "irritation", ...

ref:

Bookmark:
Notify-send ignores timeout?

Community
  • 1
George Rowell
  • 202
4

There is a small handy script notify-send.sh as a drop-in replacement for notify-send that enables you to close or replace previously sent notifications.

Edit: as @Glutanimate pointed out, this script supports expiration-time by default.

I couldn't get expiration-time to work in the end, so I went rather a hacky way to send a notification with 2 seconds timeout like this:

notify-send.sh --print-id test | xargs -I {} bash -c "sleep 2 && notify-send.sh --close={}" &
Zanna
  • 72,312
NiMa Thr
  • 361
2

This is in milliseconds. I tested on XUbuntu 16.04 (Ubuntu XFCE)

notify-send -t 3000 "test"

exactly 3 seconds

Zanna
  • 72,312
Pawel Cioch
  • 166
2

Yes, if you use notify-send -u critical -t 0 the notification will stay on the screen until you click it.

quoted from this answer

zheyuanWang
  • 131
  • 3
1

For those using the Cinnamon desktop environment, there's a setting that can be enabled:

Notifications > Remove notifications after their timeout is reached

Zanna
  • 72,312
Shai Coleman
  • 113
0

You can also use gdbus directly

gdbus call \
        --session \
        --dest org.freedesktop.Notifications \
        --object-path /org/freedesktop/Notifications \
        --method org.freedesktop.Notifications.Notify \
        "App_name" 0 "audio-headphones" "Title" "Message" '[]' '{}' 5000 \
    | sed -E 's/.uint32 ([0-9]+).*/\1/' \
    | xargs -I{notification_id} sh -c 'sleep 1 && gdbus call \
        --session \
        --dest org.freedesktop.Notifications \
        --object-path /org/freedesktop/Notifications \
        --method org.freedesktop.Notifications.CloseNotification {notification_id}'

I also made this function that additionally allows to update the notification, and refreshes the timeout

notify() {
    local app_name="$1"
    local title="$2"
    local message="$3"
    local duration="$4"
    local notification_file="/tmp/${app_name}_notification_id"
    local timer_file="/tmp/${app_name}_timer_pid"

# Read existing notification_id if available
local notification_id=0
[ -f "$notification_file" ] && notification_id=$(cat "$notification_file")

# Cancel previous timer if it exists
if [ -f "$timer_file" ]; then
    kill $(cat "$timer_file") 2>/dev/null
    rm "$timer_file"
fi

# Send notification and save new id
new_id=$(gdbus call \
    --session \
    --dest org.freedesktop.Notifications \
    --object-path /org/freedesktop/Notifications \
    --method org.freedesktop.Notifications.Notify \
    "$app_name" "$notification_id" "audio-headphones" "$title" "$message" '[]' '{}' "$duration" \
    | sed -E 's/.uint32 ([0-9]+).*/\1/')

echo "$new_id" > "$notification_file"

# Schedule closing of notification
(
    sleep "$duration" 
    gdbus call \
        --session \
        --dest org.freedesktop.Notifications \
        --object-path /org/freedesktop/Notifications \
        --method org.freedesktop.Notifications.CloseNotification "$new_id"
    rm "$timer_file"
) & 
echo $! > "$timer_file"



}

Usage:

notify "App_name" "Title" "Message" 5000

As long as you use the same App_name the notification will be updated.

Madacol
  • 518