Close button on notify-osd?

The choice to have zero chrome on the ephemeral notifications is very deliberate and not going to change. The rationale is that these notifications should be as lightweight as possible.

However, there are some things that could be done to help you further.

There is a spec to make the timing of the notification variable - longer messages would stay for a longer time, or updated messages would be extended. A patch implementing that would be welcome, it would allow us to shorten the time for very short messages :-)

Also, we would like to add a "do not disturb" mode, where only system (urgent) notifications, like battery very low and hardware problems, would show up. So you could use do-not-disturb to avoid people seeing your notifications when they are looking over your shoulder, or you are plugged in to the projector (though we'd rather put the notifications on your laptop screen and not on the projector, where they are different displays). Again, a patch for that would be welcome.

Your best bet would be file a bug and ask for the feature. When filing a wishlist bug like this, be sure to give some thought out user cases why this feature could prove to be useful for a larger section of the Ubuntu user community.

There isn't a close button, the blob isn't even there in terms on the mouse (when you click over it, it simply clicks what ever is behind it), see details here:

https://wiki.ubuntu.com/NotifyOSD

This functionality won't change, there have been several bug reports asking for what your asking for, all of which have been denied in the strongest of terms.

You could make a program to close it though, fork the osd code a bit and use some of the existing code branches which do this already. See the program D-Feet to browse and play with the dbus interface for notifyosd and the code on launchpad.

There is a way you can get notifications with a close button.

From Webupd8's Article

First install Avant Window Navigator from the software center and add the "Notification Daemon" to the dock.

Now press Alt + F2 and paste gconf-editor

Then navigate to apps > awn-applet-notification-daemon (this is for the latest AWN from the AWN trunk PPA, it may be apps > avant-window-navigator > awn-applet-notification-daemon on older versions of Avant Window Navigator). Clicking a key will display its description at the bottom so you'll know how to tweak it. The most important key is: "kill_standard_daemon" - make sure this is enabled or else the AWN notifications won't work.

For instance, "override_x" is the horizontal position on the screen (for which I've used "1900" because my screen width is 1920 and I want the notifications to be displayed on the right), "override_y" is the vertical position (for which I've used "30" so the notification dialog is displayed in the top right corner) and "gradient_factor" is the transparency. That should be enough to get you started.

To customize the colors, uncheck the "use_theme" box, then specify a "text_colour" and "bg_colour" and so on.

An important feature you may want to turn on is "show_icon". This will display an icon on your Avant Window Navigator dock which you can then click to temporarily disable/enable the notifications.

Instead of using avant window navigator, you could also do this (only tested on Lucid):

Install xfce4-notifyd from the software center and press Alt + F2 and paste killall notify-osd

This switches to XFCE's notify daemon, which looks a lot like the default one, only a close button appears when you hover over it.

I have read about this before and can understand the design reasoning but in practice they are distracting when they cannot be cleared easily.

Using https://launchpad.net/caffeine, a statusbar app which can prevent screen/power saving, will also disable the popups so I thought I would suggest this as a workaround.

Blocking the notification does highlight the need for a notifications history but this has also been raised as an issue and resolved as wont fix: bugs.launchpad.net/notify-osd/+bug/382094

Decrease the delay with notify-osd-conf app.

Bookmark: Close button on notify-osd?

ref:

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

Concepts presto proven, bash'd OSD pop-up graffiti "disabled" solution is conceived and hatched as:

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

This can be run in a terminal or as a background task - stop it and pop-up graffiti resumes.

The OP stated "No, I can't disable it". If by this it means that the notification system IS NOT to be disabled by the poser, then this solution is consistent with that. The system is intact. If it means the poser does not know how to do so, then again the solution is pertinent.

Details explained below line. The ultimate would be to embed everything on (in?) the DBus, to directly invoke

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

A very, very, very naive rudimentary solution, that is more proof of concept than practical, essentially "disables" notify-osd (or at least its effects). Don't forget to terminate it when done testing! by ETX'ng with <ctrl>-C or closing the terminal window etc. It does do its job but not very pragmatically! since unfortunately other jobs suffer trying to do theirs ...

  while true; do killall notify-osd; done

(to "hear" relevant activity you might want to "grep out"

 notify-osd: no process found ....

)

Test it by running it in a terminal window and from another terminal window try doing:

  notify-send "test 1" "now you see it not"
  notify-send "test 2" "you see it not after test 1 evaporates"
  notify-send "test 3" "finally after test 2 evaporates"

Stop the first process and then try the messages again.

Perhaps a notify-osd indicator for the unity-panel-service could invoke killall notify-osd. The hot spotted close button wouldn't (& can not!) be resident on the notification window but it would be available on the indicator panel. This is completely analagous to the same concept that Unity has for windows. The use of the top bar for notification closing is similar to the way Unity exiles window menus with close, mini, maxi boxes to the top menu bar.

A truly elegant solution would have the indicator appear when DBus activity for the notify-osd manifests and disappear when there are no pending notifications.

It might also address the problem of stacked notifications - only one can be seen at a time and if multiple notifications are pending each one must evaporate before the next appears - they cannot usually be seen simultaneously.

DBus-monitor'ng of the notify-osd notification interface will however provide immediate acknowledgement of pending notices even if there is one already showing. (AND if killall notify-osd is issued immediately - presto poof!)

Select All, Drag & Drop to a terminal window the following tests:

  notify-send "test 1" "now you see it"
  notify-send "test 2" "you see it after test 1 evaporates"
  notify-send "test 3" "finally after test 2 evaporates"

now do the same with p{r}oof:

  notify-send "test 1" "now you don't"
  notify-send "test 2" "you see it not! after test 1 evaporates"
  notify-send "test 3" "NOT finally after test 2 evaporates"
  killall notify-osd
  notify-send "gonzo" "gone nada zip zilch"

The killall notify-osd in the suggested solution would be triggered when DBus monitor detects OSD pop-up graffiti activity.

Try this:

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

You won't get a close button, but you'll be able to close the bubble and adjust the time it is active.

It was a deliberate decision to leave out any way to interact with the notification bubble (so its a passive notification), so you can post a bug report on Launchpad (there may be one already) and lobby for it to be changed.

Its not something I can see happening soon unless there's major demand (and there isn't)

It might also be worth trying to tackle the issue by asking for a way to exclude certain programs from accessing the notify-osd system.