notifyOSD ignores the expire timeout parameter

Notify-Send is sending the timeout to the server correctly as your grep shows, but Notify OSD does not support timeouts.

As I understand the code, the "expire_timeout" variable is first initialized
with a default, then the same value is used later to define an array and
then to set the expiration timeout for the notification. I don't see any
code that reads the notification timeout from the command line and sets the
"expire_timeout" variable accordingly.

Anyway, regardless of where the problem lies, the expiration timeout can
only be the default "5 seconds" - there's no way to change this value.

DRM 'manages access' in the same way that jail 'manages freedom'.

On Sat, Jun 27, 2009 at 6:39 AM, A. Walton <email address hidden> wrote:

> Notify-Send is sending the timeout to the server correctly as your grep
> shows, but Notify OSD does not support timeouts.
>
> ** Package changed: libnotify (Ubuntu) => notify-osd (Ubuntu)
>
> --
> notify-send ignores the expire timeout parameter
> https://bugs.launchpad.net/bugs/390508
> You received this bug notification because you are a direct subscriber
> of the bug.
>

That's deliberate any by design. The timeout-policy for notifications is specified here here https://wiki.ubuntu.com/NotifyOSD#Animations%20and%20durations.

The manual page of the notify-send program specifies:

[...]
SYNOPSIS
       notify-send [OPTIONS] <summary> [body]

DESCRIPTION
[...]

OPTIONS
[...]
       -t, --expire-time=TIME
              Specifies the timeout in milliseconds at which to expire the
notification.
[...]

If the expiration time for the notifications must be hard-coded, why leave
the "-t" option?

DRM 'manages access' in the same way that jail 'manages freedom'.

On Mon, Jun 29, 2009 at 4:50 PM, Mirco Müller
<email address hidden>wrote:

> That's deliberate any by design. The timeout-policy for notifications is
> specified here here
> https://wiki.ubuntu.com/NotifyOSD#Animations%20and%20durations.
>
> ** Changed in: notify-osd (Ubuntu)
> Importance: Undecided => Wishlist
>
> ** Changed in: notify-osd (Ubuntu)
> Status: New => Won't Fix
>
> ** Changed in: notify-osd (Ubuntu)
> Assignee: (unassigned) => Mirco Müller (macslow)
>
> --
> notify-send ignores the expire timeout parameter
> https://bugs.launchpad.net/bugs/390508
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I'm sorry to say that this makes notify-osd unusable for certain applications, which need to control the timeout of the notification to smaller values as well as vary the placement and opacity.

IMHO, it should not be the job of the tool to decide how it is being used. If an application delivers "notification spam" people should take it up with the makers of that application. Enforcing artificial and subjective limitations in notify-osd seems to me quite the misplaced effort.

In the meantime, I suppose tools like aosd, xosd, gnome-osd etc. will have to keep being used. Which is a pity, since I was hoping notify-osd to be able to unify and replace them.

Back to the topic: it's still not clear to me, after reading the aforementioned docs, why certain bubbles (volume, brightness) are allowed to use shorter timeouts and stacking, whereas custom bubbles are stuck with sequential display and minum timeout of 5 seconds. It looks like the creators are perfectly aware of the need for stacking and shorter timeouts on occasions, but have just arbitrarily decided to make it a pain in the butt to access them(!) Why?

I respectfully urge the powers-that-be in charge of notify-osd to reconsider. I like the current timeout spec, but only as a feature. We need to be able to override it sometimes. This is a stringent, real need. Attempting to suppress it is, sorry to say, delusional, and will only lead to the appearance of patches that implement this.

+1 (for the above comment)

It's also hugely misleading. I followed documentation, and spent a fair amount of time trying to get it to work before coming across this thread.

Can you either:

a) Fix the documentation and remove that we can change the timeout

b) Make the notification timeout override-able.

b is would be preferable. As mentioned above I can't see why you would want to restrict it. Some applications, if posting a warning or error for example, may want the notification to show for a little longer in case the user misses it.

Please see https://wiki.ubuntu.com/NotifyOSD#org.freedesktop.Notifications.Notify stating that if the notification-daemon is "notify-osd" values for expire_timeout are ignored.

This may be a little dumb, but as I look at the man page for notify-send, it
specifies a "-t" parameter, and I don't see the reason why that parameter
exists without me having the possibility to use it. Is there any way that I
could use that parameter? Can I choose to use notify-send with something
else than notify-osd?

DRM 'manages access' in the same way that jail 'manages freedom'.

On Fri, Sep 11, 2009 at 2:07 PM, Mirco Müller
<email address hidden>wrote:

> Please see
> https://wiki.ubuntu.com/NotifyOSD#org.freedesktop.Notifications.Notify
> stating that if the notification-daemon is "notify-osd" values for
> expire_timeout are ignored.
>
> --
> notify-send ignores the expire timeout parameter
> https://bugs.launchpad.net/bugs/390508
> You received this bug notification because you are a direct subscriber
> of the bug.
>

