Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

Is it possible to get a close button on the OSD?

It stays for a long time, and sometimes I have colleagues over on my PC, and I dont want them seeing who is online, or what song I am listening to. No, I can't disable it.

share|improve this question
    
The only workaround to get a close button on the notification, is to use AWN, and use the notification plugin. It works well with Rhythmbox and exaile too. –  theTuxRacer Feb 12 '11 at 12:06
    
This answer askubuntu.com/questions/14354/close-button-on-notify-osd/… basically preempts notification display. It is temporary and if this process is stopped, notification display resumes. If by "I can't disable it" is meant that you are not at liberty to disable the notification dbus mechanism, this solution leaves it intact ... if it means you've tried and been unable to do so, again this answer will provide a solution. –  George Rowell Sep 29 '12 at 2:42
add comment

11 Answers

up vote 14 down vote accepted

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.

share|improve this answer
    
yeah, i will do that. But where can I do that? Launchpad? –  theTuxRacer Nov 22 '10 at 6:43
1  
its already on the wishlist, but action wont be taken, i think. please vote bugs.launchpad.net/ubuntu/+source/notify-osd/+bug/381416 –  theTuxRacer Nov 22 '10 at 10:50
6  
@Kaustubh P Read this, markshuttleworth.com/archives/253 specifically this part: The most controversial part of the proposal is the idea that notifications should not have actions associated with them. In other words, no buttons, sliders, links, or even a dismissal [x]. Don't get your hopes up, this won't be changing anytime soon if ever. –  Alvin Row Nov 22 '10 at 16:43
1  
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 :-) –  Mark Shuttleworth Nov 23 '10 at 10:34
9  
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. –  Mark Shuttleworth Nov 23 '10 at 10:36
add comment

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.

share|improve this answer
    
wow, thanks for the answer! I guess I might cry! –  theTuxRacer Nov 23 '10 at 11:17
4  
I hope this "do not disturb" mode is implemented then. –  Roddie Nov 23 '10 at 14:23
    
For this urgent notifications system, there should be a way to differentiate which notifications gets to be categorised as urgent. –  Oxwivi Mar 19 '11 at 9:44
    
I don't agree with these decisions 100%, but at least they seem to be working well. –  RolandiXor Sep 17 '12 at 22:36
    
I'd try to look into the source code and submit the patch (if possible). –  green7 Sep 18 '12 at 14:56
add comment

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.

share|improve this answer
    
And bind that program to hotkey, right? –  Extender Nov 22 '10 at 4:01
    
its already on the wishlist, but action wont be taken, i think. please vote bugs.launchpad.net/ubuntu/+source/notify-osd/+bug/381416 –  theTuxRacer Nov 23 '10 at 3:23
    
This answer askubuntu.com/questions/14354/close-button-on-notify-osd/… basically preempts notifications and though not actually disabled, their display is. It is temporary and if this process is stopped, notification display resumes. –  George Rowell Sep 29 '12 at 2:32
add comment

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

enter image description here

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.

share|improve this answer
1  
That is co-incidentally how my setup is right now :) Adding the AWN's notification applet gives me the functionalit I want. Thanks for the answer :) –  theTuxRacer Mar 19 '11 at 12:18
add comment

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

share|improve this answer
    
They make the notifications a barely-useful annoyance.. –  Dakota Jun 11 '13 at 0:44
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Bookmark: Close button on notify-osd?

ref:

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Decrease the delay with notify-osd-conf app.

share|improve this answer
    
i might try that, but really there are some things that i need some time to read myself. so hence the demand for a close button. otherwise, thanks for the heads up! –  theTuxRacer Nov 23 '10 at 3:24
    
This is really a comment, not an answer to the question. Please use "add comment" to leave feedback for the author. –  hexafraction Aug 17 '12 at 17:52
2  
@ObsessiveFOSS This is intended as a solution for the problem given in the question, and it seems like it may work. So even though this would benefit from expansion and greater detail, it's still would not be better off as a comment. borjacampina: I recommend editing this to explain exactly how to decrease the delay in this manner. –  Eliah Kagan Sep 8 '12 at 8:29
add comment

A close button on the notifications themselves won't solve your problem. They will still see the notifications, and will have to click the close button to close them, if there were one.

What you should do instead, is when you want to allow others to use your computer, simply choose the "Switch User" option in the system menu on the upper right (the gear icon), and use the Guest login. This will fabricate a temporary session for them to use, and will not preserve any browser history, cookies, etc… when that user logs out. This will keep them from seeing your notifications, as well as from possibly disturbing any of your own data (web history, downloads, logins, etc…), as they traverse the ether from your computer.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.