Ubuntu

notifyOSD ignores the expire timeout parameter

Reported by Adrian Roman on 2009-06-22
706
This bug affects 146 people
Affects Status Importance Assigned to Milestone
Message Web
Undecided
Unassigned
One Hundred Papercuts
Wishlist
Unassigned
notify-osd (Ubuntu)
Wishlist
Unassigned

Bug Description

Binary package hint: libnotify-bin

adyroman@panther:~/libnotify-0.4.5/tools$ lsb_release -rd
Description: Ubuntu 9.04
Release: 9.04
adyroman@panther:~/libnotify-0.4.5/tools$

adyroman@panther:~/libnotify-0.4.5/tools$ apt-cache policy libnotify-bin
libnotify-bin:
  Installed: 0.4.5-0ubuntu1
  Candidate: 0.4.5-0ubuntu1
  Version table:
 *** 0.4.5-0ubuntu1 0
        500 http://ro.archive.ubuntu.com jaunty/universe Packages
        100 /var/lib/dpkg/status
adyroman@panther:~/libnotify-0.4.5/tools$

adyroman@panther:~/libnotify-0.4.5/tools$ cat notify-send.c | grep expire_timeout
 static glong expire_timeout = NOTIFY_EXPIRES_DEFAULT;
  { "expire-time", 't', 0,G_OPTION_ARG_INT, &expire_timeout,
 notify_notification_set_timeout(notify, expire_timeout);
adyroman@panther:~/libnotify-0.4.5/tools$

A. Walton (awalton) wrote :

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

affects: libnotify (Ubuntu) → notify-osd (Ubuntu)

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.

Changed in notify-osd (Ubuntu):
assignee: nobody → Mirco Müller (macslow)
importance: Undecided → Wishlist
status: New → Won't Fix

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.

bealer (robertbeal) wrote :

+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.

Mirco Müller (macslow) 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.

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.

Mirco Müller (macslow) wrote :

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.

Smeuuh (smeuuh) wrote :

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.

enb (elitenoobboy) wrote :

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!

Matthew Paul Thomas (mpt) 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.

Smeuuh (smeuuh) wrote :

> 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?

Smeuuh (smeuuh) wrote :

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.

wirespot (wirespot) wrote :

@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.

Matthew Paul Thomas (mpt) wrote :

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"?

wirespot (wirespot) wrote :

@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.

bealer (robertbeal) wrote :

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.

enb (elitenoobboy) 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

@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.
>

Mirco Müller (macslow) on 2009-10-06
Changed in notify-osd (Ubuntu):
status: New → Won't Fix

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.

Changed in notify-osd (Ubuntu):
status: Won't Fix → New
Mirco Müller (macslow) on 2009-10-29
Changed in notify-osd (Ubuntu):
milestone: none → later
status: New → Triaged
movaxes (movax0x13) wrote :

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?

Justin Clift (justin-salasaga) wrote :

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

What a steaming pile. :(

Justin Clift (justin-salasaga) wrote :

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!

Matthew Paul Thomas (mpt) 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 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.

Changed in notify-osd (Ubuntu):
status: Triaged → Won't Fix
Download full text (4.4 KiB)

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...

Read more...

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.

enb (elitenoobboy) wrote :

"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!

Ankur Nayak (ankur-iit) wrote :

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.

wirespot (wirespot) wrote :

@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 :)

Ankur Nayak (ankur-iit) 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

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?

elijah (elijah) on 2010-03-18
Changed in notify-osd (Ubuntu):
status: Won't Fix → Confirmed
Changed in notify-osd (Ubuntu):
milestone: later → none
Changed in notify-osd (Ubuntu):
assignee: Mirco Müller (macslow) → nobody
quequotion (quequotion) on 2011-04-03
summary: - notify-send ignores the expire timeout parameter
+ notifyOSD ignores the expire timeout parameter
Islam Wazery (wazery) on 2011-12-06
Changed in hundredpapercuts:
status: New → Confirmed
Ahmed Shams (ashams) on 2011-12-06
Changed in hundredpapercuts:
importance: Undecided → Wishlist
status: Confirmed → New
status: New → Confirmed
Changed in hundredpapercuts:
status: Confirmed → Invalid
quequotion (quequotion) on 2012-01-03
Changed in notify-osd:
status: New → Confirmed
162 comments hidden view all 242 comments

<rant>then fix the bl**dy docs, whoever made this st**id "design decision" against the wish of so many users</rant>

Leandro (lehphyro-gmail) wrote :

+1 for fixing the documentation

Documentation shoud be accurate. When it's not there's a bug.

There's two ways to fix that kind of a bug: make the software work correctly, or rewrite the documentation.

If the desire for a consistent user interface is to much to make the software work correctly as described in the docs (by having the notification system respect the notify-osd timeout parameter), then notify-osd should be forked into a special Ubuntu version that doesn't have a timeout parameter in the documentation.

Ronny might have nothing to add (neither do I really), but he's still right.

I love this thread. It is the bug that keeps on giving, year after year,
each time someone spends a few hours in frustration and then stumbles
across this bug. Frustrations turns to disbelief and then finally to
resignation.

Deepak (deepakiitr2015) wrote :

Why there is a parameter if that is ignored and even if it is ignored it should not be in documentation. I agree with you for either changing software or documentation. But changing software would be better option as it will provide better control.

Duncan Bayne (dhgbayne) wrote :

> I love this thread. It is the bug that keeps on giving, year after year,
> each time someone spends a few hours in frustration and then stumbles
> across this bug. Frustrations turns to disbelief and then finally to
> resignation.

+1 ... that describes my recent experience. This sort of heavy-handed decision - not trusting developers to use the API appropriately - belongs on Apple systems, not Free systems.

Sebastian W. (yodamin) wrote :

> I love this thread. It is the bug that keeps on giving, year after year,
> each time someone spends a few hours in frustration and then stumbles
> across this bug. Frustrations turns to disbelief and then finally to
> resignation.

+2. Also sharing Ducan's opinion. Do you really want to tell us that you don't allow the normal user to configure is notifications events as he like? Nope instead he has to google for this BUG :-(
*sorry that I am a little bit frustrated.

Henning (pixelkalle) wrote :

> I love this thread. It is the bug that keeps on giving, year after year,
> each time someone spends a few hours in frustration and then stumbles
> across this bug. Frustrations turns to disbelief and then finally to
> resignation.

+3
But, it's Open-Source. Why just not forking it and create a replacement package for it? Users beeing annoyed about this bug, may just install the replacement and everybody is happy. Just saying...

+4 on this insanity

At this point to me it 's not even about the broken function anymore, it's the fact that this bug is coming up on it's 4th birthday and the maintainers still haven't gotten around to editing the two lines of code or updating the man page.

In a commercial enterprise, a person would get sacked for willfully not doing their job for this long.

Anyway, got to take this bug to preschool, he's really looking forward to that playdate with is other bug and doc error friends!

Sebastien Bacher (seb128) wrote :

> In a commercial enterprise, a person would get sacked for willfully not doing their job for this long.

you assume that there is an active maintainer for that component, look at the vcs commit history and you will notice notify-osd is lacking a maintainer for a while

Could everyone stop doing +1 on that bug, that's spamming people subscribed and not bringing any value, if the patch is trivial how come so many of you are wanting to spent a minute ranting, in a non constructive way, rather than spending the same minute writing the manpage patch so the bug can get fixed once for good?

nh2 (nh2) wrote :

Patch attached that mentions the behaviour in the man page.

Robert Pocklington (rpocklin) wrote :

When someone asks me 'what does digging your heels in' mean? I'm gonna refer them to this page. I mean this is just stupid. Make the timeout configurable - everyone's asking for it, it's easy to do. Most people wanting to do this for real-time updates like media streaming or guard-like auto-testing (Rails FTW) which are totally legitimate reasons.

The users of Ubuntu have asked for what they want. Yet it is open source (socially-led) and our views means nothing? Sounds like personality is getting in the way of progress here.

Sebastien Bacher (seb128) wrote :

Some notes:

* the documentation issue has been addressed in 0.7.6 by upstream with that commit:
https://git.gnome.org/browse/libnotify/commit/?id=91280420269c98e408adc0db1e1d1e74cf24c71c

(which adds a "Note that the timeout may be ignored by the server." note)

* the version with that fix is in saucy

* the new version of GNOME/gnome-shell ignore that parameter the same way that notify-osd is doing:
https://bugzilla.gnome.org/show_bug.cgi?id=701645

That's probably not likely to make the users who want to be able to configure that setting, but it seems to be where desktop are heading...

Changed in notify-osd:
status: Confirmed → Won't Fix
Changed in notify-osd (Ubuntu):
status: Confirmed → Won't Fix
nh2 (nh2) wrote :

The man page of notify-send in Saucy still claims "Specifies the timeout in milliseconds at which to expire the notification".

The note in libnotify will not help users looking at notify-send.

My attached patch further up fixes that.

quequotion (quequotion) wrote :

Well, it looks like the tide has turned toward sweeping this under the rug by changing the man page...

Allow me to reiterate that this is the wrong way to fix this bug.

The correct way would be to support the timeout parameter.

That would also follow the freedesktop spec, if it still means anything to anybody.

Case in point:

Similar to adryoman5, I'm use a script that controls a television card and uses notify-osd to provide information much like the OSD on an actual television. Some of the messages are relatively important, others are unimportant. The "--urgency" parameter is not what I'm looking for as it only controls which messages a user will actually see (and users have no idea how to control which messages they will actually see). The best way to do this is to specify all the messages as "--urgency=critical" to be certain they will actually make it onto the screen; but some of them don't need to stay there long.

For example, when channel surfing, if I leave each CH+/- on the screen for five seconds, by the time I've switched five channels I might still be looking at the number of the first one, or possibly five numbers for five different channels. That would be dumb. The numbers need to be displayed, but they don't need to be displayed for five seconds each. Less than a second each would be acceptable. This is not possible with the current design.

You might ask why I just don't replace each old notification with the next one, but then I'd have to redirect you to bug 257135

Matthew Paul Thomas (mpt) wrote :

quequotion, the FreeDesktop notifications specification is for asynchronous notifications. Since five years before Notify OSD was released -- since before Ubuntu even existed -- it has been right there in the very first sentence of the specification: "to notify the user in an asynchronous manner of events".

I reiterated that fact in my comments in this bug report on 2009-10-02 and 2009-11-23. If you try to use it for synchronous things, such as displaying which TV channel you've just switched to, you should not be remotely surprised that some implementations don't do what you want.

As I said in those comments four years ago, if you want to provide synchronous feedback, you should draw your own synchronous notification. Notify OSD is open source, so you could copy and adapt its rendering code if you wish.

oriolpont (oriolpont) wrote :

Well, Notify OSD is synchronous for system volume and screen brightness. Then, why does core ubuntu functionality go against the standard?

Sebastien Bacher (seb128) wrote :

@oriolpont: you are right, that's a bug, those are likely to be moved out of the notification service in unity8

Matthew Paul Thomas (mpt) wrote :

oriolpoint, Notify OSD implements the FreeDesktop Notifications spec, and also provides synchronous feedback for volume and brightness (and soon, for Bluetooth and Wi-Fi hardware switches as well). It is quite common for a computer program to implement a specification, and also to do other things.

quequotion (quequotion) wrote :

>>mpt

No, it doesn't.

http://www.galago-project.org/specs/notification/0.9/x408.html#command-close-notification

In section 9, notifaction D-BUS protocol specification, it clearly states:

"The following messages must be supported by all implementations. "

Following that is section 9.1, which lists several messages that are required to be implemented.

Among them, in subsection 9.1.2:

expire_timeout INT32 The timeout time in milliseconds since the display of the notification at which the notification should automatically close. If -1, the notification's expiration time is dependent on the notification server's settings, and may vary for the type of notification. If 0, never expire. "

Perhaps this is where design decisions for NotifyOSD began to go wrong: "If 0, never expire."

This specification presents a problem for Ubuntu's NotifyOSD design, which renders notifications with no means of closing the notifications manually. In fact, NotifyOSD renders notifications that don't accept any interaction at all:

http://developer.ubuntu.com/resources/technologies/notification/#Notification_actions

"Notify OSD bubbles cannot be clicked on themselves, nor can they contain buttons that can be clicked: in the terminology of the Desktop Notifications Specification, they do not accept actions."

Therefore, a timeout is the only means of closing NotifyOSD notifications, however a notification with expire_timeout 0 would never disappear, which is actually a problem with the freedesktop.org specification in that it allows non-interactive notifications with an expire_timeout of 0.

However, there is already logic in NotifyOSD to handle this specific situation:

http://developer.ubuntu.com/resources/technologies/notification/#Non-expiring_notifications

"Some programs specify an expire_timeout of 0 to produce notifications that never close by themselves, assuming that they can be closed manually as they can in notification-daemon. Because this is usually done for a message that requires response or acknowledgement, Notify OSD presents it as an alert box rather than as a bubble."

Furthermore "if a notification does not actually need response or acknowledgement, you can avoid it appearing as an alert box by setting the expire_timeout to the default value of -1." So NotifyOSD has to support expire_timeout by design after all.

There are no conflicts between fredesktop.org's specification and NotifyOSD's design that prevent a notification from dissapearing on a timer set by the program or script sending a notification. As there is no need to resolve the already resolved issue of non-expiring notifications, and no other conflict with the specification related to expire_timeout, and the design includes a use case for the parameter, there is no logic to support removing expire_timeout support from NotifyOSD or it's documentation.

It's amazing. Three and a half years, almost to the day, since this 'bug' was first commented on. I use bug very loosely, because all it is is poor programming that the developer would rather defend than make the few small changes required to resolve this.

There have been dozens of case uses identified for the timeout parameter to be installed properly.

It's been documented how this failure actively prevents programs developed for a non-Ubuntu distro from working properly in Ubuntu, and can cause confusion and unexpected reactions when porting programs from Ubuntu to another distro.

Many times the specifications have been brought up, documenting how the Ubuntu devs are out of specifications set by freedesktop. Instead Ubuntu (as an organization even though it's one or two people speaking on their 'behalf') has basically told people to 'make your own notify program' if you don't like theirs. And to Hades if you're not able to safely integrate it into whatever desktop notification system the end user happens to be using.

This is how OS's get fragmented and end up going in the toilet. I understand the GPL pretty much lets you fork the 'official' program and muck around with it as much as you want, but the amount of effort that has gone into defending a poorly defensible position versus the work it would take to bring the program back in line with the standard, I can't even accept laziness as an excuse for this anymore.

The only understandable reason this is still going on is pure and simple bull headed stubbornness.

Vanessa Lee (vanessax) wrote :

Having spent 5 minutes learning about notify-osd and then 6 hours trying to figure out what the problem was and finally coming across this, it's appearent there is a dichotomous debate over this timeout issue.

I'm not sure if it's already mentioned before, but isn't there a way for the user to set the server to recognize timeouts? At least this way we don't have the fork and hack the code just to make a new notify-osd-that-recognizes-timeout.

@vanessax Buried in the comments is a patch that is supposed to restore full functionality. But that, for one, doesn't address the core issue, and secondly, does nothing to prevent the next change done to notify-osd by Ubuntu devs to rebreak the system down the road.

Vanessa Lee (vanessax) wrote :

Thanks for the patch, though I think eventually this issue needs to be
worked out and agreed upon.

-Vanessa

On Tue, 2013-12-24 at 04:44 +0000, Heather Van Wilde wrote:
> @vanessax Buried in the comments is a patch that is supposed to restore
> full functionality. But that, for one, doesn't address the core issue,
> and secondly, does nothing to prevent the next change done to notify-osd
> by Ubuntu devs to rebreak the system down the road.
>

wirespot (wirespot) wrote :

Allow me to clarify the situation.

In the Desktop Notification Specification there is nothing to suggest that the expire_timeout parameter is optional.
https://developer.gnome.org/notification-spec/#commands

The devs for gnome-shell and notifyOSD have taken it upon themselves to silently(!) ignore the parameter in their server implementation. There is a comment in the code for gnome-shell that states this, but IMHO that is not the right way to deal with this.

I can see two logical solutions:

1) Fix gnome-shell and notifyOSD to conform to the spec. ie. stop ignoring the expire_timeout parameter. This implies modifications to the code (see aforementioned patch) and no modification to the spec.

2) Change the spec to explicitly advertise support for expiration timeout via a server capability eg. if "expire-timeout" does not appear in the list returned by org.freedesktop.Notifications.GetCapabilities() then the client will _know_ that the expire_timeout parameter will be ignored because the server does not support it. This solution would imply no modifications to the code for gnome-shell/notifyOSD (they will not have expire-timeout published in capabilities, therefore ignoring the expire_timeout parameter becomes perfectly logical and expected.) It will however require changes to the spec and probably to various other client and server implementations.

Matthew Paul Thomas (mpt) wrote :

When you first encounter a specification for a language or a protocol, it is common to consider it as inviolable. If a program implements the specification to the letter, everything will be okay, right? But it isn't so -- as any developer of an RSS parser, Imap client, or Web browser could tell you.

Instead, specification authors and implementors engage in a slow-motion negotiation about the de-facto workings of the thing being specified. For example, the HTML specification used to contain a <command> element. Browser developers decided they didn't want it, so it was removed. Similarly, the HTML specification currently describes a "srcset" attribute, implemented by WebKit, but the Firefox developers have decided it's a bad idea and they'll implement something else instead. But then or now, nobody would seriously respond to the statement "Firefox implements the HTML specification" with queqotion's dismissal of Notify OSD, "No, it doesn't". Those decisions were just part of the overall standards process.

In this case, as wirespot points out, the developers of probably the two most-used implementations of the notifications specification -- Notify OSD and Gnome Shell -- have *chosen* to ignore the timeout parameter. It is not "removing expire_timeout support" as quequotion suggests, and it is not "poor programming" as Heather suggests: it is an ab-initio design decision in both cases. You are welcome to criticize that decision. But since Windows, OS X, iOS, and (as best I can tell) Android don't let apps set notification durations either, you should at least recognize that you are in an obscure minority.

Finally, Heather, you seem to have misinterpreted my suggestion that app developers adapt the Notify OSD code for their own purposes. I did not suggest, and do not think, that they would need to "safely integrate it into whatever desktop notification system the end user happens to be using"; it would be completely separate. One example of this is in TextWrangler, a free text editor for OS X. If you search for some text that is not in the document, or if you type an unmatched closing bracket or parenthesis, you are immediately (synchronously!) informed of this using a custom overlay in the middle of the screen. These notifications do not integrate with OS X's Notification Center at all; they would be much worse if they did. I would enjoy seeing a text editor on Ubuntu borrowing some of Notify OSD's code to do the same.

wirespot (wirespot) wrote :

@mpt: The problem isn't just that some devs chose to ignore a spec. It's also the fact that they told nobody about it; and other devs are forced to waste time discovering this fact.

Either follow the spec; or change the spec so people will know what to expect. Both variants are one-liner patches. It's an extremely simple fix, one way or another. For the love of God, it's been three and a half years. Can we please stop pretending that this isn't a problem and just apply either fix?

[On a side note, yes, it is poor programming to ignore an API and to think one comment in one implementation makes it alright. Giving examples of other bad programming is not going to change that.

Also, I see 143 people affected by this bug; all of them are most likely programmers who wanted to use timeout_expire. How many programmers are working on notifyOSD and Gnome Shell, combined? Who's in the minority, again?]

Vanessa Lee (vanessax) wrote :

I was not out to program anything the day I found out about this
problem.

I was writing a shell script just to get something displayed on screen
after a key press. I found out about notify-osd and used it, it took 5
seconds for me to figure out how to use it.

Then I realized that notifications were backlogged and I couldn't figure
out why. notify-send did not warn that the expiration timeouts were
being ignored.

If you call me a programmer just for writing a shell script I feel
disproportionately-honored.

It's just a shell script, that I spent two days trying to figure out
what was wrong and my time is valuable, there was no notice that an
option was being ignored.

My gripe is that it was being ignored and no warning was being printed
as it was. That will waste a lot of people's time, and cause a lot of
users to wonder who the bad programmer was to see a notification on
screen repeat for several minutes and no way to get rid of it.

My workaround for killing the backlog stack was:

#!/bin/bash
pkill notify-osd
notify-send "Current value is $VALUE"

no longer affects: notify-osd
quequotion (quequotion) wrote :

No longer affects notify-osd?

When is someone with the authority and the ability going to wake up and realize that this bug needs to be fixed, and the way to fix it is to implement the expire_timeout parameter as specified.

There are plenty of specific cases pointed out in this report of users and developers who require support for the expire_timeout parameter. Failing to recognize their need is insulting; it sends the message that Cannonical doesn't care.

For every one person who goes to the trouble of creating a launchpad account and posting a comment on a bug report, how many give up and assume nothing can be done? How many stop using Ubuntu? How many stop using Linux?

Matthew Paul Thomas (mpt) wrote :

Notify OSD was inefficiently tracking its bugs in two places, the project and the Ubuntu package, an example of bug 76416. Now we've migrated to tracking bugs just on the package. To briefly list your resulting errors, (1) that this is a bug is assuming the question, (2) the cases described in this report are cases for which *any* asynchronous notification system wouldn't work reliably, (3) describing how to satisfy their need is not failing to recognize their need, (4) taking offense does not demonstrate that you are right, (5) "Canonical" has only two "n"s, (6) I have spent much more time on this bug report than someone who doesn't care would, (7) the silent majority does not necessarily agree with you or even care, and (8) other OSes don't let app developers customize notification durations either.

Vanessa Lee (vanessax) wrote :

Well let's approach this logically, scientifically, sensibly, and reasonably.

We have an easy opportunity to add a "choice", to have the option or not. But we are choosing not to have a choice.

The whole point of Ubuntu and free software is to be better than commercial, to actually have the best and brightest minds contribute, not highschool hackers who just want to make a buck and write buggy code.

We should somehow at the very least, come half way and allow a choice for to have the expire option or not.

Just because no one else does it does not mean we should not have that option (note I am not saying that we absolutely must have it, but a choice).

We can choose to use Linux, Windows, or Mac, or something else entirely, we can and should have a choice to enable such a timeout/expire in our OSD displays. Note that I said choice to enable or disable on the server side, not explicitly accepting expire arguments on the client side.

With regards to the "silent majority", we don't know how many people have come across this bug, we don't know how many people want it or do not want it.

But we have many comments from people who have spent many hours trying to figure out why the expire timeout was not being detected so I think placing a warning about the expire timeout not being accepted is reasonable.

Throughout history, having fewer choices has always, eventually, led to monopolies, dictators, and single source dominations. I don't think we are close to that with NotifyOSD, but we are going in that direction if we explicitly deny such a choice.

Matthew Paul Thomas (mpt) wrote :

Approaching this logically would be excellent. "The whole point of Ubuntu and free software is to be better than commercial" is a muddled premise -- Ubuntu is both free software *and* commercial -- but I understand what you're getting at. Unfortunately, you have omitted the logical route from there to "We should somehow at the very least, come half way and allow a choice for to have the expire option or not". That is merely an argument to moderation.

In software design, arguments to moderation are not just logical fallacies, they also tend to make the software worse. In introducing "a choice to have the expire option", not only would someone need to incorporate and test Ankur's timeout behavior, someone would need to design, implement, and test the option as well. Designing the option would be particularly difficult, because users would find it difficult to believe that they were being expected to care about it.

The people who have tried to figure out why the timeout does not work are going by out-of-date notify-send documentation. nh2 kindly attached a patch that adds the sentence "Currently ignored" to the timeout flag description. Unfortunately that implies that the change is temporary, when it is not; a viable patch would just remove mention of the flag altogether.

It is not the responsibility of a software project to contain the union of all features or options provided by its predecessors. That leads to overcomplexity and to increasingly unreliable and unmaintainable software. Finally, "fewer choices has always, eventually, led to monopolies, dictators, and single source dominations" is confusing cause and effect. Those things result in fewer choices, they are not caused by fewer choices.

Vanessa Lee (vanessax) wrote :

Where is the illogical reasoning where:

A group of people encountered a timeout option that was not working, spent many hours of their time, lives, and energy, to figure out what was causing it, and only to find out it does nothing but did not warm them of so?

They posted about this, and have asked for:

1. At least a warning.
2. An option to enable or disable it.
3. To make it work as documented.

So the logical reasoning is to say, "no we won't do that and we won't tell you about it, only way to find out is the same way everyone else did by ending up here on this thread".

> The people who have tried to figure out why the timeout does > not work
> are going by out-of-date notify-send documentation. nh2 > kindly attached
> a patch that adds the sentence "Currently ignored" to the > timeout flag
> description. Unfortunately that implies that the change is > temporary,
> when it is not; a viable patch would just remove mention of > the flag
altogether.

Latest version does not reflect that... still.

> It is not the responsibility of a software project to contain > the union
> of all features or options provided by its predecessors. That > leads to
> overcomplexity and to increasingly unreliable and > unmaintainable
software.

This is not the union of all features, it's clearly something that needs to be addressed and we have proven it with this thread alone.

Let's look at Windows and Linux:

Windows is commercially based, they include "features" that sell, how often does Windows crash?

Linux is community based, anyone can contribute, the features that people want get in. How often does Linux crash?

Having more features does not always result in overcomplexity, increasingly unreliable, and unmaintainable software. We want meaningful features that people are asking for, not just something that would be "neat".

We've wasted so many days and weeks on this topic, it needs to be addressed, not just "won't fix".

Holger Berndt (berndth) wrote :

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.

Matthew Paul Thomas (mpt) wrote :

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.

quequotion (quequotion) wrote :

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.

quequotion (quequotion) wrote :

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

Matthew Paul Thomas (mpt) wrote :

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.

wirespot (wirespot) wrote :

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.

Displaying first 40 and last 40 comments. View all 242 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.