The initial problem is that the API documentation (which I can't find on Google now) and Wiki didn't/don't quite match.

It so happened that Adrian and I came across the API documentation, rather than the Wiki. And in most cases I would guess that people using it will just look at the API documentation, especially to find out a parameter they want to use.

So to stop future confusion, it's probably worth finding the API page and updating it to be consistent with the Wiki.

Then the second discussion, is whether it should be overrideable. If you can't override it, then there shouldn't be a "-t" parameter as it offers no value to those that might try to use it (ie us the Customers), and it only ends up causing confusion.

If you want to run a GNOME session, without notify-usd (using the old daemon, notification-daemon) install and use gnome-stracciatella-session. That'll start (selectable from gdm login) a GNOME-session without Ubuntu-specific components.

I understand that the intent is to create a set of default that all applications would use. However, there are a few parameters which users should be able to modify. The notification expiration time is one of them, and so is the fact that fullscreen apps should or should not be interrupted by non-critical notifications. Some of us are perfectly content with watching movies and being interrupted by a friend asking something on IM.

If it isn't possible to set it in the API, why not provide a configuration menu ? Either by a osd-notification-properties app, or by simple text/gconf/xml/whatever configuration. It could also contain a setting for the position of notifications, or font size ... I understand that certain core decisions (for example, not stashing notifications) are not subject to modifications, but for simple parameters ...

Some users (including me) would like to use osd-notify, but are prevented by rigid design decision. I'm not saying it's a bad thing to have strong defaults, just that users should be able to modify them when needed. I'm not trying to start a flamewar here.

So the developers are making the notification OSD sucky by not disabling something as simple as timeouts on purpose? If I want to send a single on/off message to the screen, I don't need it up there for more than a second or two.

Reminds me of the old MS saying: It's not a bug, it's a feature!

Adrian, please report a bug on libnotify if the notify-send man page is inaccurate. I don't understand the relevance of DRM to this bug report.

Smeuuh, if we offered a configuration screen for something as boring as notification bubbles, we would have done something terribly wrong in the design. It's possible we have something terribly wrong, but if we have, it's a bug that should be fixed, not configured around.

enb, Notify OSD does not implement timeouts at all, so it is not disabling them, and it is not "not disabling" them either. In Karmic, bubbles with short messages automatically stay up for a shorter time than long messages.

> Smeuuh, if we offered a configuration screen for something as boring
> as notification bubbles, we would have done something terribly wrong
> in the design. It's possible we have something terribly wrong, but if
> we have, it's a bug that should be fixed, not configured around.

Configuration is not always a sign of having done something
wrong. It's just a question of personal preferences, same as mouse
sensibility, or the delay between repeats on keypresses. All these and
even more have been configurable since time immemorial, and I don't
think anyone has ever complained about it.

I agree there is a thin line between what should be configurable by
default and what shouldn't, and maybe this is one of those case where
an additional option in preferences would be overkill. That may be so,
but in that case please provide a way to change it : an option in
gconf, honouring the timeout argument, a configuration file
somewhere ... just provide the option.

The problem here is that there are several classes of notifications,
which haven't the same importance to the user. The urgency setting is
a step in recognising this fact, but the granularity is just too
high. When my IM client receives a new messages, even with stacking, I
feel 5 seconds is just too much. I read fast and like just to glance
at the message to see what has been said, and go back to my IM client
if it needs further inspection. Some people with different use cases
might want longer notifications. The current state of notify-osd
doesn't allow me to set the timeout to a value appropriate for me
(which I could with libnotify, and which is an explicit part of the
protocol), and I feel that is a bug.

I haven't looked at the code, but I'd guess honouring timeouts would be pretty simple to do. I'm clearly missing something here, because I don't understand at all the point of not doing so, other than "the wiki page says so".

That's just my signature below, it has nothing to do with the bug report -
sorry for the confusion. I'll try to remember to delete it, starting with
the next message I send.

I'll open a bug on libnotify as requested, but I really would prefer it if
we could just specify the timeout instead of deleting that from the man
page. I use custom lirc scripts to modify the sound volume with a IR remote,
and if I press the "Volume up" button 3 times to increase the volume, it
will create 3 different notification messages, 5 seconds each - so in total,
it will take 10 second to display the final volume level, and the volume
level will stay on the screen for 15 seconds. It should be trivial to read
the expire time from the command line and pass it on, instead of the
default. In the end, I guess I'll end up spending the time to build my own
expire-time-enabled package if it won't be fixed.

DRM 'manages access' in the same way that jail 'manages freedom'.

On Tue, Sep 22, 2009 at 6:38 PM, Matthew Paul Thomas <email address hidden>wrote:

> Adrian, please report a bug on libnotify if the notify-send man page is
> inaccurate. I don't understand the relevance of DRM to this bug report.
>
> Smeuuh, if we offered a configuration screen for something as boring as
> notification bubbles, we would have done something terribly wrong in the
> design. It's possible we have something terribly wrong, but if we have,
> it's a bug that should be fixed, not configured around.
>
> enb, Notify OSD does not implement timeouts at all, so it is not
> disabling them, and it is not "not disabling" them either. In Karmic,
> bubbles with short messages automatically stay up for a shorter time
> than long messages.
>
> --
> notify-send ignores the expire timeout parameter
> https://bugs.launchpad.net/bugs/390508
> You received this bug notification because you are a direct subscriber
> of the bug.
>

"if we offered a configuration screen for something as boring as notification bubbles, we would have done something terribly wrong in the design."

IMHO, this is completely inaccurate. I can understand not having a config utility by default, or not even making a gui config utility for it, but at least leave some functionality for the people who need them. Things like placement and timeouts should be standard for something like this. I also don't consider something meant to relay data on screen to the user "boring". By following your line of reasoning, you could call desktop backgrounds boring (what do they do for the user, after all?) and say that they also shouldn't be configurable. Or perhaps some of the features in compiz such as desktop switch time are boring and shouldn't be configurable.

"Notify OSD does not implement timeouts at all, so it is not disabling them, and it is not "not disabling" them either."

Doesn't the gnome messaging system for which the notify-send binary was written for respect timeouts? It seems like some functionality was lost in the transition. This is bad.

"In Karmic, bubbles with short messages automatically stay up for a shorter time than long messages."

It is still not short enough. I don't need 10 seconds of notify time for something that only has a word or two. There also seems to be some queuing going on when it really shouldn't be. Example: I am using notify for feedback on some custom media player controls, such as toggling shuffle. If I toggle it 3 times in a second or two, I get a message that stays up for just over 10 seconds that says shuffle on, then right after that disappears, another says shuffle off and stays up for another ten, and so on. That's over 30 seconds total. Is the queuing by design?

While I agree with the bulk of your argument, enb, the queuing can be avoided by using the "merge" functionality. However, this doesn't work with notify-send. I've just filed a bug report at https://bugs.launchpad.net/ubuntu/+source/notify-osd/+bug/434913 about it.

@Smeuuh: "merge" fixes the queuing of similar, overriding messages. Timeout control (which is what this bug is about) is still a problem.

@Matthew Paul Thomas:
> enb, Notify OSD does not implement timeouts at all, so it is not disabling
> them, and it is not "not disabling" them either. In Karmic, bubbles with
> short messages automatically stay up for a shorter time than long messages.

Then I ask again something that was asked above: why does the sound volume change get preferential treatment?

To me this means that the need for shorter timeouts is recognized as valid.

Except that developers seem to then add "yeah, but volume and brightness changes are the ONLY kinds of actions in the world that deserve these shorter timeouts". Which is silly.

We need custom timeouts. If you don't implement it, either someone else will, or it will stop adoption of notify OSD. It's that simple.

Personally, I'm trying to meet the original thinking halfway. I'm trying to figure out why make such a silly statement as the one above.

I'm guessing it's about how fast the average human can recognize information in the bubbles to make sensible use of them. Volume or brightness changes, since all they show is an icon and a slider, can be recognized very fast, hence the short timeout exception. Text needs to be read, hence a timeout which is adapted to the length of the text.

It is very sensible. Excepts it doesn't take into account situations which don't conform to this thinking. Such as outputting a very short piece of text with an explanatory custom icon. Basically, it's the minimum 5 second timeout that's the killer here.

So a way to meet us halfway would be to lower or eliminate the minimum timeout on text pieces. The fade in/out already adds almost a second going up+down. IMHO that's plenty of minimum timeout.

Smeuuh, I agree that configuration is not always a sign of doing something wrong. One good use of configurability is to cater for varied hardware or physical abilities; mouse and keyboard sensitivity is in this category. Another is to help people feel that the computer is personally theirs; enb gives background picture as a good example of this category. I don't see, though, that notification bubbles fall into either of those categories. However, all that is really off-topic for this bug report. For example, even if we concluded that a single time setting cannot reasonably cater for the population's variation in reading speed, we would most likely fix that with an overall "Slower <-> Faster" slider, which still would not involve obeying the timeout parameter, which is what this bug report is about.

Adrian Roman, please report a bug that the IR remote doesn't trigger the standard volume notifications, if it's not reported already.

enb, your subsequent notifications should specify that they are supposed to replace the earlier one if it is still being displayed. Supporting replacement would be a reasonable enhancement request for notify-send.

wirespot: volume, brightness, and eject bubbles are instant confirmation (synchronous) of something you have done, whereas notification bubbles are not-necessarily-instant notifications (asynchronous) of something someone else has done. That the two things are presented in almost the same way is a visual design choice (and perhaps they should be displayed more differently than they are). Can you give an example of your "very short piece of text with an explanatory custom icon"?

@Matthew Paul Thomas: Here's an example. "Screen saver ON/OFF". Or a more interesting one: "The dog went out/came in." (I'm not kidding, a friend of mine has a sensor on the door flap.) Or "Weekly backup finished."

There are lots of oportunity for a knowledgeable Linux desktop user to customize various input triggers (mouse, keyboard, IR remote, proximity sensors, cron job exit status etc.) AND to make the desktop reacts nicely by providing feedback messages. I'm currently using various -osd console tools for this purpose. I was hoping I could use notify-send as a drop in replacement, since it's the hot new thing.

But being forced to stare at a message for 5 or 10 seconds, a message consisting of a few short words and an icon? A message I see all the time and I don't even have to actually read anymore, just glance at? Yeah, I know it becomes transparent if you mouse over but that's not the same as going away and not bothering me, is it?

Clearly, someone somewhere is thinking that the way *they* use notify-osd is the only possible way anybody could ever use it. Whereas more humble people, like the ones who wrote gnome-osd and didn't presume to dictate me how I should use it, are having me use *their* tool. Because it works and doesn't try to think for me.

Hmmm not sure I agree with that explanation. It's clear that people want to be able to set the length a notification shows for. It's a feature that is even listed in the documentation.

People are asking to be able to use it, and you're either not letting them, or are suggesting having a one-controls-all slider bar. As far as API's go that's not very usable and you're not catering for people that want to develop for the platform.

You still haven't given a clear reason why it's a bad idea to expose the timeout property.

There are clear reasons why it would be a good idea to expose it (mentioned above). It benefits the end user's experience, and platform as a whole, as developers are able to write applications with suitable timeouts depending on the context.

Did I just change the status? I had no idea I could do that. I was just messing around and thought that it would reject it because I thought that only moderators or priveledged users could change bug statuses, and now it won't change back to won't fix. Whoops. :(

@Matthew Paul Thomas:

I completely disagree with your arguments.

As a more "philosophical" explanation, if I wanted somebody to tell me how
the software should work for me, I could go use Windows. The spirit of free
software is exactly this, to enable users' freedom to alter the environment
they work with for whichever need they have, regardless of how "niche" that
need / use case may be. I agree that having access to the source code with
the proper license allows users to modify and build their own packages that
do exactly that, but I don't understand the reason why it benefits anybody
to intentionally restrict the capabilities of software under these
circumstances. It's not like it's confusing users with too many options,
this is a command line tool for advanced users - so usability couldn't be a
reason. It does not require massive amounts of development work, so
resources couldn't be the reason. So then, why? As somebody else already
pointed out, we have not yet heard any valid argument why restricting the
use of the timeout property is beneficial. There's an important distinction
between making things "simple" and making them "dumb".

Specifically in my case, the use case is this. I have a TV tuner with an IR
remote control. I use lirc to define actions (call bash scripts) for the
buttons on the remote control. I used separate buttons for volume control in
tvtime and totem for a while, but I then realized it's not really efficient
using 2 sets of buttons for the same function, so I switched to using a
single pair of buttons for system-wide volume control. So I use "amixer" to
increase / decrease volume, and I do so in increments of 3%. If I'm at 35%
and I want to get to 50% volume, I need to press the volume up button 5
times. That effectively means I will have 5 bubbles, each 5 seconds long,
each telling me that the volume has increased 3% - so for at least 20 of the
25 seconds (how long the bubbles stay on the screen) I will have old
information on screen, coming from the queue of notification events. Too bad
I can't either set the timeout to 1 second, or replace the older bubbles
with the newer ones. Too bad both of these capabilities are referenced in
the man page, but neither work - but not because it's a bug, it's a feature!

--
Support Wikipedia:
http://wikimediafoundation.org/wiki/Donate/en
http://volunteer.wikimedia.org/
--
DRM 'manages access' in the same way that jail 'manages freedom'.

On Fri, Oct 2, 2009 at 11:24 PM, enb <email address hidden> wrote:

> Did I just change the status? I had no idea I could do that. I was just
> messing around and thought that it would reject it because I thought
> that only moderators or priveledged users could change bug statuses, and
> now it won't change back to won't fix. Whoops. :(
>
> ** Changed in: notify-osd (Ubuntu)
> Status: Won't Fix => New
>
> --
> notify-send ignores the expire timeout parameter
> https://bugs.launchpad.net/bugs/390508
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Hi, thinking that notify-osd is an interesting piece of software, I'm going to write a small program to show messages from my proprietary UPS software to notify-osd. That said, I totally agree with wirespot and other guys here, but I prefer not to comment too much the absurd policy of not considering user needs at all (user needs are indeed important, not categories), which is unheard for developers. So, let's talk about facts.
I can't see anywhere the word "optional" referred to "expire timeout" in the Desktop Notification Specification (
http://www.galago-project.org/specs/notification/0.9/index.html): for sure notify-osd is not DNS compliant. Is that what developers want? After, we can also discuss about changing the default notify-osd timeout when showing notifications with the Expiration Timeout field set to -1.
Ignoring the timeout field is REALLY a design error, instead:
- because the application sending the message is the only one entity that could/should know about message meaning and, for this reason, its caratteristics. I think that notify-osd should mainly care about message exposure/relaying, not about changing timeouts.
- because you might force application developers to call the org.freedesktop.Notifications.CloseNotification message command after a desidered time, which would be a bad habit.
After all, why would you ignore a timeout setting that is there for a reason (while still cannot see a good reason for ignoring it)?
Moreover I think that some notify-osd configuration options, such as placement and default timeout settings, can be useful as well. That would be a kickass application, a real centralized, good looking notifier.

I'm using fluxbox and wanted to replace osdctl with notify-send but it won't work if "Workspace 1" message lasts more than a one seconds... changing workspaces needs smaller timeouts. Any workaround?

Ugh. When testing my application on Karmic, notification timeouts aren't working as *required* for my application to function.

What a steaming pile. :(

As follow up confirmation, switching to notification-daemon and removing notify-osd works fine.

We'll need to ensure our Ubuntu packages have a "Depends" on notification-daemon listed, and list notify-osd as a Conflict. Should solve the problem. :)

I totally agree with [wirespot] and IMO the notify-osd is totally broken by design.

I exclusively use Ubuntu both at home and at work and use the notification subsystem to automate my life. I like to get notified about results of software build and tests; when the backup is done; getting notified about special emails in a different way (duration, icon). tail on a log file, grepping and piping to the notify-send to create flexible notifications is very important to me.

The new notify-osd is trying to steel my time. If for example I get three similar notifications in 300ms cycle and wanted them to be shown for about 2 seconds and displayed one on top of each other (can do with notification-daemon), notify-osd shows them for 3 x 5 sec = 15 sec - an eternity for me and the overview is lost (notifications not shown at once).

So solved problem pragmatically for me

   sudo aptitude install notification-daemon
   sudo aptitude remove notify-osd

But my worry is, will the nofification-daemon still work in the Ubuntu versions after the Karmic? I would prefer the notify-osd being fixed.

Thanks!

wirespot, the variable durations are not implemented yet. Once they are, you'll find that "Screen saver ON" will display for 5 seconds rather than the current 10, which should be much less annoying.

Adrian Roman, this has little if anything to do with "users' freedom to alter the environment", because the timeout parameter is for application developers, not end users. We think we can set more consistent and reliable durations for users automatically than diverse application developers ever could manually. Calculating the appropriate duration will be *more work* for us than simply heeding the timeout parameter, but we think it will be worth it. For your remote control work, which sounds very cool, I suggest you either (1) enhance notify-send (or find someone to do it) so that you, and anyone else, can set replaces_id, (2) use a scripting language that lets you set replaces_id instead of using a shell script, or (3) if you really want a challenge, work out how to integrate the remote control volume changes into gnome-settings-daemon so that it generates the standard volume bubbles instead of notification bubbles.

Marco Chiappero, it is true that expire_timeout is not part of the Hints table and therefore not explicitly optional, though I could get all RFC-2119 about it and point out that the definition of expire_timeout uses the word "should" rather than "must". We are fortunate that the Desktop Notifications Specification was flexible enough to allow what we wanted for notifications in Ubuntu, so we didn't need to fork it.

movaxes, showing synchronous things like which workspace you've just switched to would be a misuse of notifications, which are for asynchronous things. But provided you follow the software license, you're welcome to adapt the Notify OSD code for your own synchronous overlays.

Justin Clift, if your application is distributed in an official Ubuntu archive or a PPA, you can expect unfavorable ratings and reviews in future if installing it produces ugly notifications not just in your application but in every other application too. And regardless of how the package is distributed, the Ubuntu Software Center will issue a warning if installing it involves uninstalling anything else (such as notify-osd). If you are more specific about what you want, designers could help you find a more harmonious solution; I suggest mailing the Ayatana mailing list <https://launchpad.net/~ayatana> with details.

As long as I have a executable binary (notify-send) which is accessible by
the user, and the binary takes a "-t" (timeout) parameter, I consider that
we're talking about end user freedom and not developer freedom. This
wouldn't have made it all the way here if this "-t" option wasn't in the man
page. If it was an API / method or function call parameter, then I agree -
it would have been developer-land.

And I'm sorry, but you can make all the excuses you want, you're not going
to convince me that it's beneficial for the majority of Ubuntu users to
ignore this parameter. That you want to create a framework for the
notifications, that will have good defaults for everything instead of
relying on application developers to set the notification durations is a
worth-while endeavor, and you deserve praise for it; but the existence of
reasonable defaults _does NOT_ automatically exclude the ability to override
them. Aside from the minimal effort of spending the resources needed to
implement this feature (which should be significantly cheaper than arguing
over the merits of this thread), there is no reasonable benefit for anybody
that arises from ignoring the expire time parameter.

I'm working on a solution myself, because I have lost hope that somebody in
the Launchpad / Ubuntu team will fix this problem. I'm very disappointed,
but there's no way to force you, so I have to fix my own problem - thanks to
RMS and the GPL, this should be possible. If and when this solution of mine
will work, I will make it public - but so far I have no foreseeable "release
date".

On Mon, Nov 23, 2009 at 2:19 PM, Matthew Paul Thomas <email address hidden>wrote:

> wirespot, the variable durations are not implemented yet. Once they are,
> you'll find that "Screen saver ON" will display for 5 seconds rather
> than the current 10, which should be much less annoying.
>
> Adrian Roman, this has little if anything to do with "users' freedom to
> alter the environment", because the timeout parameter is for application
> developers, not end users. We think we can set more consistent and
> reliable durations for users automatically than diverse application
> developers ever could manually. Calculating the appropriate duration
> will be *more work* for us than simply heeding the timeout parameter,
> but we think it will be worth it. For your remote control work, which
> sounds very cool, I suggest you either (1) enhance notify-send (or find
> someone to do it) so that you, and anyone else, can set replaces_id, (2)
> use a scripting language that lets you set replaces_id instead of using
> a shell script, or (3) if you really want a challenge, work out how to
> integrate the remote control volume changes into gnome-settings-daemon
> so that it generates the standard volume bubbles instead of notification
> bubbles.
>
> Marco Chiappero, it is true that expire_timeout is not part of the Hints
> table and therefore not explicitly optional, though I could get all
> RFC-2119 about it and point out that the definition of expire_timeout
> uses the word "should" rather than "must". We are fortunate that the
> Desktop Notifications Specification was flexible enough to allow what we
> wan...

I totally agree with Adrian. Configurable timeouts should be implemented in notify-osd. As long as "-t" option is present in notify-send (and it should be), the ball is in userland. It's sad to see it not being part of the specification. I don't want to add anything more. I'd be waiting for Adrian's fixes.

"this has little if anything to do with "users' freedom to alter the environment", because the timeout parameter is for application developers, not end users."

So you really think that forcing a message that has one word in it onto the users desktop for 15 seconds concerns the developer and not the user? Really? And the ubuntu devs want to waste more time on this bug that they themselves created? Brilliant!

I already fixed it. If anyone wants a patch, I can provide it (send me an e-mail : ankur (.) iit (@) gmail (dot) com ). Its a two-line change.

@Matthew Paul Thomas: So what, now it's "our way or the highway"? That's an incredibly narrow-minded approach to this whole issue. Not to mention the brazenness of telling application makers that they can "expect unfavorable ratings and reviews" if they keep avoiding notify-send. In addition to persisting in keeping everybody from fixing a broken user experience.

I'm trying hard to find my words after such a brash and presuming attitude, in order to keep the discussion polite and to the point. I still can't believe we're seeing so much stubornness in this matter, after all the examples we've been providing that support the fact that We Need This for the express purpose of oferring a better user experience. I'm angry as I write this and I have to constantly edit harsh words out.

I'm left with warning you once again: please fix this, or others will fix it for you, in manners beyond your control. You're contributing to further fracture of the userspace.

As far as I and others are concerned notify-send is broken and Ubuntu has decided to ship their distro with a major shortcoming. Application makers will avoid adopting notify-send, thus, granted, creating confusion in the ranks of the users. notify-send will be forked, patched or replaced.

In those cases where application makers think they know better than their users, the users will be quick to correct them. Example: recently I've had the "pleasure" of seeing Pidgin enable a notify-send plugin after an update, without my consent. Needless to say, the result of having conversation and status changes piped to notify-send was, as you can imagine, horrible. I've disabled it promptly and went back to Guifications.

As for my automation needs, I've given up on notify-send for now. There's plenty of alternatives. Luckily, all it takes is changing a couple of lines in my central scripting library.

I'm still struggling to wrap my head around the notion that Ubuntu can attempt to strong-arm anybody into accepting their bad decisions. Ubuntu has produced a lot of wonderful stuff which has enhanced the state of the Gnome and Linux desktop and end-user experience, but that's no excuse for decisions which are simply bad.

Then again, there's things like Pulse and the new GDM, living testament to the approach "screw end-user experience, Ubuntu knows better" so perhaps I shouldn't be surprised. It's ironic though, that a distro meant to enhance desktop experience would go this way.

I'm really really really disappointed.
Sorry Mattew, but what the hell are you saying? "We think we can set more consistent and reliable durations for users automatically than diverse application developers ever could manually.". You're not supposed to do that, you should not do that, you don't even knot how to do that because you know nothing about the message semantic. You are telling us that you our own decision is much better than mine or the application one which knows the messages content? You know better than me in deciding what I want and what I need? Really? That's ridiculous...
These are really good reasons, while still waiting for reasoning from you (I'm ignoring the nonsense above, "consistent" means absolutely nothing here) about this bug (yes, it's a regression). Honestly, who cares about what you think it's best, people do care about properly working and useful software. People want good defaults, not stupid behaviours. That's indeed your job, not preventing people from doing fine their own job.
A little though: where is the innovation in Ubuntu? Is this all the innovation Ubuntu is supposed to provide, breaking things? How brilliant...
I think I will revert to debian testing, much more recent software and no blind developers.
Sorry for the hateful message, but I think you really deserve it.

Ankur, please post the patch here; we'll be able to validate that it works
and it will serve whoever else feels encumbered by the current state of
affairs.

MPT: I seriously appreciate the work involved in creating a consistent
framework for notifications. It's just that you went only one step too far.
Like a lot of people and I have said before, having a good set of defaults
does not require you to eliminate the override option. That's really
arrogant. There's no benefit to you or anybody else in doing that, and you
have consistently failed to prove otherwise.

--
Support Wikipedia:
http://wikimediafoundation.org/wiki/Donate/en
http://volunteer.wikimedia.org/
--
DRM 'manages access' in the same way that jail 'manages freedom'.

On Mon, Nov 23, 2009 at 10:07 PM, Marco Chiappero <email address hidden> wrote:

> I'm really really really disappointed.
> Sorry Mattew, but what the hell are you saying? "We think we can set more
> consistent and reliable durations for users automatically than diverse
> application developers ever could manually.". You're not supposed to do
> that, you should not do that, you don't even knot how to do that because you
> know nothing about the message semantic. You are telling us that you our own
> decision is much better than mine or the application one which knows the
> messages content? You know better than me in deciding what I want and what I
> need? Really? That's ridiculous...
> These are really good reasons, while still waiting for reasoning from you
> (I'm ignoring the nonsense above, "consistent" means absolutely nothing
> here) about this bug (yes, it's a regression). Honestly, who cares about
> what you think it's best, people do care about properly working and useful
> software. People want good defaults, not stupid behaviours. That's indeed
> your job, not preventing people from doing fine their own job.
> A little though: where is the innovation in Ubuntu? Is this all the
> innovation Ubuntu is supposed to provide, breaking things? How brilliant...
> I think I will revert to debian testing, much more recent software and no
> blind developers.
> Sorry for the hateful message, but I think you really deserve it.
>
> --
> notify-send ignores the expire timeout parameter
> https://bugs.launchpad.net/bugs/390508
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Here is the patch.

You need to kill notify-osd and start the new one from the new source code.

notify-send does all the right thing by sending all the data through dbus. On the other hand, notify-osd doesn't respect the "timeout" value sent by notify-send and instead uses the default values.

notify-send sends "-1" to denote "default timeout", when "-t" option is "NOT" given. Otherwise, the user specified timeout value is sent. So, what I do is use the default timeout values when "-1" is sent and the user specified value otherwise.

I'm not an active developer. So, my fixes might be broken. Please use it with caution :)

I forgot to mention. The patch works with version 0.9.24 of notify-osd.

Please let me know if the patch works fine.

Thanks,
Ankur

Tested the patch - works great here!

--
Support Wikipedia:
http://wikimediafoundation.org/wiki/Donate/en
http://volunteer.wikimedia.org/
--
DRM 'manages access' in the same way that jail 'manages freedom'.

On Tue, Nov 24, 2009 at 12:45 AM, Ankur Nayak <email address hidden> wrote:

> I forgot to mention. The patch works with version 0.9.24 of notify-osd.
>
> Please let me know if the patch works fine.
>
> Thanks,
> Ankur
>
> --
> notify-send ignores the expire timeout parameter
> https://bugs.launchpad.net/bugs/390508
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Looking at the source code from http://packages.ubuntu.com/source/karmic/notify-osd, there is an "orig" source package, and then a diff patch. Is the original source package from debian? Would that package alone without the diff patch from that page make it respect the timeout value (I assume that the debian version, or whatever version that is without ubuntu mods to it would?)? Does the patch above depend on the ubuntu patch being applied?

The documentation patch is wrong. Notification is a client/server infrastructure, and it is up to the server to respect or ignore certain client requests (such as timeout settings, amonst others). The man page of the client cannot possibly know which server the user is using. Thus, "currently ignored" is wrong. All you can say is that some servers may ignore certain settings.

Vanessa, since you ask, those are four more examples of illogical reasoning. The first is a straw man: "no we won't do that and we won't tell you about it". Nobody has suggested that. Everyone agrees that the man page does not match reality. As unknown and Holger have pointed out, notify-send can't be *sure* that the the server will ignore the timeout -- mate-notification-daemon implements it, at least -- but both Notify OSD and Gnome Shell do ignore it, so it is ignored for most users. That is a bug, but it is not a bug in Notify OSD, it is a bug in the man page. It's roughly the equivalent of a Web reference describing HTML's <blink> element without mentioning that the browsers used by most people now ignore it.

The second is assuming the question: "we have proven it with this thread alone". As I said earlier, the cases described in this report are cases for which *any* asynchronous notification system wouldn't work reliably -- whether they had developer-configurable timeouts or not. The notification your app triggered might be queued behind a dozen from other apps, and therefore not appear until a full minute after you wanted it to.

The third is an invalid premise: "Linux is community based, anyone can contribute, the features that people want get in." Features people want are often rejected from Linux. For example, there is no user-switchable option to choose BFS or any other process scheduler, because to quote Linus Torvalds, such an option would be "really bad for users in that it forces the user to make some particular choice that the user is usually not even aware of". The same is true for most other components of Ubuntu, including the notification server; their designers often say no to things. But just as with the kernel, you are welcome to install or compile your own.

And the fourth is a sunk cost fallacy: "We've wasted so many days and weeks on this topic, it needs to be addressed". The word count in this bug report is not evidence of anything except people's awe-inspiring willingness to post comments instead of fixing a man page.

Finally, since you asked, Ubuntu 12.04 experiences a crash or similar error, on average, once every 25 days, 13.10 once every 14 days, and Trusty currently once every 11 days. The equivalent figures for Windows are not public.

The people trying to figure out why notifications linger at the top of the screen for way too long and cause new notifications to come in late and pile up in a chain that can go on for several minutes are not reading outdated documentation; they are trying to figure out what is wrong with this implementation.

Besides, the documentation contradicting Ubuntu's implementation at freedesktop.org isn't outdated.

That is another example of assuming the question. Following the standards process I described in 2014-01-02, the next step would be for the spec to be updated, reflecting the fact that the implementations used by most people eschew that property.

Fact remains that, for as long as the spec continues to say otherwise, notify-osd and Gnome Shell are in violation of the spec.

If you intend to keep things like this, then:

* Remove the parameters from your API. Take it out of the function signature, take it out of the command line tool. Stop fooling programmers and users into using silently ignored parameters, that's just bad coding!

* Document this (in the API docs, in the man page) and own up to the fact it's a spec violation. It's in your best interest to tell people what's going on, so you don't get more bugs like this opened.

Then you can close this bug as "fixed" – or "wontfix", depending on your outlook on the issue.

Updating the spec is a completely different discussion. Maybe it should be done, maybe not; deal with your mess here first.

there's also the fact that lacking support for the timeout parameter allows for notifications that do not reliably disappear, ever.

That's unlikely to be related. If you have a reproducible example of a notification bubble that never disappears, please report it as a separate bug. Thanks!

I was developing a script based on inotify that would use very short-lived onscreen notifications. Turns out I can't, at least not with notify-send; I spent some time trying to debug my script before thinking it might be a bug elsewhere.

This needs fixing either by:

 - making osd-notify honour the setting, or
 - removing it from notify-send, or
 - clearly documenting the issue in notify-send --help

grump :(

Well, I am one more now affected by this BUG. Yes, it is a BUG that doesn't seem to be addressed (or people don't want to). Maybe somebody is forcing their hands and they have to come up with justifications, which from what I read are changing over time (just like the documentation ;)).

One of the old arguments was that this was an option for 'developers', not users. Guess what? I'm a user and, in the Skype options, I can (actually, I could, but this BUG prevents me from doing so) specify the timeout of the notifications. Well, I guess I can't now.

You might have changed the documentation, but "man notify-send" still mentions the (useless, i.e. BUGGY) "-t" option.

I'm really tired of the total disregard and condescension towards the community that Ubuntu takes. This BUG is really not that hard to solve, but you just don't *want* to, despite the many many users asking for it.

I am utterly disappointed. I can live with bugs, they just happen. What really gets to me is the attitude of Ubuntu towards its users.

Matthew Paul Thomas (mpt) your arguments are simply not good enough. You just keep jumping from place to place to justify the unwillingness of Ubuntu to solve this.

Let me conclude: this is a BUG.

>>duncan bayne

The bug isn't in notify-send; this is part of libnotify which properly implements the timeout specification (you can send the timeout parameter).

The problem is in notify-osd (Canonical's notification front-end) which does not properly implement the timeout specification (it will not receive the timeout parameter) for no justifiable reason as I have pointed out with quotations from Canonical's notification specs, the freedesktop specs, and specific real-world use cases.

>>franglais.125

Welcome to the fold.

>> Everyone

Let me at this time express my appreciation for pantheon-notify, a notification front-end from that does everything right. The notifications do honor the timeout parameter and feature a close button as well for when you want them to just go away. It does nothing less than notify-osd can do and everything more.

Yeah I know, I still see the OSD staying on and wondered, oh if there were just some way to make it disappear faster if it wasn't important.

Hey, there must be a timeout option... oh wait, I'm not going to fall for that one again.

We can waste our time on more productive issues that plaque the world that we are MUCH MORE LIKELY TO AGREE UPON, such as:

1. Abortion.
2. Which religion is the one true religion.
3. How to school your children.
4. Reducing the diviorce rate.

Just look at all those topics where so many people agree on and have resolved things so well, seriously, look at them, then look at this ridiculous issue.

Since everybody else over the past five and a half years has been more willing to make epic bug comments decrying the ridiculousness of this bug than to actually fix the man page, I have just submitted a fix for the man page (bug 533631). It was a two-line change.

Anyway, the book was better. <https://twitter.com/mpt/status/537364312491589633>

It would be great if they would accept that, but this is an issue they "won't fix".

If they did accept your manual page fix, someone down the line would say, "hey, wouldn't it be great if we could add a timeout option?"

Then the cycle of madness repeats (with a longer circumferance).

>>mpt

It's pretty clear that the majority opinion is to have this fixed by IMPLEMENTING the timeout parameter, not sweeping it under the rug.

The #1 reason people end up here is looking for some way to make Notify-OSD's notifications go away faster.

The majority opinion in a bug report doesn't mean anything. People who look for, find, and comment in bug reports are disproportionately those who notice and are annoyed by software's current behavior. People who don't notice, don't care about, or agree with, current behavior don't go looking for bug reports about it.

Is it just me? I noticed today that `notify-send -t TIME` has started to
actually honor the -t flag, so long as TIME is 1000 milliseconds or more
(less than 1000 milliseconds and it appears to use 2000 milliseconds).

I think I am running stock 14.10. Maybe someone accidentally implemented
-t despite the intransigence of the Ubuntu developers on this tracker.

Matthew Paul Thomas (mpt) we don't know how many people are annoyed with this bug vs those who are not because today, we simply don't have as many competent programmers as we did a decade ago (before the tech industry boom) that will delve this deep into a problem amoung the programming community.

Obviously with this many comments and complaints alone we could say that this is an issue that isn't going away.

I don't understand, why so long can't fix that problem? I added a timeout fix to my build of notify-osd ( https://launchpad.net/~leolik/+archive/ubuntu/leolik ), 5 years ago

I've read the comments defending the position that the -t parameter should be ignored. I still don't understand. I'm dumbfounded.

I can honestly see no harm whatsoever in adding support for it.

There are plenty of use cases for which the default time out does not work well at all. The current implementation violates the spec. Why are you so stubborn?

I don't quite understand either, and I try to be as inclusive as possible in life, but my complaint is that there is an "official" stance to ignore the requests for a warning on the "official" documentation that says something works that does not.

That is inhernetly saying, "yes I officially said A works, but I also officially decided that I will not have A work and also not mention that it does not work."

this issue seems to scream: "We don't take feedback"

Vanessa, I added that warning to the official documentation two months ago (bug 533631): "Ubuntu's Notify OSD, and GNOME Shell, both ignore this parameter."

>People who look for, find, and comment in bug reports are disproportionately those who notice and are annoyed by software's current behavior. People who don't notice, don't care about, or agree with, current behavior don't go looking for bug reports about it.

I strongly disagree.

You aren't taking into account people who notice and are annoyed, but don't know anything about bug reports--or even what to call "the annoying bubble thingies that won't ever go away".

Before discovering launchpad, or the forums, or making an account, they'll get frustrated, give up and think this, Ubuntu, and/or Linux are [insert expletive here]--and use something else.

I agree with quequotion, you can't assume that the number of people annoyed by these issues are limited to the number of people complaining about it in a bug report.

Case in point, I ditched Ubuntu entirely on my desktop because systemd rendered it unbootable. I'm not going to file a bug report, I'm just going to leave, because systemd is a (poor) design decision they're apparently going to stick with no matter what... just like this notify-OSD timeout nonsense.

Also: happy 6th birthday, notifyOSD bug! It's comforting to know that some things will never change.

Since queqotion and Kent both misunderstood the same word: "Disproportionately" does not mean "the complete set of". It means "biased towards".

>>mpt

Just because I don't agree with you doesn't mean I don't understand your lexicon.

I just think you're wrong. The group disproportionately represented on launchpad is not who you think it is.

However, it's the people *not* represented on launchpad that you're *even more* wrong about.

The design decision to remove support for the options are undermining the effort by developers who put it there and the whole (IMHO correct) thought process behind their work.
The incorrect design decision is taking away my *freedom* to use these options as i see fit.
Do you really want to take away my freedom? Is this what ubuntu is all about?

"unknown", as I said two years ago, we did not "remove support": Notify OSD never implemented the parameter in the first place. And it is also incorrect -- and, as I suspect you know, extremely silly -- to say that the design takes away your freedom: you have the freedom to use mate-notification-daemon instead, to apply Ankur's patch, or to write your own. You don't have any of those freedoms with the notification systems on Windows, OS X, or iOS, none of which let app developers customize notification durations either.

So... after ~6.5 years; 267 posts; and several thousand lines of unhappy, frustrated, and/or annoyed feedback, my man page is still lying to me about -t actually doing something and the devs are now adding "you can use someone else's software or write your own" to justify their design decision. Did I miss something?

I was going to shake my head in disgust and quietly move to another notification daemon until I saw the last few posts discussing how many people are annoyed by this issue. I would like to add myself to the statistic of "very unhappy, but would normally not comment on this bug report."

Side note:
Since other operating systems were brought up in the last post, I would like to note that Windows 10 (and presumably Vista through 8.1) at least have a global configuration option for their notification timeout duration.

I guess “Did I miss something?” was a rhetorical question, since Nicholas did not subscribe to receive any answer. But he missed three things. First, as I wrote on 2015-02-06, I fixed the man page myself (bug 533631). Trivial bug fixes are seldom backported. Second, I did not cite the possibility of using other software to “justify [the] design decision”, merely to disprove the ludicrous claim of “taking away my freedom”. And third, as I wrote on 2009-10-02, a global configuration option would not involve the timeout parameter at all. Adding one is part of bug 420583.

>mpt

Glad to see this bug is still bothering you, because it still bothers us.

bug 420583's proposal great, and it's been sitting there for seven years.

Seven years ago there was an idea that could probably have avoided all this trouble.

Did the x time per n characters algorithm ever really get implemented?

Where is the proposed settings dialog (aside from leolik's fork, which has one)?

How much progress has been made toward making the hooks customizable?

Hey hey, one more person from 2017 crying out to get this bug fixed/feature implemented.

Use Case:
My friend and I are trying to display some volume/brightness notifications for about 200millis on our franken-Chromebooks that we wiped and on which we installed Ubuntu. Alas, it seems the current solution is still:

sudo apt-get remove notify-osd
sudo apt-get install notification-daemon

Cheers to the future where sensibility prevails and someone realizes that individuals want to use this feature for their own ends, not just "developers" who are building applications.

Behold the notify-send help text that brought me here:

Usage:
  notify-send [OPTION?] <SUMMARY> [BODY] - create a notification

Help Options:
  -?, --help Show help options

Application Options:
  -u, --urgency=LEVEL Specifies the urgency level (low, normal, critical).
  -t, --expire-time=TIME Specifies the timeout in milliseconds at which to expire the notification.
  -a, --app-name=APP_NAME Specifies the app name for the icon
  -i, --icon=ICON[,ICON...] Specifies an icon filename or stock icon to display.
  -c, --category=TYPE[,TYPE...] Specifies the notification category.
  -h, --hint=TYPE:NAME:VALUE Specifies basic extra data to pass. Valid types are int, double, string and byte.
  -v, --version Version of the package.

Colter, I addressed your use case in my 2009-10-02 comment: to reiterate, you can’t reliably use an asynchronous notification API to give synchronous feedback on events like volume/brightness change, because your notification might be queued behind dozens of others. If it happens to work with notification-daemon, that’s roughly analogous to a Web page that works only with Internet Explorer: an interesting quirk, but of little consequence, because most people don’t use that software any more. As for the notify-send help text, as I wrote above on 2015-02-06, I fixed the text in bug 533631.

Hello from 2020, the man for notify-send now indeed has a note for the -t parameter that "Ubuntu's Notify OSD and GNOME Shell both ignore this parameter.".

However "notify-send --help" still shows the old message, which had me wasting the last hour trying to figure out what was wrong. After reading the comments, I feel we're being trolled.

Hello from 2020. Under KDE Plasma those timeouts work perfectly (including delicate way of signalling that they are on their way towards expiring) and I use them gladly.

Regarding purpose: I frequently use notify-send in my scripting to trigger notification that some build, tests, compilation, or sth finished. And, for example, info about finished compilation should flash and disappear, but info about failed major build is another story and should persist much longer.

Pls i want good ubuntu notifs