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?

My patch works with the orig package without the debian patch. But, it should also work after the debian patch is applied. I have not tested it though. The debian patch doesn't touch the source code. As far as I could see, it only adds some additional notifications for volume, brightness, Wi-Fi etc.

Another good example of a need for duration: I have a script bound to my "toggle ambient light sensor" key that gives this short notification:

"Ambient Light Sensor"
"ON" / "OFF" (shows only new state)

I can read those 4 words about 20 or 50 times in the ten seconds the bubble remains on the screen.
(In Windows, the equivalent notification from HP's utilities show up for, oh, about 1 second -- so even the expected 5 seconds is way too long.)
If I hit the key twice, the bubbles get backlogged for 20 seconds... ridiculous! Is there any way to get notify-send to do this "update" operation that we're supposed to use?

Also a relevant bug report: https://bugs.launchpad.net/debian/+bug/423314

Adrian, sorry, I was unclear. By "developers" I was including script programmers such as yourself; non-developers don't send themselves notifications from the command line. Anyway, I have already suggested that you report a bug about the man page; if you do that it's more likely to get fixed than if you complain about it (even twice) in the comments of a bug report about a different package.

enb, for the 15-second issue, see the first paragraph of my previous comment.

wirespot, I didn't say using notify-send would invite unfavorable ratings and reviews, I said making a package conflict with notify-osd would. You are also mistaken about Pidgin: it is written in C, and does not use notify-send at all. If you think "notify-send is broken" in Ubuntu, you could have reported, subscribed to, or commented on any bug reports about it, but you never have.

Marco, it's not true that we "know nothing about the message semantic"; notifications have an urgency level, and during Lucid development, notify-osd is using color to expose the urgency level so that we can check that it's set correctly in Ubuntu applications.

Dana, "In Windows Vista and later, notifications are displayed for a fixed duration of 9 seconds." <http://msdn.microsoft.com/en-us/library/aa511497.aspx#howlong> Therefore the HP utilities in Windows are therefore using their own feedback mechanism, just like your light sensor script should. As I said to movaxes, asynchronous notifications are not an appropriate way of giving synchronous feedback.

So let me see if I understand this right so we can move on.

The facts I see are these:
* notify-send and the accompanying framework is incapable of serving timeouts below several seconds, by design, and that design will not be changed.
* There is a need for shorter message timeouts.

Therefore you are hereby stating that the scope of notify-send is limited and anybody who is not pleased by those limitations should use other notification frameworks.

I will also address your other remarks, to the point:
* All who come in contact with Ubuntu will be affected by Ubuntu's choice in this matter. Developers and users alike, the distinction is irrelevant, since notify-send's limitations affect usability first of all.
* This is no longer about the man page, in case anybody had any doubts. This is about notify-send being arbitrarily limited in its capabilities.
* Your rewording about "conflicting" with notify-send does little to change the initial impression. The initial anger is obviously gone now, but I still do not appreciate the patronizing behind the statement.
* As I'm sure you well know, Pidgin may be written in C but has plugins written in various languages, and one of those plugins is pidgin-libnotify. I don't really understand what your point was on this topic.
* I do think notify-send is broken in Ubuntu, and I'm commenting now, on this bug. I think the title of the bug captures the letter, if not the spirit, of what is broken with notify-send, so it's the best place to comment. We can always open another bug report and rephrase it slightly differently if you wish to be pedantic but I don't see the point, really.
* Color bubbles are not in any way related to the topic at hand, which is timeout.
* I'm not really interested in how the Vista notifications work, I'm interested in notify-send. The Vista stuff may be just as broken, but I don't see how that's relevant.

MPT: The fix for this appears to be a 12 line patch (including the blank lines) which has been submitted, and shown to work.

Yet you guys are refusing to implement this (very simple) patch, which would enable apps with specific needs to continue working to full functionality.

We've had to code a reduced functionality workaround that detects Notify-OSD, and makes use of a "confirmation bubble" approach instead in order to GET THE NOTIFCATION OFF THE SCREEN in time for the screenshot. But it makes for a lesser user experience.

I'm obviously extremely unimpressed with the inflexible line you guys are taking on this. It really doesn't suit *100%* of software packages, and the code to allow the edge cases (like our app) to work is already available.

Can't you guys just enable it and allow people to move on with coding more important stuff?

MPT: "[...] Anyway, I have already suggested
that you report a bug about the man page; if you do that it's more
likely to get fixed than if you complain about it (even twice) in the
comments of a bug report about a different package."

Initially I was going to report a bug about the man page, but in the
meantime I've decided not to do it, because actually the man page doesn't
bother me at all. It bothers me that this bug won't be fixed, and maybe if
the man page stays as it is more people will complain on this thread.
It's frustrating that the man page lists the expire time parameter, but the
fix for that is not to remove the parameter specification from the man page;
the fix is the patch that has already been provided to you, tested by me and
a couple of other people, and that you won't apply because you feel you know
what's best for _everybody_.

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

On Wed, Dec 2, 2009 at 8:44 PM, Justin Clift <email address hidden> wrote:

> MPT: The fix for this appears to be a 12 line patch (including the blank
> lines) which has been submitted, and shown to work.
>
> Yet you guys are refusing to implement this (very simple) patch, which
> would enable apps with specific needs to continue working to full
> functionality.
>
> We've had to code a reduced functionality workaround that detects
> Notify-OSD, and makes use of a "confirmation bubble" approach instead in
> order to GET THE NOTIFCATION OFF THE SCREEN in time for the screenshot.
> But it makes for a lesser user experience.
>
> I'm obviously extremely unimpressed with the inflexible line you guys
> are taking on this. It really doesn't suit *100%* of software packages,
> and the code to allow the edge cases (like our app) to work is already
> available.
>
> Can't you guys just enable it and allow people to move on with coding
> more important stuff?
>
> --
> 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.
>

"enb, for the 15-second issue, see the first paragraph of my previous comment."

Why are you waiting for an implement, when you have a patch that is even better than the implement already complete and posted to the bug report? And from what you said, it will only work for 5 or 10 seconds. What if I only want it on screen for one second? For 15?

I'm suffering from the exact same limitation, and really need a notification system with a command line interface and timeout support. Guess I will have to switch to another one... Or is there any PPA available somewhere with the above mentioned patch?

There's no ppa, but you can just grab the source from packages.ubuntu and apply the patch manually.

I think the user should decide. Don't start making things to the M$ style: "People are stupid and should not modify anything, or they would break it."

I don't expect this makes much difference but I'd just like to express my agreement with the general consensus here.

I certainly don't consider myself a developer, I'd only like to output of a one-line script to an osd. I have been using gmessage but thought it would be nicer to have it properly integrated. Without being able to control timing and stacking, however, this is impossible. Am I understanding correctly in thinking that this is not possible with bash, will not be possible with bash and that I would have to learn a new scripting language?

+1 for Ankur's patch

wirespot, pidgin-libnotify does not use notify-send either. This bug report is not about notify-send, it is about notify-osd. If you find a bug in notify-send, report a bug on the libnotify package. I don't mind that you're not interested in bubble color or in Vista's behavior; those comments were addressed to Marco and Dana respectively, not to you.

Justin Clift, I suggested that you be more specific about your use case, and that you post to the Ayatana mailing list to ask for advice. Since you have done neither of those things, it's a bit hard to tell what your problem is! But any approach that expects a notification bubble to be gone after a given time will have undesirable results if another program has a notification bubble up at the moment your program requests its own. Either your bubble will still be up at the time you expect it to be gone, or it will be up for a randomly shorter duration than you intended, or it will not appear at all. This is why I say that org.freedesktop.Notifications is *not appropriate* for synchronous feedback, regardless of what notification display system you are using. If you have implemented an overlay system for your confirmation bubbles, it would be cool if you could make that available as a library other programs can use.

+1 for the patch.

Please implement the patch, or provide like functionality in notify-osd.

+1 for Vladimir Dobriakov's comment #28 and wirespot's comment #20

I have a script that I run every 5 minutes. I want to get notified when it exits successfully. I don't need 10 seconds to read 'Success: my-script.sh".

From #29: "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"."

I skimmed the DNS and RFC-2119 out of curiosity and mincing words with RFC-2119 as justification for ignoring part of a spec you don't want to implement is beyond ridiculous. I've never seen the DNS before and I know EXACTLY what they intended; expire_timeout is supposed to be obeyed or it would have been included with the other hints.

+1 for the patch
I am system administrator and use ubuntu at work and at home i have *various* scripts that I found convenient to use bubbles to report. And I need just a glance at the bubble, not 10 seconds!

I use the patched version and I continue to use it until the package works properly! And properly is not the M$ way nor your way!

Best Regards,
Ludmil

+1 for the patch. It is so-o stupid to restrict users _and_ developers on the free platform.

Sounds like we need someone to write this up as an "idea" for http://brainstorm.ubuntu.com, so that way we can vote on it and put some actual numbers around the demand a version that supports timeouts.

Who wants to write it up?

Submitted as
http://brainstorm.ubuntu.com/idea/24001/

However,
"This idea is awaiting moderator approval before going to the popular ideas
area."

Let's see if it doesn't get rejected by a moderator.

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

On Sun, Mar 14, 2010 at 7:36 AM, Justin Clift <email address hidden> wrote:

> Sounds like we need someone to write this up as an "idea" for
> http://brainstorm.ubuntu.com, so that way we can vote on it and put some
> actual numbers around the demand a version that supports timeouts.
>
> Who wants to write it up?
>
> --
> 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.
>

Nice write up up Adrian, good work. :)

Now, let's hope it gets approved by the moderators.

notify-send is the application that dispatch --expire-timeout to notify-osd daemon. notify-osd doesn't respect notify-send --expire-timeout. notify-send to me is more of a developer's tool to help improve the user's experience. Some of my applications require notification to appear within the 500-2,000 milliseconds. Some of my applications require notification to remain between 7,000 to 9,000 milliseconds. This all depend on how long the message in the notification is. A 5 liners notification require longer duration to remain. A 1 liner with two words require only 1,000 milliseconds. The flexibility to have notify-osd obey by notify-send --expire-timeout value is critical to the user's experience.

The reason why I'm here and writing this comment is because I like many others encounter the same problem when we write our little application.

If necessary, the specification needs to be revised to accommodate for more use cases.

If --expire-timeout is not respected, notify-send should be revised and have the option removed. I hope the author of notify-send is aware of this and remove --expire-timeout to not confuse the user as well as to not lead the user on. It's one thing to not know it exists than knowing it exists and find out that it doesn't work. I like many others would be pissed because it wastes my time trying to make it work when in fact it's not available.

By the way, Ankura's patch works great! Kudos to him.

"The developers of notify-osd have spoken clearly in the bug report. They
are not interested in providing this feature. "
http://brainstorm.ubuntu.com/idea/24001/

So, stop dreaming and let Ubuntu go the MS and Apple way. Do you want
freedom? Fork and make your own Ubuntu derivative. Otherwise shut up and use
whatever they feel is best for you.

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

On Thu, Mar 18, 2010 at 10:10 AM, elijah <email address hidden> wrote:

> ** Changed in: notify-osd (Ubuntu)
> Status: Won't Fix => Confirmed
>
> --
> 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.
>

Wow. They really have. They've marked the idea in the brainstorms site as not being acceptable, so we can't even use the standard mechanisms to actually measure demand.

Can't believe they'd ignore the community so much. Very poor process not to ignore what users are clearly requesting, as a) it'll anger them, and b) they'll go elsewhere eventually when someone offers what they want.

In all honesty, I actually use Linux Mint now (have done for a while). May be worth asking there if the patch could be applied, and point them to this thread.

Sad! Ubuntu seems to be going the MS way. I hope they realize this before its late.

Could you stop adding such comments to this bug? Nobody is limited your choice, you are free to install notification-daemon which is the one which was used before or to build your own version of notify-osd if you want to change this one. That's open source you have the source code and can do what you need or want there. Dictating other people how they should write the software they work on during their free time is not constructive. The notify-osd hackers have made clear they are not interested in having their software doing that, if you want it just look for an alternative solution nobody is blocking you

"Sad! Ubuntu seems to be going the MS way. I hope they realize this before its late."
This statement is so not true. The day when ubuntu will be charged will be the day when you can say ubuntu is going the microsoft way and thats never gonna happen. That's a promise made by Ubuntu that it will always be free. :)

@Sebastien

The issue here isn't anyone trying to tell the devs how to develop their software. The notify-osd package intentionally ignores part of the desktop notification spec, yet still claims to be compliant. It breaks packages around it (ie: notify-send) and forces developers to 'Ubuntu'ize' their applications / scripts.

Sure, everyone can ignore notify-osd and develop against packages like notification-daemon that don't intentionally ignore the spec, but it's impossible for anyone that develops for linux to ignore anything Ubuntu uses by default.

I like Ubuntu. I use it on a lot of machines. I think it's done amazing things for linux and the open source community. However, I don't think it benefits anyone to have the most popular linux distribution behaving in a way that detriments interoperability.

Telling anyone that complains to fork notify-osd is akin to giving them the middle finger and telling them to get lost. It's not going to change anything if Ubuntu is packaging (a broken) notify-osd. What do you think the chances are that Ubuntu would package a forked version of notify-osd?

Also, someone tried to create a brainstorm topic where this debate could continue, but it was rejected. I agree the bug tracker isn't the place for this discussion, but there doesn't appear to be anywhere else for people to voice their opinions.

+1

@Omer, I didn't mean to undermine in any way Ubuntu's efforts in delivering great software. But, it's just sad that so many people have voiced their opinion about this bug and it has not even been considered as an option.

> Dictating other people how they should write the software they work on
> during their free time is not constructive.

That's ironic, considering that that's exactly what the Ubuntu devs are doing to us by refusing to implement this change.

It is also not constructive to fork an entire package for a few lines of code. Especially when said lines of code don't make it in because of obscure reasons that nobody seems able to explain very well beyond "that's how we want to do it, take it or leave it". That's actually the main problem: no rational explanation for this refusal. All attempts have been rebuked in the thread above.

On a side note, it's ironic to think that people sometimes wonder why there's so much code fork in the Linux world... There's a prime example of gratuitous push for a fork right here.

I guess we'll have to start proposing the change to maintainers of other distro's. Don't know how much success we'll have since the upstream developer is an Ubuntu team.

It looks like I'll be forced to stay away from notify-osd for my projects. For personal use I can hack the source and install a version that accepts all timeouts, but it's not viable when you have to distribute a piece of software to others as well. It's not a portable hack.

On 03/18/2010 10:15 AM, Sebastien Bacher wrote:

> you are free to install notification-daemon which is the one
> which was used before or to build your own version of notify-osd if you
> want to change this one.

No, you can't. This only works if you are writing software that you
don't want to distribute to anyone else. If you want to share with other
people, they must also have a functional (i.e. patched) notify-osd.

I think the arrogance of the Ubuntu developers on this thread is really
shocking. There are apps bundled with Ubuntu that don't follow the silly
5 second rule, like the volume control.

The real problem is that notify-send is very limited in functionality.
Either it should support merging, replacement, and stacking, or
notify-osd should support the timeout option. This is just common sense.
The problem with UI experts is that they like to pretend what they do is
a science, when really it is subjective art. Unfortunately, the Ubuntu
UI developers have decided that they know better than everyone else.

Ubuntu: "We choose what our users want so they don't have to!"
and: "It's not a bug, it's a feature!" http://brainstorm.ubuntu.com/idea/24001

Yag, stuff like this was why I dumped microsoft. While I am still free to use a patch, it is still extremely bothersome to have to fight against the developers, not because it's some bug, but because they crippled something on purpose.

Is there some higher up who actually cares about the users that we can contact for an explanation of this instead of shouting upon deaf ears?

Seems some people feel strongly about the subject, nobody is being arrogant there but you are discussing at the wrong place since designers will not follow every bug reports which are usually about technical issues or bugs in the code writte. You should raised the topic on the ayatana list for discussion.

Note that the fact that you want to be able to use random timeout in softwares would lead the system to behave in an inconsistant way tiiming wisz and wouldn't work with the notify-osd slots design (ie notifications don't get stacked but use the same location).

> Either it should support merging, replacement, and stacking, or notify-osd should support the timeout option. This is just common sense.

The current system does support appending or replacing, see what the default im client or music player do in lucid. If you want to display a note for ever on screen why don't you just open a dialog to display it?

You should maybe come with concrete example of things that the current design is limiting which would benefit users (displaying some bubbles for 6 seconds and some others for 8 seconds because software writters don't agree between themself would not benefit users) and raise the topic on the ayatana list for discussion

> The current system does support appending or replacing,
> see what the default im client or music player do in lucid

Yes, but those abilities are not possible with notify-send.

Hence, these bugs:

https://bugs.launchpad.net/ubuntu/+source/libnotify/+bug/257135

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559544

> You should maybe come with concrete example of things that
> the current design is limiting which would benefit users

I have three audio devices, and I have a script to cycle the
current sink to use the next device. Currently, with the broken
notify-send, if I hit a hotkey to cycle to the next device I am unable
to see which current device is active unless I pause for 5 seconds
each time I want to switch devices. This makes notify-send totally
useless.

It seems as if the Ubuntu UI developers have a deep seated inability
to contemplate the possibility that other people have useful and
productive things to say. What a nice way to treat people who are
basically volunteering their labor to help make Ubuntu better.

> Yes, but those abilities are not possible with notify-send.

so there is an another way to fix your issue there which is to improve notify-send or have a notify-osd-send handling those

> to see which current device is active unless I pause for 5 seconds each time I want to switch devices. This makes notify-send totally useless.

that's a fair point but notify-osd doesn't force you to wait, see what happens when changing tracks with a music player on lucid, the limitation there is not with what notify-osd let you do but rather with the notify-send command

> It seems as if the Ubuntu UI developers have a deep seated inability to contemplate the possibility that other people have useful and productive things to say.

What does that mean exactly? This comment doesn't seem especially constructive in reply to a question which aims at understanding your needs to try to solve the issue... Why can't we have something looking nice and behaving in a consitant way there which still working correctly? You failed so far at showing the need of notify-osd changes there

@Sebastien:

> You should maybe come with concrete example of things that the current
> design is limiting which would benefit users

This thread is full of examples! That you consider them irrelevant, that's a
different story, but all these people that have written on this thread have
a valid (for them) use case where the timeout parameter is important.
Otherwise they wouldn't have bothered. Plus, you do realise there may be
hundreds or maybe thousands of other people that just saw the thread and the
arrogant position the developers are taking and just decided to forget about
it, in order to not waste time writing stuff here in vain.

As somebody else was saying, if notify-send supported merging and replacing
we could have worked without the timeout parameter; but since it doesn't,
it's essential. But why would you want to improve notify-send by writing all
the code required to add these features (replacing and merging) when the
timeout patch already exists and it works? (Aside from the fact that I still
don't understand why the timeout parameter _has to be disregarded_ anyway -
I mean, we could have timeouts and replacing and merging.)

@enb:

> Is there some higher up who actually cares about the users that we can
> contact for an explanation of this instead of shouting upon deaf ears?

That's a very good point; I thought about this as well. Maybe there's a
hierarchy of people that we can use to address this dispute.

--
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, Mar 19, 2010 at 11:29 AM, Sebastien Bacher <email address hidden>wrote:

> > Yes, but those abilities are not possible with notify-send.
>
> so there is an another way to fix your issue there which is to improve
> notify-send or have a notify-osd-send handling those
>
> > to see which current device is active unless I pause for 5 seconds
> each time I want to switch devices. This makes notify-send totally
> useless.
>
> that's a fair point but notify-osd doesn't force you to wait, see what
> happens when changing tracks with a music player on lucid, the
> limitation there is not with what notify-osd let you do but rather with
> the notify-send command
>
> > It seems as if the Ubuntu UI developers have a deep seated inability
> to contemplate the possibility that other people have useful and
> productive things to say.
>
> What does that mean exactly? This comment doesn't seem especially
> constructive in reply to a question which aims at understanding your
> needs to try to solve the issue... Why can't we have something looking
> nice and behaving in a consitant way there which still working
> correctly? You failed so far at showing the need of notify-osd changes
> there
>
> ** Changed in: notify-osd (Ubuntu)
> Assignee: Mirco Müller (macslow) => (unassigned)
>
> --
> 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.
>

Let's calm down, people. This is a bug report, not a place to vent your disappointment with ubuntu.

There are two things at issue here, variable delays, and lack of merging for notifications sent by notify-send.

It is clear that the ubuntu people in general do not wish to address the second issue, on the grounds that that would cause disparity between applications. I feel that forcing the whole ecosystem to use a fixed set of parameters by simply ignoring their requests is a bad idea: this should be patched for each application individually. However, this position is understandable, although a finer grain would be nice, instead of simply having "normal" and "urgent".

The second one is clearly a bug (or rather, a design flaw that should be addressed as a bug). This has been reported a few times ( https://bugs.launchpad.net/ubuntu/+source/notify-osd/+bug/434913 and the bugs cited by elijah). I believe this would be very simple to fix: as far as I remember, libnotify only merges if three things match :
- the notification ID, which is _not_ kept by notify-send between invocations
- title of notification
- sender app

The point is that the first one prevents replacing with notify-send. I think the last two criteria should be more than enough to filter false positive, so that the criteria for notification ID could be removed with no side effects, allowing notifications to be merged with notify-send.

In the meantime, I use gnome-osd, which is quite nice, less buggy, and with more features (albeit less pretty), than libnotify.

>Seems some people feel strongly about the subject, nobody is being
>arrogant there but you are discussing at the wrong place since designers
>will not follow every bug reports which are usually about technical
>issues or bugs in the code writte. You should raised the topic on the
>ayatana list for discussion.

Well, a brainstorm report was created for discussion and voting on what to do, but that was locked out...

> examples! That you consider them irrelevant, that's a different story,

nobody said example are irrelevant but could you give some specific ones focussing on the user experience rather than on the way to use?

> notify-send supported merging and replacing we could have worked without the timeout parameter;

ok, so you seem to agree that adding timeout to notify-osd is not the only way, notify-send could also be improved to achieve the same goal

reading again this bug and the request, it seems that timeout is perceived as needed to:
- not have a bubble delay other ones with updated content
- let something stay on screen until the user read it

the first case should not be an issue if you can append or replace the bubbles right? the second case seems to be a situation where you could as well display a standard dialog since you want the dialog to stay on screen until user act on it

There's also a use case for screenshot applications, like Salasaga, where the notification telling the user a screenshot is about to occur MUST be removed before the screenshot is taken.

Otherwise, all the screenshots have the warning notification itself in them, as happened when notify-osd became the default.

Which is why notify-osd not adhering to something that works fine with the previous (proper, working) implementation is really not scoring points.

@Sebastian Bacher:
> Note that the fact that you want to be able to use random timeout in
> softwares would lead the system to behave in an inconsistant way
> tiiming wisz

So draw up a set of HIG guidelines and kindly ask developers to apply them WHEN they make sense. There's no such thing as an interface that's 100% perfect for everybody and everything all the time.

Nothing is solved by hardcoding such limitations. People who want to bypass the limitations will still do so, while legitimate use cases will not be catered to.

> and wouldn't work with the notify-osd slots design (ie
> notifications don't get stacked but use the same location).

I fail to see how a shorter timeout would affect stacking. Or why shorter timeouts mean we must eliminate stacking, if that's what seems to be implied above.

It's not about providing the use case, it's more about providing third party application ON TOP of Ubuntu. Ubuntu comes standard with 5 seconds time-out for notify-osd. That's fine. We are not complaining what Ubuntu does with its standard base. What we want is the ability to have our application be able to adjust the timeout value. So instead of distributing our application with a NEW notify-osd, we can leverage notify-osd that comes with Ubuntu standard base.

When writing core, it should provide developers flexibility to override methods. With this inflexibility, writing third party application for Ubuntu will be a chore.

you are asking for flexibility for random application to block other notifications for the time they want or to make the system look inconsistent which is not likely what you want, if you were explaining your motivation to change the timeout to a non standard values you could have a better chance to convince to notify-psd writters about the need there

As I said quite a long time ago "inconsistent" has no meaning here right now. Consistent with what? The aspect? Colours? The time you decide is right for everybody? The time you decide is fine for every message you don't even know about? And YES, your "inconsistency" IS what WE ALL want here, even though you keep on insisting that you know better than us what we want or what it's better for us. It's a shame, I think there's nothing more to say. In any other different company such blindness would not be considered acceptable for the company's sake.

BTW, I forgot to reply about this: "Marco, it's not true that we "know nothing about the message semantic"". That's funny, priority and semantic are a totally different concepts, you should buy a dictionary.

How about leaving hardcoded limit for MAXIMUM timeout only? So that other notifications wouldn't get blocked. Developers (or users of notify-send) would be able to set the timeout from 1 ms to let's say 5 secs. I guess it would solve 99% of problems mentioned here, wouldn't it?

Guys, you just don't seem to get that notify-osd is about unification and consistency amongst applications using it. It's fundamental design point is to NOT allow applications to use it in different ways, and also not to let the user configure it extensively. In this light, what you request as a feature, could actually be regarded as a bug if it was implemented.

As a user, you are free to use an alternative implementation of the D-Bus spec that suits your needs better.

As a programmer, you have to deal with the behaviour of possible implementations on your target platform. You just cannot rely on specific timeouts, or specific behaviour. In fact, you can't even rely on your notification being visible at all. The notification daemon could just as well not display anything, but write the message to a log file (which obviously never times out).

If that's a problem to your usecase, you probably shouldn't be using the notification infrastructure for it in the first place. That would be a design-bug in your own code, then.

> Guys, you just don't seem to get that notify-osd is about unification
> and consistency amongst applications using it.

Totally wrong, we want to use it exactly for this reason: it's a common (and nice) interface for showing messages from different applications. But I can't see how this idea and goal should be (considered) accomplished with fixed timeouts.

> It's fundamental design
> point is to NOT allow applications to use it in different ways, and also
> not to let the user configure it extensively.

Right, message priority and timings, not much freedom from the sender standpoint. About the user: for example, he might just choose whether he prefer to consider the timeout field from the applications or a fixed timeout for every message (it is reasonable to have this as default behaviour). I would not call it extensive configurability.

> In this light, what you
> request as a feature, could actually be regarded as a bug if it was
> implemented.

At the very beginning someone thought notify-send was ignoring the timeout setting. Then it turned out to be a notify-osd issue. But it is not possible to request it as a feature either, so what are you talking about?

> As a user, you are free to use an alternative implementation of the
> D-Bus spec that suits your needs better.

We already discussed about Desktop Notification Specification.

> As a programmer, you have to deal with the behaviour of possible
> implementations on your target platform. You just cannot rely on
> specific timeouts, or specific behaviour.

It doesn't mean you cannot use the timeout field whenever possible, it is there for a reason, and it is reasonable to consider it too, when makes sense.

> If that's a problem to your usecase, you probably shouldn't be using the
> notification infrastructure for it in the first place.

Oh really? That's strange, because it fits perfectly my needs (even though I hate the timeout constrain).
BTW, I'm not a "luser", I'm a computer engineer (and developer as well), so I think I'm able to evaluate that by myself, thanks.

> That would be a
> design-bug in your own code, then.

Oh well, finally we discovered the problem: the others.

> Totally wrong

No, it's not. Denying reality may be fun, but it's not helpful. I was not talking about what you'd like, but about what notify-osd is aiming at. It is part of project Ayatana, and here's a statement about configurability in that project:
http://<email address hidden>/msg00747.html

> Oh really? That's strange, because it fits perfectly my needs

Obviously, it doesn't, because otherwise, there wouldn't be any need to complain.

> BTW, I'm not a "luser", I'm a computer engineer (and developer as well),

I didn't say anything about "lusers". And I don't really care for your engineering background, but thanks for telling me. It's got nothing to do with the discussion at hand, though.

> so I think I'm able to evaluate that by myself, thanks.

So just go ahead, and evaluate if notify-osd fits your needs. Because in fact, it doesn't seem like you did that yet. You're evaluating how notify-osd should change it's design to fit your needs. That's not the same thing.

> Oh well, finally we discovered the problem: the others

Yes, if you rely on notification daemon specialities, you're doing something wrong. For comparison: Here's what the KDE notification daemon developer (completely unrelated to notify-osd) has to say about how and where Galago notifications may end up in KDE:

http://markmail.org/message/hxvahasqoemkuhp5#query:+page:1+mid:ij55nyqffhbf3gvs+state:results
http://markmail.org/message/hxvahasqoemkuhp5#query:+page:1+mid:hgigaz6777qubzet+state:results

How does a developer know how his notification is going to look or behave? If it's not in-house code, he can't. Thus, he can't rely on presentation, or, in other words, if he needs to rely on presentation, it's not the right infrastructure to use.

@Holger on Ayatana

That's an interesting philosophy for a linux distribution, but bear in mind
that in that case, they did not delete all the other packages from the
repository. If you don't like the default application shipped with the
Ubuntu install CD, you can very well go ahead and install any others from
the repositories. Ignoring timeouts (enforcing the defaults) is similar to
removing all the applications that conflict with the defaults from the
repository. The problem is not with setting a default - that's fine; the
problem is with forcing people to use that default even if they don't want
to.

--
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, Mar 23, 2010 at 1:59 AM, Holger Berndt <email address hidden> wrote:

> > Totally wrong
>
> No, it's not. Denying reality may be fun, but it's not helpful. I was not
> talking about what you'd like, but about what notify-osd is aiming at. It is
> part of project Ayatana, and here's a statement about configurability in
> that project:
> http://<email address hidden>/msg00747.html
>
> > Oh really? That's strange, because it fits perfectly my needs
>
> Obviously, it doesn't, because otherwise, there wouldn't be any need to
> complain.
>
> > BTW, I'm not a "luser", I'm a computer engineer (and developer as
> well),
>
> I didn't say anything about "lusers". And I don't really care for your
> engineering background, but thanks for telling me. It's got nothing to
> do with the discussion at hand, though.
>
> > so I think I'm able to evaluate that by myself, thanks.
>
> So just go ahead, and evaluate if notify-osd fits your needs. Because in
> fact, it doesn't seem like you did that yet. You're evaluating how
> notify-osd should change it's design to fit your needs. That's not the
> same thing.
>
> > Oh well, finally we discovered the problem: the others
>
> Yes, if you rely on notification daemon specialities, you're doing
> something wrong. For comparison: Here's what the KDE notification daemon
> developer (completely unrelated to notify-osd) has to say about how and
> where Galago notifications may end up in KDE:
>
>
> http://markmail.org/message/hxvahasqoemkuhp5#query:+page:1+mid:ij55nyqffhbf3gvs+state:results
>
> http://markmail.org/message/hxvahasqoemkuhp5#query:+page:1+mid:hgigaz6777qubzet+state:results
>
> How does a developer know how his notification is going to look or
> behave? If it's not in-house code, he can't. Thus, he can't rely on
> presentation, or, in other words, if he needs to rely on presentation,
> it's not the right infrastructure to use.
>
> --
> 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.
>

@ Krzysztof:

As far as I'm concerned, that would solve my problem; but bear in mind that
the issue here is not that my personal problem with notify-osd needs to be
solved. Other people may want longer notifications on the screen. Same with
replace and merge.

The issue here is that the developers want to enforce some unnecessary,
useless and frustrating restrictions on how people use their code. Some
people argue it's their right. I'm not going to say it's not, it's just that
without understanding the specific benefits this position is bringing to the
community, it seems they're not really following their mantra. If it was
Microsoft or Apple - I wouldn't have bothered to argue on this thread - we
all know they want to enforce their interests on their users, and charge you
for it. It's just that it's Linux, and we're used to freedom and
community-oriented decisions rather than corporatist bull**** motivated by
greed.

--
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, Mar 22, 2010 at 11:50 PM, Krzysztof Jelski <email address hidden>wrote:

> How about leaving hardcoded limit for MAXIMUM timeout only? So that
> other notifications wouldn't get blocked. Developers (or users of
> notify-send) would be able to set the timeout from 1 ms to let's say 5
> secs. I guess it would solve 99% of problems mentioned here, wouldn't
> 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.
>

I think it might be a good idea if someone could take an initiative and post this issue on the Ayatana mailing list. We might get better answers/resolutions there. Please remember to post the link to the specific mail archive here, if it doesn't hurt.

"You just cannot rely on specific timeouts, or specific behaviour. In fact, you can't even rely on your notification being visible at all. The notification daemon could just as well not display anything, but write the message to a log file (which obviously never times out)."

If the only guarantee is that notifications get sent 'somewhere', then what's the point of even having it? Are you saying that anyone developing an application that needs to provide visual notifications to their users shouldn't use any of the notification daemons _at all_, because that's what it sounds like to me?

"How does a developer know how his notification is going to look or behave?"

By reading the spec and following it. That's the reason I've posted in this bug report. In my opinion the notify-osd developers ignored part of the spec and, because notify-osd is in Ubuntu, everyone else is forced to work around their _opinion_ of a suitable timeout value or to ignore Ubuntu which is a much worse option.

I use notify-send with a single script that rsyncs some data once every 5 mins. When the script runs successfully I use a 3 second notification. When it fails I use a 15 second notification. I want both to be relatively unobtrusive, but (in my opinion) it's more important to see a notification about a failure condition than it is to see one about success.

I still want a notification when my script runs successfully, because I want to _know_ that it's running. If it's running properly I don't mind missing the (short) notification two or three times in a row and, since I'm used to seeing it, I can read it in about 2 seconds. However, if it fails I'd prefer to see the notification as soon as possible and want a little more time to read it (definitely more than 5 seconds).

Is there another solution better than notify-send that I can use that will push an unobtrusive notification to my desktop. Keep in mind my script took about 60 seconds to write. Am I mis-using notify-send?

Completely ignoring the argument of what is required by the spec, I think it was a poor design decision for notify-osd to make _all_ notifications so similar looking. As a user I want (critical) notifications about something failing to stay on the screen longer and have a more prominent look to them. I can't be the only user that takes more time to interpret a failure condition (that I rarely see) than I take to interpret a success condition (that I'm expecting because I see it all the time).

I've also seen comments suggesting that allowing a longer timeout will allow developers to block notifications from other applications by setting a long timeout value. I can already cause considerable delay by sending multiple messages to the daemon in short succession. Ex:

for i in {1..3}; do notify-send "Hello World $i"; done

Had I not taken the time to patch notify-osd, the above would have been my solution for displaying a longer notification. Is that the kind of behavior anyone wants to encourage? I'd think that adding some spam control to the notification queue would be more important to the users' experience than forcing all notifications to use a 5 second duration.

Holger Berndt ha scritto:
>> Totally wrong
>
> No, it's not.

I have clear in mind what is the aim of notify-osd. But I still don't
see any reason why that goal is achived by imposing *every* user a fixed
5 seconds timeout.

> I was not talking about what you'd like, but about what notify-osd is aiming at. It is part of project Ayatana, and here's a statement about configurability in that project:
> http://<email address hidden>/msg00747.html

We are neither talking about good defaults nor about extended
configuration options. But you ignores it.

>> Oh really? That's strange, because it fits perfectly my needs
>
> Obviously, it doesn't, because otherwise, there wouldn't be any need to
> complain.

No, it fits perfectly, but I do prefer to have different timeouts. What
I'm complaining here mostly and what bothers me is the Ubuntu team
arrogance and blindness. And the lack af good arguing for this limitation.

> And I don't really care for your
> engineering background,

And we don't really care about you telling us what's right or wrong for us.

>> Oh well, finally we discovered the problem: the others
>
> Yes, if you rely on notification daemon specialities,

No need for long stories, I'm not relying on anything, I just want to
see a bubble message on my desktop with notify-osd, because I like it,
except for the fact that it does not take into account the timeout
parameter passed from the application (while it easily could without
breaking the unification purpose).

> How does a developer know how his notification is going to look or
> behave?

Even though I like the new notification system, about this specific
topic and about relying on the popup being show or having all the
action, I might ask you why developers should use something that comes
with no guarantee to work or to work exactly as they expected.

Think this discussion has gone on too long and is going nowhere. It needs to be reviewed.

1) Clearly developers have a need to be able to override the default time of the notification. That needs to be considered, especially if you want to encourage development on the platform.

2) If you're not going to allow it to be ovverrideable, then remove the option from the documentation! Save some of the confusion.

3) My preference would be making it overrideable. There's a system default, which Ubuntu can follow, but 3rd party apps have the ability to override (based on some of the use cases mentioned). If you feel this is inconsistent, that's ok... **You don't have to install the 3rd party apps!** The user can make that choice, why not let them, rather than trying to force it on them.

If I for example wrote an app, and set the timeout to 10minutes, I'm sure users would get annoyed, and uninstall my app.

It reminds of the sort of awful decisions the UK goverment make, "umbrella" laws/rules that apply to everything but don't work in terms of interests to the customers, ie the public.

@Holger:
> Guys, you just don't seem to get that notify-osd is about
> unification and consistency amongst applications using it.

In other words, in order to achieve a unified framework, make developers unable to use it, so they will have to use _another_ framework. LOL. Doesn't that strike you as defying the very goal you were aiming for? :)

The only way you can realistically achieve the above is if all the applications that can't use notify-osd are not available for Ubuntu. I'm guessing that's not what you want.

Jokes aside, please, give us a viable alternative. We can't use notify-osd and you don't want us to use another framework. What SHOULD we do?

Question: what if we open up a PPA repository and maintain a patched version of notify-osd? We can direct users who complain about the timeout to install the PPA version.

@Adrian Roman:
Weird analogy. You can do the same with notify-osd as you can do with other default applications: Replace it with an alternative from the repository if you don't like the feature set. notification-daemon would be an alternative to notify-osd that offers the features you want. Why don't you just go ahead and use that one instead?

Ryan J:
> By reading the spec and following it.
That surely applies both ways, server and client side. Does your client follow "Clients should try and avoid making assumptions about the presentation and abilities of the notification server." ?
Besides that, that spec is a draft that is under revision anyways. People have expressed their unhappiness with specific parts (e.g. some KDE folks don't like clients being able to query server capabilities, as that breaks model/view separation etc).

@Marco Chiappero:
> And we don't really care about you telling us what's right or wrong for us.
I am not telling you what's right and wrong for you (who is "we"? Majestic plural?). I'm trying to tell you what notify-osd is all about. See above - if it doesn't fit your needs, use notification-daemon instead. That one respects timeouts, and is more configurable in general.

Alternatively, try to convince the notify-osd designers (I am btw not one of these) that timeouts are vital. People do tend to change their mind when something is well argued. It has been advised before that this better be done on the corresponding mailing lists, as designers don't generally read bug reports.

Holger Berndt ha scritto:
> @Adrian Roman:
> [...] Why don't you just go ahead and use that one instead?

Probably because he had a look at http://www.ubuntu.com/community/ or
http://www.ubuntu.com/community/participate/, considers notify-osd a
better option and wants to suggest how to improve it a little bit.
However you're somehow right, but looking at the replies from the Ubuntu
team, IMHO, the correct question should then be: "Why don't you just go
ahead and use another distribution instead?"

> Ryan J:
>> By reading the spec and following it.
> That surely applies both ways, server and client side. Does your client follow "Clients should try and avoid making assumptions about the presentation and abilities of the notification server." ?
> Besides that, that spec is a draft that is under revision anyways. People have expressed their unhappiness with specific parts (e.g. some KDE folks don't like clients being able to query server capabilities, as that breaks model/view separation etc).

Well, I don't know any detail about it and I'm not experienced with it,
but I'd say it is fine not to make any assumption if then a sort of
negotiation capability or query model is present (I know nothing about
the server but I can ask it about its own abilities). Otherwise it looks
to me that a client developer has no chance to know in advance whether
he will obtain what he wanted or not. So, again, why should developers
spend time using something that comes with no guarantee at all to work
or to work exactly as they expected?

> @Marco Chiappero:
>> And we don't really care about you telling us what's right or wrong for us.
> I am not telling you what's right and wrong for you

You keep on telling us that the problem lies elsewhere, because it's
easier to say that we didn't understand the aim of notify-osd, that we
are using it improperly and for the wrong task, that application using
it are broken and so on instead of admitting that notify-osd comes with
an unmotivated limitation and/or lacks a few basic configuration options.
BTW, "you probably shouldn't be using" is from you, right?

> (who is "we"? Majestic plural?).

We, all the people complaining. Quite a lot here.

> Alternatively, try to convince the notify-osd designers (I am btw not
> one of these) that timeouts are vital.

Nothing is vital, neither having a good looking bubble. But desirable? Sure.

> People do tend to change their
> mind when something is well argued.

It looks like you've read just a couple of comments in this report...
As for me, as I already said, one important reason for using the timeout
field from application (when a specific value is present) is that the
notification daemon knows nothing about the message purpose, content and
meaning. In other words the applications know better than notify-osd how
much time is suitable/comfortable/needed for the user to read the message.

> It has been advised before that this
> better be done on the corresponding mailing lists,

Ok, which one?

> as designers don't
> generally read bug reports.

But some other people from Ubuntu do. I think they should care about
forwarding interesting topics or suggestions to th...

>Question: what if we open up a PPA repository and maintain a patched
>version of notify-osd? We can direct users who complain about the
>timeout to install the PPA version.

At the same time, the PPA could also include a fix to lucids moving the title bar buttons over to the other side and giving users no gui option of moving them back, it could also get rid of the shutdown restart and logout confirmation dialogs that also have no gui way of fixing, along with the ability to put update notifier back to the system tray. Ubuntu just seems to love forcing weird changes on its users for no real reason at all, and not even giving them the ability to switch back without knowing how to use gconf..

@Holger
The scope of the work in this bug report is notify-osd, not Ubuntu in
general. While it is possible to install something else, that's besides the
point.

Within the scope of this bug report (notify-osd):
- one option is to ask the application for the timeout (make the timeout
parameter mandatory, there's no default);
- second option is to set a default (5 seconds) and allow it to be
overridden with the timeout parameter;
- third option is to hard-code all notifications to 5 seconds.

Within the scope of a linux distribution, that would be equivalent to:
- provide all the different conflicting packages (as it was before Ayatana);
- provide one default and allow users to install others if they so choose
(what was specified with Ayatana);
- provide one application and remove all others from the repository (similar
to what's happening here with notify-osd).

The analogy is pretty clear, unless you want to pretend you don't
understand. The suggestion to install another set of packages that provide
the same function, within the scope of this bug report, is similar to
suggesting to install a different distribution in response to Ayatana,
within the scope of the linux distribution.

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

On Wed, Mar 24, 2010 at 8:15 PM, Holger Berndt <email address hidden> wrote:

> @Adrian Roman:
> Weird analogy. You can do the same with notify-osd as you can do with other
> default applications: Replace it with an alternative from the repository if
> you don't like the feature set. notification-daemon would be an alternative
> to notify-osd that offers the features you want. Why don't you just go ahead
> and use that one instead?
>
> Ryan J:
> > By reading the spec and following it.
> That surely applies both ways, server and client side. Does your client
> follow "Clients should try and avoid making assumptions about the
> presentation and abilities of the notification server." ?
> Besides that, that spec is a draft that is under revision anyways. People
> have expressed their unhappiness with specific parts (e.g. some KDE folks
> don't like clients being able to query server capabilities, as that breaks
> model/view separation etc).
>
> @Marco Chiappero:
> > And we don't really care about you telling us what's right or wrong for
> us.
> I am not telling you what's right and wrong for you (who is "we"? Majestic
> plural?). I'm trying to tell you what notify-osd is all about. See above -
> if it doesn't fit your needs, use notification-daemon instead. That one
> respects timeouts, and is more configurable in general.
>
> Alternatively, try to convince the notify-osd designers (I am btw not
> one of these) that timeouts are vital. People do tend to change their
> mind when something is well argued. It has been advised before that this
> better be done on the corresponding mailing lists, as designers don't
> generally read bug reports.
>
> --
> notify-send ignores the expire timeout parameter
> https://bugs.launchpad.net/bugs/390508
> You received this bug notification because you are a direct subsc...

I made a ppa package using the patch by Ankur Nayak.
ppa:fkalman/main

Hey, I was just writing up some bash cron scripts today to notify me about system temperature and, 'lo, I can't control the time these messages display for. That's rather ridiculous. I've read most of the discussion here and agree with those who see this as being a flaw with notify-osd.

Just as a humble request - for whoever gets to read this thread. If you came
here because you were bugged by the behavior of notify-osd ignoring
expire-timeouts, please post on this thread - maybe one day we'll be enough
people to get the developers thinking.

--
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, Mar 29, 2010 at 2:13 AM, Finog <email address hidden> wrote:

> Hey, I was just writing up some bash cron scripts today to notify me
> about system temperature and, 'lo, I can't control the time these
> messages display for. That's rather ridiculous. I've read most of the
> discussion here and agree with those who see this as being a flaw with
> notify-osd.
>
> --
> 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 ended up coming here because I want to enhance a python script that i have to operate a non-standard remote (Asus AI remote, not supported in Lirc). I want to use on screen notifications to display the status of the remote (I plan to program two different key maps depending on what mode I program the remote to)

The old idea of a dialog box that the user clicks is not acceptable for me, because my end goal is to have completely remote based control when using it for music or videos (making a micro remote for a HTPC, basically). Notify-osd appeared to be a perfect way to notify what mode the remote was operating on at the time, and while I can still use the command even with an unpatched notify-osd package (call the osd information every 4.9 seconds that the remote is in the alternate mode), and would work for what I want it for (it only needs to be in that mode for 5-10 seconds anyway, so it will have minimal impact on other programs access to those calls) It is very dirty programming, especially if i plan to re-release this script in the wild one day.

Yes, I could make a package level program with it's own system tray icon showing the status and all that fun stuff, but do I really want all that effort for what I know is a niche program when all the tools exist already in the default installation? Not to mention that replacing the notification system with another one brings up it's own problems. First off, anyone installing your app will have to remove notify-osd to put in your preferred flavor. And point B, I refer back to post 29, where it was stated: "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)"

So, no, if anyone plans to redistribute a program using any notification daemon included with Ubuntu that is not notify-osd, we get in trouble. The only options that are left (as the developers want to say) is to use an incomplete/broken program, or to custom build our own notification systems, which have little to no compatability with the existing system already installed. It appears to me to be a lose/lose situation for everyone.

I don't have the background or knowledge to understand the reasoning underlying the design decisions behind notify-osd so I will refrain from demanding design changes, even though it seems a little bit peculiar that having a configurable time-out (with a max-time perhaps) could hurt that much.

But, from a use case of view there are two very different scenarios that fits the use of notify-osd and demands different time-outs:

1. "Un-solicited" notifcation (for example, mail arriving)
2. "Pop-up response" use case (for example, outcome of runned script)

In the first case, a longer time-out is justified in order for the user to notify it, but in the second case, where the user watches the screen, waiting for the response, the long time-out is annoying. I bet 95% of all complainers use the notify-osd as in the second example.

These two use cases would require different time-outs.

I came to this thread because I'm really annoyed by an add-on to Thunderbird, named Gnome Integration, that displays a bubble every time I receive a email, using notify-send that stays on my screen for not less than 10 seconds.

Well that's ok if it's just one email but, when I first start my computer every morning, there are always tens or hundreds of emails waiting to be downloaded by Thunderbird. Every single email creates a bubble and they are displayed in sequence for 10 seconds each one. Sum that up and you'll have an idea of my ordeal. It's common that I finish scanning the whole lot of emails and switch to something else before all the bubbles are gone.

The add-on has a configuration gui and one of its options is the time out. I was getting annoyed that whatever the amount of time I set there, there was no change in behaviour and I started googling for a solution. That's how I came across this bug report.

It makes me sad that no interest is shown by the Ubuntu team to either tackle this issue or, at least, give us (users and developers alike) a feasible alternative to get what we want/need.

I went through this hole thread looking for an easy solution for my issue and the only one I could find was a patch to notify-osd to allow setting different time outs. The problem with that is that, although I'm a developer for other platforms, I don't have the smallest clue as how to apply the patch and recompile the package. So, I think my only solution is to disable (or uninstall?) the add-on until there's a solution to this or until I find another add-on that does the same as Gnome Integration without using notify-osd.

@Airton Torres:

Fiddling with timeouts sounds like an exceptionally strange way to solve that particular issue. So, you'd still like to have tens or hundreds of bubbles, flickering unreadably on your screen with short timeouts? Doesn't make any sense to me.

Developers already have a way to avoid notification spam of their software: They can update their own bubbles. Other mailers do it like that: When the first mail arrives, it gets a bubble ("Mail from Foo with subject bar arrived"). When the second mail arrives, and the bubble is still on-screen, the bubble is simply updated ("2 mails arrived"). When the 272th mail arrives, the very same bubble says "272 mails arrived".

@Holger Berndt

That still comes back to the original problem.

a) To do what you recommend, any application would have to create their own notification system to do exactly what notify-osd does, but is unable to interact with it.

b) While your app (and any other app that has it's own notification system) tries to post at the same time, they either need to use the same notify system or overwrite each other on the screen space

c) A fantastic idea would be a rewrite of the notify-osd type program to better allow integration of numerous messages at once. notify-osd already has the ability built in to show two bubbles at once (for proof of concept, I changed the volume from my keyboard and immediately changed the song using my keyboard in Ryhtmbox. Attaching screen shot)

d) This rebuilt program would still be incompatible with the official notify-osd package, so the official package would have to go.

e) Matt Thomas @ post 29 has already threatened anyone who wants to build a distributable notify program when he said "Ubuntu Software Center will issue a warning if installing it involves uninstalling anything else (such as notify-osd)"

f) That puts us back to the same spot we were in originally. It appears to me that Mozilla is using the specs as the notify-send man page still gives information for using a time-out when sending to it.

At this point, my question would be, how far upstream is this bug? It's obvious that it affects all unpatched Ubuntu derivatives (I use Linux Mint 7 - Gloria). Was the software developed at the Ubuntu level? If so, it might be worth investing in looking for some of these libraries directly from Debian, which if I understand correctly is upstream from Ubuntu.

@Heather Van Wilde

> To do what you recommend, any application would have
> to create their own notification system to do exactly what
> notify-osd does, but is unable to interact with it.

No, that's not true. You can trust me on that - as it happens, I wrote notification spec integration for another Mail User Agent myself, which works exactly as I described above.

> notify-osd already has the ability built in to show two bubbles at once

Actually, that's another thing that notify-osd cut down on. The upstream GNOME implementation "notification-daemon" allows much more bubbles to be displayed at the same time. But it doesn't really solve Torres' problem either: Having hundreds of bubbles from the same application on screen at the same time is not a pleasant experience. (To be fair, I am sure the upstream implementation has a display limit and a queue, too.)

[Cutting most of your points, as they are based on the wrong assumption in a)]

> as the notify-send man page still gives information for using a time-out when sending to it.
> At this point, my question would be, how far upstream is this bug?

One could say that the bug is indeed upstream: It's in the man page, which should make it clear that some daemons might ignore the timeout setting.

> One could say that the bug is indeed upstream: It's in the man page, which should make it clear that some daemons might ignore the timeout setting.

Coming back full circle to the question of why the developers are refusing to have the daemon make proper use, which ends up breaking other programs (Thunderbird as explained earlier tonight) and make it so developers can't create new programs, and forcing said developers into using a tool that is unable to suit their needs.

In my case, as I described before, I want to use notify-osd to display a one or two word message for a second or two. No dialog box, nothing to click, and nothing on the taskbar. I am running all my stuff through a Python script (it's basically a fancy key mapper) so i'm not about to create a whole new osd application for this.

People have asked for examples of what these things are wanted for. Here's my example.

The discussion is circling, could you take the chatting to mailing list of an another media than the bug tracker?

> use notify-osd to display a one or two word message for a second or two

you want to do this, some other for 6 seconds, some for 18 seconds, and we get a system working in a non consistant way for no real reason out of different software writters having different preferences for timing, you might consider that good but Ubuntu decided to make a call for consistent system interaction and not random timing behaviour which most users are glad for, if you don't agree with that feel free to use another notification service or distribution

Holger Berndt wrote:

> No, that's not true. You can trust me on that - as it happens, I wrote
> notification spec integration for another Mail User Agent myself, which
> works exactly as I described above.

OK then, how, using notify-send, would you achieve this? You can't, because *notify-send* is broken.

> you want to do this, some other for 6 seconds, some for
> 18 seconds, and we get a system working in a non consistant
> way for no real reason out of different software writters having
> different preferences for timing

Umm, I'm the software author, how about letting ME decide what timing is appropriate for MY notifications, of which libnotify is merely a conveyor?

I do believe I know best what timing to use. How is it possible that authors of a completely different lib pretend to know such things better than me, the author?

> Ubuntu decided to make a call for consistent system interaction
> and not random timing behaviour which most users are glad for

I beg to differ. These notifications suck. And there's plenty of evidence on the forums and on the web, if you're willing to read it. The fact they stay up for so long, the fact you can't put more than one at a time up (the second one is reserved, really), the fact they obscure information on screen, the fact you can't customize position and transparency etc.

> if you don't agree with that feel free to use another notification
> service or distribution

I'm sorry but this remark is brain-dead. The very idea behind this notification library was that everybody would use it. How can you say "use something else"? What good is that?

I'll say this again (said it above): if you attempt to provide an "unification" library, you want everybody to be able to use it. If only select software can use it, it's no longer a unifying library, it's just another alternative. And you have FAILED in your attempt to offer unification.

I'll throw my own example in here: I wanted to write a quick script that would pop up a "Touchpad enabled"/"Touchpad disabled" notification. I wasted an hour trying to find out how to change the notification's duration to 1 or 2 seconds, and how to make it stop obscuring more important notifications (like if I lose my connection to the wireless network, etc.).

Then I found this bug report and discovered that those annoyances were _intentional_. What the hell?!

I just wasted some time trying to figure out why what I am doing wrong in passing the timeout parameter to notify-send.

Could you please resolve this bug by updating the man page to tell users, that the timeout parameter does not work with Notify-OSD? That would save people like me from wasting time on this in the future.

/sign

I also wasted a lot of time trying to figure out what's wrong.

Stoto

Sent from my iPhone.

On 2010.06.14., at 10:00, Otto Kekäläinen <email address hidden> wrote:

> I just wasted some time trying to figure out why what I am doing wrong
> in passing the timeout parameter to notify-send.
>
> Could you please resolve this bug by updating the man page to tell
> users, that the timeout parameter does not work with Notify-OSD? That
> would save people like me from wasting time on this in the future.
>
> --
> 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.
>
> Status in “notify-osd” package in Ubuntu: Confirmed
>
> 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$
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/notify-osd/+bug/390508/+subscribe

From back in post #19 by Matthew Paul Thomas: "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."

...so, how does one create one of these instant-confirmation bubbles? Because the reason I've been complaining is because I want to pop up a quick notification in response to a keypress. And if there isn't a way to do that, then why are those three button-pressing confirmations given special treatment while mine aren't?

> ...so, how does one create one of these instant-confirmation bubbles?

The design spec for notify-osd has been linked several times in the comments of this report. I'll paste the link again for your convenience, even though usage questions seem off-topic in a bug tracker:
https://wiki.ubuntu.com/NotifyOSD

The short answer from what i've understood of this whole thing is "Ubuntu dev team creates whatever is allowed to use instant-confirmation bubbles" and us private developers are out of luck. I still want to see if the patch put out will work on Lucid and if so, maybe it can be packaged downstream with my particular derivative (I use linux mint)

Holger seems to get annoyed whenever someone questions the dev teams decision, that's why i didn't post this in the bug thread

 Heather L Van Wilde

"True discovery lies in seeing what everyone else sees and finding what no one else has found"

________________________________
From: Kent deVillafranca <email address hidden>
To: <email address hidden>
Sent: Mon, June 14, 2010 7:57:33 AM
Subject: [Bug 390508] Re: notify-send ignores the expire timeout parameter

>From back in post #19 by Matthew Paul Thomas: "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."

...so, how does one create one of these instant-confirmation bubbles?
Because the reason I've been complaining is because I want to pop up a
quick notification in response to a keypress. And if there isn't a way
to do that, then why are those three button-pressing confirmations given
special treatment while mine aren't?

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

It is incredible. It is as simple as:

notify-send --hint=string:x-canonical-private-synchronous: Hell Yeah

This creates a bubble that is treated like "Brightness", so it stays there for about 2 seconds

The "-t" option is ignored though

@mindoms

I've confirmed this with my copy of Lucid ... seems like a good enough workaround for the use that i had at least.

So the argument about users and their experience, or how you think it should be used goes out the window if developers can and are starting to get around it. In which case you may as well just open it up properly for use. It's confusingly documented that way, and people have requested the change (with decent use-cases).

If you want to set a global timeout across the whole OS, then it's no good having work arounds as mentioned above.

Take a look at other notifiers like snarl, ruby-libnotify, jquery notifications, or even when writing Windows apps it's possible to set a timeout.
Of course they all must be wrong to offer that sort of override.

@mindoms

Not so easy, in fact. If you bring up one of the regular time-out broken message boxes and a synchronous box at the same time, the synchronous box lives for the duration of the broken box, at least on my machine.

This is a happy advancement, though.

I don't know want is happening along the conversation in this 'thread', I'm just posting this to inform everyone who's interested in customizing notify-osd.

-----

Sukochev Roman (Leolik) as a PPA with notify-osd which add the function of reading settings from ~/.notify-osd, and by my recommendation, now it has the patch created by Ankur Nayak, so it provides the timeout option too.

If you want it, just install the PPA: https://launchpad.net/~leolik/+archive/leolik

And if you want a nice way of configuring this notify-osd, install this notifyosdconfig: https://launchpad.net/~amandeepgrewal/+archive/notifyosdconfig

Before I get scolded: You may find that I posted a very similar comment on bug #257135, regarding the lack of access to replaces_id, however this comment is regarding the behavior of --expire-time.

Red_Acid++

Leolik's notify-osd + notifyosdconfig = vastly superior, and faster, messages.

There's still a little funniness with the --expire-time parameter however.

Case in Point: To get messages at the speed of channel surfing, temperature changes, bandwidth use, etc, etc, etc it's necessary to set an arbitrary, system-wide timeout of 1sec with notifyosdconfig (see above PPAs) and set --expire-time < 1000.

This makes a notification which blinks in and out of existence since an expire time of anything less than 1000 is equal to 0. I'd actually like to have messages linger for about 600~800msec, which I figure to be ample time for reading a channel number (and could also be useful for reading many kinds of things that don't need to be studied carefully).

To be precise I want to do this (note the imaginary --replaces_id parameter):

notify-send --replaces_id=tvchannel --icon=gtk-info --urgency=critical --expire-time=750 "Channel $CHANGE" "`ivtv-tune -x $CHANGE`"

The first sentence of the design spec for notify-osd clearly says it should implement the Desktop Notifications Specification.

The first line of the Desktop Notifications Specification says, "The following messages MUST be supported by all implementations." There is no ambiguity.

notify-osd does not use the expire_timeout parameter of org.freedesktop.Notifications.Notify.

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

notify-osd always acts as though expire_timeout is -1. Nothing in the spec says "feel free to ignore this in your implementation", or "developers beware- implementations are free to ignore this and still be called compliant (i.e. don't expect this to actually work)".

Clearly, this is a bug (that it's by choice is irrelevant).

Apps written to be fully compliant with the Desktop Notifications Specification using the expire_timeout parameter have notifications that do not work correctly on Ubuntu. That is _unacceptable_.

@nstenz ... while i hate to back up the Ubuntu developer side in this issue, let me point out a flaw that has been brought up before:

"The first sentence of the design spec for notify-osd clearly says it should implement the Desktop Notifications Specification."

Unfortunately, should != must

Ubuntu, in this case, has decided that even though they should do this, they don't want to.

> The first line of the Desktop Notifications Specification says

In my copy, the first line says that it is a draft (!) document for async event notifications.

> The first line of the Desktop Notifications Specification says,
>"The following messages MUST be supported by all implementations."
>There is no ambiguity.

Yes. Believe it or not, notify-osd does indeed support all these messages, with the same signatures (so all parameters are accepted as well). That says nothing about how it interprets the parameters. (Yes, I know, specs are hard to read.)

Concerning the interpretation of the expire timeout parameter, it's funny that you, while quoting so much from the spec, omitted the central sentence (probably because you didn't like it?): "The timeout time in milliseconds since the display of the notification at which the notification should automatically close."

There's a "should", a recommendation. The spec does not demand that the expire timeout parameter is respected. (In fact, if it did, it would be a fishy spec - an implementation could just as well chose (or offer config parameters to let the user chose) to not display any non-critical messages at all, but just log them to a file. Timeouts of a few seconds don't make any sense in a log file.)

> Nothing in the spec says "feel free to ignore this
> in your implementation", or "developers beware-
> implementations are free to ignore this and still
> be called compliant (i.e. don't expect this to actually work)".

As pointed out before, the spec gives a clear recommendation as to what clients should expect: "Clients should try and avoid making assumptions about the presentation and abilities of the notification server." Obviously, you're not following that recommendation. That's your choice, and also your problem.

Il 07/07/2010 12:02, Holger Berndt ha scritto:

> There's a "should", a recommendation. The spec does not demand that the
> expire timeout parameter is respected. (In fact, if it did, it would be
> a fishy spec - an implementation could just as well chose (or offer
> config parameters to let the user chose) to not display any non-critical
> messages at all, but just log them to a file. Timeouts of a few seconds
> don't make any sense in a log file.)

Is this the case? Is notify-osd specifically intended for file logging?
No, it isn't, so why is a good thing not to follow this recommendation?
After tons of messages still lacks a good answer to this question. And
no, "uniformity" is not a good answer.

> As pointed out before, the spec gives a clear recommendation as to what
> clients should expect: "Clients should try and avoid making assumptions
> about the presentation and abilities of the notification server."
> Obviously, you're not following that recommendation. That's your choice,
> and also your problem.

This has nothing to do with the design choices made in the server, it
doesn't explain why is good not to honor the clients timeout
(independently of the client expectations).

Could you take those discussions somewhere else as requested before? You disagree on the design choices there and don't see the value in having a system working on a consistent way but it's the choice Ubuntu did for its notification system, you are free to use other softwares to replace this one or other system if you decide this one doesn't fit your needs, arguing over and over using the same arguments will not bring any addition value to the discussion

to reply to comments about the notify-send documentation being unclear that's a real bug indeed and there is another ticket which is dealing with this one...

Sebastien- where? Somebody tried to create a brainstorm thread for it, and if I'm seeing things correctly, it was shut down and nobody can vote for it. Correct me if I'm wrong- I've never used the brainstorm site.

There's nothing wrong with the notify-send documentation. It's doing its job- it has no idea that notify-osd is on the other end, ignoring the timeout parameter. The only documentation change that would make any sense is the addition something that says "IF notify-osd is the notification agent (default since Ubuntu x.xx), the timeout parameter is ignored." But why should the documentation for one package have to warn you about deficiencies in another that it might not even be interfacing with?

Il 07/07/2010 23:20, Sebastien Bacher ha scritto:
> Could you take those discussions somewhere else as requested before?

Where?

> You
> disagree on the design choices there and don't see the value in having a
> system working on a consistent way

No, and I'm not the only one. You seem quite sure that the ubuntu team
is always right and the (l)users are always wrong and, being stupid,
can't comprehend the great design behind notify-osd. At the moment I've
never read a word explaining what "consistent way" means and what it is
useful for. Where is the "value"? In what? Where is the value when lots
of people complain about it?
Instead, I already explained why it is much more reasonable, useful and
natural to let the client chose the right (yes, the right) timeout. The
DNS suggests the same.

> but it's the choice Ubuntu did for
> its notification system, you are free to use other softwares to replace
> this one or other system if you decide this one doesn't fit your needs,

Sure, but we are talking about notify-osd.

> arguing over and over using the same arguments will not bring any
> addition value to the discussion

Are you referring at your own messages? Well, this time I agree with you.

> Where

The list where the design is discussed, see comment #95

> No, and I'm not the only one. You seem quite sure that the ubuntu team is always right and the (l)users are always wrong and, being stupid, can't comprehend the great design behind notify-osd.

Nobody said that, the Ubuntu team just decided on a design for Ubuntu without any claim of being right or not, nobody said either that users are wrong or stupid. You could respect the choice of Ubuntu to take decisions on what they are doing, nobody is forcing you to use Ubuntu if you think the decision don't fit your needs either

> never read a word explaining what "consistent way" means and what it is useful for. Where is the "value"? In what?

Consistent means that things are not changing randomly, notifications are always displayed in the same way, for the same time
rather than have a bubble displayed for 1 second, then the next one 15 seconds, then the next one 45 seconds just because the software writers don't agree on what to do

> Where is the value when lots of people complain about it?

Lot of people will complain anyway, what you call lot of is a matter of perspective, it's some vocal users on a bug report, user testing are being made as well and not only on technical communities and some users see value in having a system not acting randomly (why was that bubble displayed 3 seconds and now this one 8 seconds?)

> Instead, I already explained why it is much more reasonable, useful and natural to let the client chose the right (yes, the right) timeout. The DNS suggests the same.

Let's agree to disagree and stop abusing this bug report? Design discussion should be moved to the lists where the people working on notify-osd and doing the design will read it rather on a bug report where you keep arguing with Ubuntu bug triagers who are neither deciding on the design nor coding on notify-osd.

Not sure what DNS have to do with that discussion but DNS have nothing to do with visual design

> Sure, but we are talking about notify-osd.

Right, so change Ubuntu by the notify-osd writers, why don't you accept that whoever is writing code can take decisions on what the said code behaviour should be? If you don't like it don't use it, nobody forces you to use notify-osd or Ubuntu

"If you don't like it don't use it, nobody forces you to use notify-osd or Ubuntu"

Awful message to put across from an open source community based OS, and not really a solution.

I think the middle ground would be different types of duration. Short, Medium, Long. Given 3 options would certainly help and partially avoid developers choosing different timeout durations.

I still don't fully agree though. If an app wants to specify an odd or different timeout, then users will no doubt complain, or not use just that app. Or Ubuntu doesn't have to include it in the default build.

Also the reason I gather for this bug report being abused, is because people have tried to open up other avenues to talk about this and they've been shut down or cut off. This is the only place we can voice our opinion.

Il 08/07/2010 10:54, Sebastien Bacher ha scritto:

> The list where the design is discussed, see comment #95

Fine.

>> No, and I'm not the only one. You seem quite sure that the ubuntu team
> is always right and the (l)users are always wrong and, being stupid,
> can't comprehend the great design behind notify-osd.
>
> Nobody said that, the Ubuntu team just decided on a design for Ubuntu
> without any claim of being right or not, nobody said either that users
> are wrong or stupid.

No, not directly. Ok, so, now, we can finally say that probably the
Ubuntu team is wrong and there are no problem with our comprehension
capabilities. Good.

> You could respect the choice of Ubuntu to take
> decisions on what they are doing,

Sure, but since the Ubuntu team ask for users/comunity support we feel
free to ask and discuss about this behaviour.

> nobody is forcing you to use Ubuntu if
> you think the decision don't fit your needs either

Once again, no doubt, but this is not the right answer to the question
"why fixed timeouts should be better than variable timeouts?".

>> never read a word explaining what "consistent way" means and what it
> is useful for. Where is the "value"? In what?
>
> Consistent means that things are not changing randomly,
> notifications are always displayed in the same way, for the same time

Thanks, that was not difficult to understand. The point is that it makes
no sense, so the use of this word, IMHO, is wrong.

> rather than have a bubble displayed for 1 second, then the next one 15 seconds, then the next one 45 seconds just because the software

Just because some software need short bubbles while some others longer
timeouts? We need this, it's really useful, while having the same
timeout does not significantly improve the user experience.
To do an example, it's like saying that in a car we'd better have fixed
front wheels because they look "consistent"/"uniform" to the rear ones,
while we need them to rotate and steer. It doesn't look very brilliant
and doesn't seem to have much "value".
But still, there are various options available to maintain a sort of
order, for example three different timeouts like bealer said,
configuration options within the server and/or the clients and so on.
Ignoring, always and totally, these possibilities is unbelievable.

>> Where is the value when lots of people complain about it?
>
> Lot of people will complain anyway,

Sure, but there are a lot of differences between a few and a lot,
between reasonable objections and stupid requests. The tone used here
shows that the Ubuntu team cannot see these differences.
Moreover I don't think that common users pay too much attention about
duration, while some power users do it. But we have the chance to make
both happy, so why not?

> Not sure what DNS have to do with that discussion but DNS have nothing
> to do with visual design

I was referring to the Desktop Notifications Specification.

> Right, so change Ubuntu by the notify-osd writers, why don't you accept
> that whoever is writing code can take decisions on what the said code
> behaviour should be? If you don't like it don't use it, nobody forces
> you to use notify-osd or...

bealer, opensource based doesn't mean you can't take design decisions or choices, we could try to fix every applications and blame random softwares installed from the internet for making ubuntu bug or we can enforce some design choices we believe benefit our users and communication to software writers on our design choice and how to well integrate with our system, it's what other very people device makers do for their system as well and users don't complain so much about the limitations since in the end it leads to things working nicely together in a consistent way

> because people have tried to open up other avenues to talk about this and they've been shut down or cut off. This is the only place we can voice our opinion.

did any of you trying the ayatana list as suggested several times now? could you point where you got turned down from posting on it?

The vast majority of people out there don't care about notifications, they don't care about softwares, they don't care about configurations or computer, they want to go on the internet, chat with their friends, etc. They want a system fast, easy to use and visual appeleant. They don't want to understand why some of the messages coming are different or to configure every softwares to behave different, that should just be working on be out of their way. Some of design decision taken in that project and others the dx team is working on will limit flexibility and enforce a consistent and easy to understand interaction. That will limit possibilities for softwares to do weird things and make the system feel buggy, that will simplify code, that will simplify interfaces and that will benefits users in the end. Now some people are very much wanting to have full flexibility and use it, the softwares you used to run are still there and you can still install those if you want, why is that so much of an issue?

"bealer, opensource based doesn't mean you can't take design decisions or choices, we could try to fix every applications and blame random softwares installed from the internet for making ubuntu bug or we can enforce some design choices we believe benefit our users and communication to software writers on our design choice and how to well integrate with our system, it's what other very people device makers do for their system as well and users don't complain so much about the limitations since in the end it leads to things working nicely together in a consistent way"

Of course decisions have to be made, that's what this whole argument is about. People arguing the wrong decision has been made.

Being open source and community based just means people can contribute fixes/patches (as per above), and also give feedback and be involved around these decisions. That seems to be lacking in this case.

Decisions should be based on feedback. In this case from developers and users in terms of experience. At the moment developers are crying out for this feature. We don't know how users will be affected, because I would guess it's not been tried. There's nothing stopping you opening it up fully, and if it becomes abused, updating notify-osd so that timeouts can no longer be specified, or as I mentioned implement a few different levels of duration.

"The vast majority of people out there don't care about notifications"

Then let us set it to whatever we want!

"They don't want to understand why some of the messages coming are different or to configure every softwares to behave different, that should just be working on be out of their way"

They're not inclined to understand in many of the examples given. People have given examples of when overriding would be beneficial and improve user experience.

In the case of the screenshot example, I think the user would be more inclined to think/ "understand" why the notification pops up for so long, or is included in the screenshot (not understanding that the dev that wrote it had no control over it), as opposed to if it came up quickly.

With a notification app, you need to think how it's going to be used. We've defined plenty of use cases above. And from example use cases define an appropriate public interface. Not define how it should work, then try to fit the use cases around it. That's awful design and will either lead to poor user experience in the examples given, or people developing the same thing twice, so that they can open it up more.

> Decisions should be based on feedback. In this case from developers and users in terms of experience. At the moment developers are crying out for this feature. We don't know how users will be affected, because I would guess it's not been tried

That's not true, Canonical does organize user testing sessions and watch non technical users dealing with Ubuntu. We have been using the old notification-daemon which respects timeout settings for years before notify-osd. The complain there come from some technical users or softwares writers not so much from non technical users out there.

> With a notification app, you need to think how it's going to be used. We've defined plenty of use cases above. And from example use cases define an appropriate public interface.

No, the current design is that notifications are unintrusive and just used to get informational content displayed. They are not used to display questions. They are not used to display important informations. They are not displayed when interaction is required.

You can read those wikipages to understand the design principle for those choices:

https://wiki.ubuntu.com/NotificationDesignGuidelines
https://wiki.ubuntu.com/NotifyOSD

The first document describes what other solutions Ubuntu recommends to softwares writers that need interactivity. You might think that using notifications and tweaking the way users interact with it is the only way but it's not. You might disagree on the design described there but give some credit to those who worked on it and read those, you will see that lot of efforts, thinking and real world usecases consideration has been in action and it not a decision made in an hurry to annoy users.

> That's not true, Canonical does organize user testing sessions and watch non technical users dealing with Ubuntu.

Ok cool. I meant more specifically around notify-osd and just notifications but I know there will be a degree of user testing already going on. I also meant on the wider scale. User testing is always only ever a small sample of the user base.

> No, the current design is that notifications are unintrusive and just used to get informational content displayed. They are not used to display questions.

I understand the guidelines, and it's fairly obvious otherwise it wouldn't be a "notification" system if it did more than just notify. "Intrusive" depends on how it's used. I could fire notifications all the time. And informational, well I could just put crap in the message, or put as much text as allowed to fully expand the notification.

The use cases above define a perfectly acceptable instance where it's beneficial to be able to set the timeout, or at least have some finer grained lengths of notification. You're restricting that because you're worried about how people will mis-use it, when as mentioned above, I could totally abuse the notification system anyway. What's to stop me putting questions in, and firing it frequently (there is a limit but 50 but still).

Why not open it up, and like with messages, and frequency, write some guidelines for duration.

Il 08/07/2010 13:49, Sebastien Bacher ha scritto:
> bealer, opensource based doesn't mean you can't take design decisions or
> choices,

Right, but it's still possible to suggest a change or feature and maybe
provide a patch for it (often developers don't spend time in features
they are not directly interested in, but still agree to include features
useful for others).

> we could try to fix every applications and blame random
> softwares installed from the internet for making ubuntu bug

Are you talking about notify-osd? Using something defined in the DNS is
a bug?

> or we can
> enforce some design choices we believe benefit our users and
> communication to software writers on our design choice and how to well
> integrate with our system,

You forget that Ubuntu it's just one linux distribution, not the whole
world. Basically, software developers don't care about notify-osd, they
just create DNS compliant messages, so there's nothing to force.

> The vast majority of people out there don't care about notifications, they don't care about softwares, they don't care about configurations or computer, they want to go on the internet, chat with their friends, etc. [...] why is that so much of an issue?

A simple option allowing the power users to switch from the default
fixed timeout to client defined timeouts is easy to implement and
doesn't disturb anybody that might not care.
"why is that so much of an issue?". But once again you won't reply.

> option allowing the power users to switch from the default fixed timeout to client defined timeouts is easy to implement and
doesn't disturb anybody that might not care. "why is that so much of an issue?". But once again you won't reply.

There is no strong reason to not accept such changes out of the fact that extra code means extra bugs and the notify-osd team could not be wanting to deal with those. You can as well install the modified version somebody did in a ppa if that's personal use or reinstall notification-daemon from universe.

I feel compelled to comment again. I agree that tiered timings seem like a good compromise between uniformity and flexibility for developers. The current timing has led to my disabling notifications in several applications, but really it's more than the timing. It's a coupling of timing and location:
Inability to customise timing makes a potentially inconvenient placement worse.
Inability to customise location makes a potentially inconvenient timing worse.

I think there's general agreement that notifications are useful to people and that the present system is transient in favour of a future, better solution. Thinking well inside the box here, it seems as though customisable timing represents a less arbitrary option. That is, placement is something coders probably don't care about and something non-coders can adapt to. Timing is something that coders do care about and something which can, if used appropriately, improve a user's experience.

Tiered timing (short, medium, and long-duration messages) provides a means of enforcing a degree of timing uniformity while allowing that flexibility.

I'll now install that Leolik PPA.

That leolik ppa and notifyosd config is awesome. It's this microsoft attitude of "We will tell the users what they want and they will like it" that turned me off of windows to begin with. I don't know why ubuntu would want to cripple their OSD notifications like they have. How hard is it to just add a gui program to control all of this stuff like the ppa has done?

I have considered switching to debian, but I am not sure how close they are to ubuntu? Does debian have the ability to use proprietary hardware drivers like ubuntu does?

The only extra thing I would like to see in the notify osd config is the ability to have the notifications "add" themselves to the screen as default rather than queue themselves behind whatever is currently on the screen. This way, if you have a bunch of apps that are sending messages at once, you won't have to wait through a long line of bubbles.

Il 08/07/2010 17:22, Sebastien Bacher ha scritto:
>> option allowing the power users to switch from the default fixed timeout to client defined timeouts is easy to implement and
> doesn't disturb anybody that might not care. "why is that so much of an issue?". But once again you won't reply.
>
> There is no strong reason to not accept such changes

But we are still discussing...

> out of the fact
> that extra code means extra bugs and the notify-osd team could not be
> wanting to deal with those.

Which bugs such change could hide? We are talking about few lines of
code... This is the usual excuse for not doing so, otherwise we should
stop software development due to possible bugs introductions or
regressions. The point is that the Ubuntu team reject everything that is
not coming from themselves, right or wrong it doesn't matter.

Has anyone sorted this bug out?
This bug is really bugging me and buggy software ought to be debugged.

Seems that this Bug report has gone quite since the last time I was here. Well, if anyone is interested, someone has come up with a work around. They re-wrote the source code for notify-osd. Feel free to try it out...it works rather well. :-)

http://www.webupd8.org/2010/07/patched-notifyosd-updates-option-to.html

Yeah. People pointed out a number of situations where the fixed timeout is counterproductive (for both users and developers), and got nothing back but "the decision is final, move to another distro if you don't like it."

So I think everyone gave up arguing with a brick wall and installed the patched version of notify-osd. Or moved over to Fedora. Or something.

This is a drama. I get really sad reading all this. This thread more then proves that there is a bug in notify-osd. Even if it is correct by the orginal design, this is still a bug. In that case we speak of a usability bug. Please fix it and stop sending people away from Ubuntu. Just because you cannot omit to a all-in-all small mistake. The biggest mistake of all being that we are not even allowed to vote on the matter. When people are given power however small and however well intended they are they will at some point abuse that power. That's what the ubuntu-dev's are doing here. This thread really goes through my heart. It rattles and shakes my believe in the Open Source philosophy.

In conclusion use the PPA... And keep a eye out for an other distribution.

Just installed the patched Notify OSD to get around the lack of options in the "official" build.

I'm very concerned about a noticeable trend in recent releases of Ubuntu. It seems highly impactful design decisions are being made that are contrary to the philosophies of open source software.

I have used Ubuntu for years and been extremely happy with it until recently. There were a number of occasions that made me consider switching away:

 - when I realised that the Volume and 'Me Menu' shared the same icon group and could not be removed independently;
 - when I realised how utterly useless the Me Menu actually was;
 - when I realised that bad design decisions were being made centrally against all consensus (the left-aligned window buttons);

The Notify OSD issue is another decision that has no design merit and only serves to distance experienced developers.

These are all starting to make me feel that the direction that Ubuntu is taking is no longer for me.

Design Guidelines should be just that - guidelines, not strict rules. Guidelines can be interpreted to ensure that developers can create exciting new software whilst sticking to the ethos of the guidelines. To actively deny the ability of developers and designers to interpret guidelines by removing functionality (that's what this is) is a Closed ethos.

Distrowatch, here I come.

Kevin

The open source "philosophy" has nothing to do with configurability, options, or features. I wonder where that idea comes from.

I think what he was getting at is that the open source philosophy is supposed to be about the will of the people, instead of the will of a select few from some corporation who seemingly know better and change things for no reason against what the majority of users want.

Question- according to the notification design guidelines (https://wiki.ubuntu.com/NotificationDesignGuidelines), those of us who want to use notify-send's timeout option should be using something like a "morphing alert box".

Would it be possible to spit out one of those instead of a NotifyOSD "bubble" when notify-send has a timeout specified? Then you wouldn't have to "pollute" NotifyOSD with the naughty timeout code, but at least notify-send would be able to work properly.

I know notify-send just sends a message out over DBUS and I believe there can only be one notification server on the other end, so I'm guessing the answer is "it's not technically possible".

Could anybody be kind enough to offer up a simple command like notify-send that displays a "morphing alert box" instead of a notification bubble?

Ok, I've read through this whole thread and I've got to side with the pro-custom-timeout people. This is friggin ridiculous. Here's another use case at the opposite end of the spectrum from most of the above:

I have a perfectly good script built around notify-send I was using on Gentoo. It worked fine there with whatever DNS-compatible notification daemon I had installed (obviously not NotifyOSD). It's short and simple - it just watches the log file for a local application server and notifies me when it has stopped or started.

Build, deploy and server restart cycles can take quite a long time - often 10-20 minutes plus. During that time I might wander away, or start doing something in another window, but I absolutely do not want to miss that notification. If I leave for 5 minutes and the server finishes restarting while I'm gone I want that notification to still be visible when I get back. So my notify-send call specified a pretty long duration (around 10 minutes). This was practical because whichever (superior) notification system was installed also allowed the user to close notifications early after they'd been read.

I switched over to Ubuntu a couple weeks ago because I've been running it on my wife's machines for months and it's grown on me. I've been pretty happy with it overall - definitely some annoyances but Googling and liberal use of gconf have generally been enough to work around them. But I'm trying to get back up to functional parity with what I had in Gentoo, particularly work-related stuff like this monitor, and I've been banging my head against this bug/deliberate gimping for hours.

I've installed the patched version of NotifyOSD from the PPA mentioned above, and it did take care of the timeout issue. But there appears to be no way for me to kill the notifications before they naturally expire. So I either run a very good chance of missing the notifications, or I see them and then they're stuck in the corner of my screen for ten minutes with no way to clear them. Not going to work.

Several times in this thread it's been suggested that if you don't like the way NotifyOSD works you should install something else. That's a pretty ridiculous thing to suggest to developers planning to distribute their code, but since this is just for my personal use, fine. There seems to be a problem with that approach though - Synaptic won't let me uninstall notify-osd without also removing ubuntu-desktop, which seems like a pretty significant package.

It seems like only one of these notification daemons can run at a time (which makes sense if they're all reading the same D-Bus messages). I tried installing notification-daemon without removing notify-osd and the system just keeps on using the latter. So I'm very confused as to what I'm expected to do at this point.

If the Ubuntu devs truly think their "alternate interpretation" of the DNS spec is actually in line with the spec, then why wouldn't I be able to swap out their daemon for any other compatible daemon and still have ubuntu-desktop work? If ubuntu-desktop is transmitting proper messages based on the spec then anything else should be able to display them, right? Otherwise I don't see...

Surprisingly there's no way to go back and edit these comments after posting (that I can find, anyway) and my questions won't help me much if they're hidden behind a click-through, so here they are again:

Does anyone know if:

- there's something I can manually edit to remove this dependency so I can switch to notification-daemon and still keep ubuntu-desktop?

- there is a way to run both NotifyOSD for ubuntu-desktop and notification-daemon for notify-send at the same time? Some way of telling notify-send to use an alternate D-Bus channel to connect with notification-daemon or something?

- there is some other simple command to fire simple messages that actually works in the way I want? I don't care if these notifications blend in seamlessly with Ubuntu's. I just want something that will pop up, not steal focus, expire when I decide it should, yet let me manually close it early. Bear in mind this is an extremely basic script.

This whole situation is disappointing. The beauty of the notification spec combined with notify-send is that throwing a nice looking GUI notification is no harder than echoing text to the console, and is just as cross-distro. Or at least it was up until this point.

> That's a pretty ridiculous thing to suggest to developers planning to distribute their code

If you plan to distribute something, you'll have to live with the lowest-common-denominator problem, and cannot rely on implementation details. Just like everywhere else.

I don't see how it's ridiculous to recommend to use the tools that suit you the best. On the other hand, I find it pretty ridiculous to actually try to force your idea of good design to every single project out there, although alternative implementation do already exist.

> there's something I can manually edit to remove this dependency
> so I can switch to notification-daemon and still keep ubuntu-desktop?

You seem to misunderstand the role of the ubuntu-desktop package. It's just a meta package that does nothing more than reference other packages, and brings you a default ubuntu desktop. You don't loose anything by not having that installed, and in fact you cannot have it installed if you want to remove referenced packages. There's nothing in that package except dependancies.

However, you may very well have multiple daemons installed. In that case, the choice of deamons is made by normal D-Bus activation; in this case the system wide config file is /usr/share/dbus-1/services/org.freedesktop.Notifications.service

My two cents:

I found this bug because I noticed that notifications were ignoring my timeout on a script I was writing.

Since this discussion seems to be pretty abstract, I'll provide a concrete usage case. I'm a 4th grade teacher and I use a projector hooked up to a tablet pc. Normally, I have a jar with Popsicle sticks on which I've written the names of my students. I pull a Popsicle stick to ensure that I'm calling on them randomly. This year, as I gear up for a new school year, I decided to write a script that pops up a random name from a list of my students. I tied it to an application launcher icon. It works.

At first I was using a zenity info box to display the name, but it's ugly and requires you to click okay to dismiss it. This seems like a good case for a notification bubble to me. Because I'm expecting it and it only contains a student's first name, it doesn't need to stay on the screen for long. Also, it's important that it doesn't, because notifications are queued and if someone is absent, I need to be able to get another name quickly, so we're not all sitting around waiting for the bubble to disappear. I ended up using the:

<code>notify-send --hint=string:x-canonical-private-synchronous: "message"</code>

solution listed above, which is fine.

But I feel like my case sort of underlines the point made by many people above. I spent twenty minutes messing around with the timeout argument, because, as a user, I expect command line arguments to work (I wasn't really aware that notify-send was a separate component from the notification system itself). Then I found this thread. Then I had to read through most of it to find an undocumented solution to my problem.

I wish that it just respected the timeout argument.

Add my name to the protests.

I applied Red-Acid's (#126) recommendation: both PPAs. It makes all the difference between a disrespectful and a respectful user experience -- dozens of times/day.

The current behaviour of notify-osd, ignoring the timeout option, is unacceptable. I'm not even going to bother repeating any of the arguments presented in this thread.

Hi! I found this bug because I saw that notifications were ignoring my expiration time too (using dbus).

About the option: notify-send --hint=string:x-canonical-private-synchronous: "message"
Has an error, try this: The terminal with 2 tabs:
In time order:
- Tab1:
  notify-send "Message"
- Tab2 (while bubble of tab1 is showing):
  notify-send --hint=string:x-canonical-private-synchronous: "message1"
  notify-send --hint=string:x-canonical-private-synchronous: "message2"
The error is: You will see "message1" while "Message" persists, and you'll lost "message2" notification.

I think the expiration time is important for some applications.
Best regards.

Well, another:
  notify-send --hint=string:x-canonical-private-synchronous: "message1"
  notify-send --hint=string:x-canonical-private-synchronous: "message2"
in the same time, you will lost "message2"...

I just wasted a lot of time trying to figure out why neither the -t nor --expire-time options were working.

This bug has been around for 1.5 years. It's confirmed with nobody assigned to fix it.

Ridiculous.

same thinking as remitaylor...

Change manpage or do what manpages says...

Anyway, you already miss the objective of having one consolidated osd notification tool: I quit osd_notify to older tools!

+1 for fixing this to respect timeouts.
After reading through these comments I can't believe Ubuntu devs are being so stubborn.
I always believed in Linux and being able to configure things and here I am being blocked.
This sucks. Better to take this out of Ubuntu then force us to live with it.
Thank you for the Leolik PPA - I'll be using that.
And hoping the devs get their sights re-aligned someday.

Maybe there should be a party for the imminent second anniversary of this report.

The foregoing feedback should suggest that there is no basis for determining how best to hard-wire the expiration time of pop-up notifications. Attempting to do so arbitrarily limits the usefulness of the service, since its behaviour will often be inappropriate to the context.

Just one concrete example:

A popular use of notify-send among programmers is to present pass/fail results from automated tests that are invoked when a changed source file is detected. A notification that is welcome and useful when it appears for 2 or 3 seconds becomes annoying and intrusive when it insists on hovering for 10 seconds.

Moreover, it seems to happen for no apparent reason because many people are relying on documentation for notify-send. Thus they encounter behaviour that's unexpected, resulting in confusion and wasted time. I'm just the latest in a long line of people who had to research this issue, eventually finding my way here to protest. One wonders how many man-hours have been similarly squandered.

I think if you added up all the man-hours wasted by people trying to figure out why the timeout parameter had no effect you'd have enough to just develop a new distro from scratch. And that's not even counting the additional hours spent by those who got as far as this bug, found the "answer", and then went on to spend even more time coding up some kind of workaround.

Honestly, if the Ubuntu devs are so sure that they're the best arbiters of how long a notification should display, fine. Make ignoring the timeout the default notification behavior for the system. But for the love of God, leave some deeply buried configuration option in a text file somewhere so that those of us who trust the application's sense of timing more than yours, or are just hacking around with something for our personal systems, can turn it back on. There is zero reason not to do that, other than the sheer joy of being a controlling jerk.

@Mike Hartman: I told you already in comment #158 where that "deeply buried configuration option in a text file somewhere" is that lets you choose your notification daemon.

I'm not asking for an option to change the daemon, I'm asking for an option to change the behavior of the existing daemon. Changing the daemon has more side effects than just fixing this one issue - it changes the look of the bubbles. If the goal is to get everyone using this new daemon, forcing us back to the old one isn't the way to do it.

That was the option I ended up taking when I first encountered this issue, and it was suboptimal. I've gone through a couple machines since then and the original use case doesn't apply anymore. I've learned to do without the convenience of having personal scripts send me feedback via notifications because Ubuntu made it such a pain.

What I'm asking for is pretty simple - it's replacing a constant in the code with an "if" clause and a configuration check. It's not something an application can force (since Ubuntu is trying to protect us fragile users from inconsistency). It's a choice the user would have to go out of their way to make. I'm suggesting burying it someplace obscure so new users wouldn't be likely to find it, get confused by it or accidentally enable it.

I just don't understand this trend in Ubuntu to completely remove customization options. Pick the defaults you think are best, fine. Hide the complexity from new users, fine. Make it next to impossible for more knowledgeable users to get their system working the way they want it to? Why? How does that benefit Ubuntu? It feels more Apple than Linux.

Anyway, I'm not going to continue this debate with you - it seems to be pointless and it's getting increasingly difficult to avoid swearing. There are something like 40 people complaining about this behavior in this bug, and only a couple people defending the status quo. But clearly we're all just unreasonable.

Don't forget, people, this bug has been moot for a long time, thanks to leolik's excellent PPA - https://launchpad.net/~leolik/+archive/leolik - which makes notify-send do what we need it to do!

Still, it's good to see more people arguing the merits for this bug report.
It means we're not crazy.

Sent from my Android powered HTC Desire smartphone.
On Jun 6, 2011 7:30 PM, "Hugh Morris" <email address hidden> wrote:
> Don't forget, people, this bug has been moot for a long time, thanks to
> leolik's excellent PPA - https://launchpad.net/~leolik/+archive/leolik -
> which makes notify-send do what we need it to do!
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/390508
>
> Title:
> notifyOSD ignores the expire timeout parameter
>
> To unsubscribe from this bug, go to:
>
https://bugs.launchpad.net/ubuntu/+source/notify-osd/+bug/390508/+subscribe

@Mike Hartman: I don't see anyone forcing you to do anything. I was merely suggesting a way to solve the problem you and others here seem to be facing. Clearly, you're not interested in selecting a suitable daemon out of the many that exist - including a modified notify-osd ppa that does exactly what you want. Instead, you insist on forcing your own oppinions down on other people's projects (which makes me wonder who the real "controlling jerk" is).

I agree to Alex Santic though that the man-page should be updated to reflect that the notifications may not appear exactly as requested by notify-send. Timeouts are just one aspect that may be affected. Other daemons may choose to not display the message at all, or delay it, or whatever. Relying on the manpage and wasting lots of time searching for the reason is unfortunate.

Holger - what you say below about being the "controlling jerk" - I consider
that an insult. If you don't want to change the way the daemon currently
works because that's your project and you do as you please without regard
for (at least some of) the users' satisfaction with it, fine, I can
understand that. Trying to convince us that it's the right way to do it and
it benefits anybody - that's an insult. A default means one of many options
that is pre-selected for the user; in this case, there's only one option, so
this is not a default, it's just 'cause somebody wants it that way, blindly,
Apple-style. There's no real reason why forcing a fixed expiration time will
benefit anybody. Stop claiming that, at least have the decency to admit that
you just want it that way period.

--
Support Wikipedia <http://wikimediafoundation.org/wiki/Donate/en>

On Mon, Jun 6, 2011 at 11:13 PM, Holger Berndt <email address hidden> wrote:

> @Mike Hartman: I don't see anyone forcing you to do anything. I was
> merely suggesting a way to solve the problem you and others here seem to
> be facing. Clearly, you're not interested in selecting a suitable daemon
> out of the many that exist - including a modified notify-osd ppa that
> does exactly what you want. Instead, you insist on forcing your own
> oppinions down on other people's projects (which makes me wonder who the
> real "controlling jerk" is).
>
> I agree to Alex Santic though that the man-page should be updated to
> reflect that the notifications may not appear exactly as requested by
> notify-send. Timeouts are just one aspect that may be affected. Other
> daemons may choose to not display the message at all, or delay it, or
> whatever. Relying on the manpage and wasting lots of time searching for
> the reason is unfortunate.
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/390508
>
> Title:
> notifyOSD ignores the expire timeout parameter
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/notify-osd/+bug/390508/+subscribe
>

@Holger - one of the points that had been brought up before is that yes, an individual can change the daemon or use the PPA, but what about those who make programs for redistribution (i.e. through Canonical). If you use the standard prerequisite of notify-osd than a new user will have a broken program because they're using the stock Ubuntu version, not the PPA version. If you choose to use a different daemon instead of notify-osd, then everything in your OS gets changed to the old daemon, and that will likely break other programs. So things left as they are now, new users will end up in a situation where they have unmeetable dependency issues, and they'll just say "oh, well, I guess I won't use this program, it hasn't been developed enough to where it's useable, and blame the third party developer instead of the OS dev team

@Adrian Roman:
> what you say below about being the "controlling jerk"

What you might have not realized is that this phrase was a quote from comment #168. But I'm glad we agree that this is not a nice way to communicate.

The point is: If somebody agues that "if developers for project xy don't add feature A or option B, they are controlling jerks" (or dictators, interface nazis, or whatever insult is in vogue lately), then the one trying to dictate is actually the user, not the developer.

> you just want it that way period

It's irrelevant what I want. What you might not realize (although I said it several times, e.g. in comment #99) is that I am not one of NotifyOSD's designers. I am also not one of its developers. Those are the ones that you should try to convince.

Frankly, I've lost interest in keeping track who is the developer, designer
or bug reviewer for this piece of software. You could even be a regular user
who happens to like the decision taken by the Ubuntu designers. It's not
that relevant. As long as you are the one claiming this whole situation is
"ok", it's you I'm replying to.

The point is: If somebody agues that "if developers for project xy don't
> add feature A or option B, they are controlling jerks" (or dictators,
> interface nazis, or whatever insult is in vogue lately), then the one
> trying to dictate is actually the user, not the developer.

This at least makes a fragile attempt at justifying the design decision with
the right of the developer to do whatever he or she pleases (which is better
than "it's best for you, believe it").
But how about we rephrase this: "if developers for project xy remove feature
A or option B (because they don't like their users using them), they are
controlling jerks". Sounds better, doesn't it?

--
Support Wikipedia <http://wikimediafoundation.org/wiki/Donate/en>

On Wed, Jun 8, 2011 at 3:13 PM, Holger Berndt <email address hidden> wrote:

> @Adrian Roman:
> > what you say below about being the "controlling jerk"
>
> What you might have not realized is that this phrase was a quote from
> comment #168. But I'm glad we agree that this is not a nice way to
> communicate.
>
> The point is: If somebody agues that "if developers for project xy don't
> add feature A or option B, they are controlling jerks" (or dictators,
> interface nazis, or whatever insult is in vogue lately), then the one
> trying to dictate is actually the user, not the developer.
>
> > you just want it that way period
>
> It's irrelevant what I want. What you might not realize (although I said
> it several times, e.g. in comment #99) is that I am not one of
> NotifyOSD's designers. I am also not one of its developers. Those are
> the ones that you should try to convince.
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/390508
>
> Title:
> notifyOSD ignores the expire timeout parameter
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/hundredpapercuts/+bug/390508/+subscribe
>

> Sounds better, doesn't it?

No, it does not. At least not to me. If you think talking to people like that is good, we'll see how far that gets you. Good luck.

Ankur, your patch works PERFECTLY. Thank you so much!!!!!

Ankur Nayak (ankur-iit) wrote on 2009-11-23: Re: notify-send ignores the expire timeout parameter #37

In case anyone wants the latest package ready to install...
On a side note: I changed the default timeout to 5s heh heh

Thanks to Ankur Nayak (ankur-iit) for the patch.

@Holger Berndt
> The point is: If somebody agues that "if developers for project xy don't
> add feature A or option B, they are controlling jerks" (or dictators,
> interface nazis, or whatever insult is in vogue lately), then the one
> trying to dictate is actually the user, not the developer.

Of course the user is the dictator! What's the use of a piece of software that nobody wants to use?

@André Ramaciotti:
> Of course the user is the dictator! What's the use of
> a piece of software that nobody wants to use?

In all fairness, with FOSS things are a bit different. Users take second place to developers (or other types of contributors), because someone who is contributing is more important to FOSS than a simple user. Unlike commercial software, it often happens to have just the devs use the software. It's the old "put up or shut up" approach.

[On a side note, Ubuntu is not exactly your average hobbyist-only distro. It simply cannot afford the "my way or the highway" position, not if it wants to hold on to what it achieved so far.]

But that is a moot point. The core of the issue is refusing to provide access to certain functionality via API because the Ubuntu team doesn't believe 3rd-party devs can possibly make good usability decisions. (Leaving aside the fact that attempting to force usability issues by crippling the API is quite silly.)

So lets be very clear about this, it was never about end users except in a very roundabout, fuzzy way. It's mainly Ubuntu devs vs 3rd-party devs and power users who write DIY desktop tools.

I read the whole story all 182 comments, by now, but:

It's ridiculous that this inconsitency between man page and real functionality is still in 11.04. This is again an indicator that ubuntu tries to copy MAC OSX which also forces their users to "what's best for them". Maybe DRM is also a good idea, or that you need an extra app for shitting in the woods!

BTW: what a infantile debate between USER and DEVELOPER, boundaries are fluid!

here's a workaround to clear all past notify-send 's and apply a smaller timeout for current notification (warning: notifications will indeed be lost this way).

i simply wanted scripted notifications quick and dirty w/o accumulation... i'd prefer another solution, but after wasting too much time because of that "man notify-osd" dysfunctional -t reference i'm satisfied for now with below hack.

#!/bin/bash
#one-second-notify-send.sh
pkill notify-osd #shoot the messenger
notify-send $1 #this will start notify-osd again...
sleep 0.1 # habit
NPID=$(pgrep notify-osd) # grab current notify-osd process ID
sleep 0.9
kill -9 $NPID #shoot the messenger again, but only if instance we caused
#eof

For those proposing the man pages change to reflect the actual behavior of notify-osd, consider this: notify-send works exactly as advertised under xfce4.

>>wirespot

this is not true: "users take second place to developers"

I think you meant to say

"many of the users are also developers"

Sometimes it seems the reverse is true. Many developers are also users.

@Tim D, thanks for the hack! ;)

Changed to confirmed for the 100papercut too.

it's not a usability easy bug, it's a design decision

"bealer, opensource based doesn't mean you can't take design decisions or choices, we could try to fix every applications and blame random softwares installed from the internet for making ubuntu bug or we can enforce some design choices we believe benefit our users and communication to software writers on our design choice and how to well integrate with our system, it's what other very people device makers do for their system as well and users don't complain so much about the limitations since in the end it leads to things working nicely together in a consistent way"

@Seb of course you have to make design decisions, that's part of software development. From the look of all the responses, people turning away from or hacking the notifications, I would say it's a poor design decision or one that needs to be reviewed. Especially if you want to encourage development in the community.

One could argue that developers will go off and use other notification systems which in itself means less consistency. Exactly the thing you were trying to stop.

Developers are putting forward examples and reasons why they would like a more granular timeout. Some good, some bad. But it's such use cases that should contribute towards making a design decision.

What would be interesting to see is the research and reasoning behind the current design decision. How do you know one length of timeout for all things benefits the user, or was it a decision plucked out of the air?

Simplest fix, at least correct the documentation then I bet you'd end up with a lot fewer comments here!

I was going to check this bug's ranking by searching launchpad by "number of comments".

Unfortunately that feature of Launchpad is broken!

Is this really something for the Wishlist?

There are already plenty of forum posts and blogs recommending to just do away with notify-osd because of this and other "design decisions" that really don't seem to make much sense or be worth stubbornly supporting.

> the look of all the responses, people turning away from or hacking the notifications, I would say it's a poor design decision or one that needs to be reviewed. Especially if you want to encourage development in the community.

well, that's if you consider that less notifications is an issue, I would rather consider it as a feature (but that's my personal opinion) we get enough "notification spam" without encouraging every software writter to add some ;-)

> Simplest fix, at least correct the documentation then I bet you'd end up with a lot fewer comments here!

yes, agreed we should at least fix the documentation

> well, that's if you consider that less notifications is an issue, I would rather consider it as a feature (but that's my personal opinion) we get enough "notification spam" without encouraging every software writter to add some ;-)

I agree that spamming is a bad thing. I just think Ubuntu's policing of it is a bad design decision.

Fewer notifications is a lose term. I can easily abuse the current functionality and keep triggering notifications. I just can't have them disappear as quickly as I might like, ie it doesn't respect the timeout.

So the system can currently be abused as it is.

Ubuntu is free to choose what software makes it into the build. If something is abusing the notification guidelines, it doesn't make it into the build. Simple. Beyond that let the users police what software they use. If something is spamming them constantly with notifications, they'll remove it, or write a bug report or not install it in the first place!

But as stated in many cases above there are clear cases where a shorter or longer timeout would give improved usability.
Option 1 - A middle ground, short/medium/long would give some flexibility while maintaining a consistent experience.
Option 2 - Let developers use what timeout they want but supply guidelines. Ubuntu picks the apps for the build for a consistent user experience that follow the guidelines. Beyond that if a user installs an inconsistent app, that is up to them. I may install Amarok yet it has a completely different UI to everything else in Ubuntu. And I can remove it if I don't like it.

>Fewer notifications is a lose term. I can easily abuse the current functionality and keep triggering notifications. I just can't have them disappear as quickly as I might like, ie it doesn't respect the timeout.

Indeed. Canonical's policy does nothing to affect the number of possible notifications.

This "feature" serves only to limit the functionality and convenience of notifications.

How clearly do I have to say this?

There is nothing good about ignoring the timeout parameter.

There is no logical reason to ignore the timeout parameter.

If we are going to use notifications at all they must acknowledge the timeout parameter.

Okay, this affects me too. I depend on the expire timeout parameter for the same reason as another developer noted. I have my own scripts that notify me of interesting things through notify-send (with a 10 minute expiry, for example). I like the luxury of making myself a cup of tea and returning to my computer, confident that my notifications of interest will still be there, ready to be dismissed with the click of my mouse.

My workaround is to:

1. Uninstall and forget about notify-osd and notification-daemon
2. Install the sensible and reasonable xfce4-notifyd, which respects the expiry timeout
3. You may have to pkill notify-osd to really get rid of it.
4. You'll know it's working when you notify-send and you get a strange looking grey notification.
5. Run xfce4-notifyd-config and select the Smoke theme to make it look better

And, if you're running xmonad, you'll need step 6 because for all its merits, xfce4-notifyd seems to grab the focus when it appears. Not only that, but it's only visible on the current workspace, whereas I want to see it on all my workspaces, as was notify-osd's behaviour. For this, you need to tweak your xmonad.hs

import XMonad.Actions.CopyWindow

....

myManageHook :: ManageHook

myManageHook = composeAll [
    className =? "Xfce4-notifyd" --> doF W.focusDown <+> doF copyToAll
    ]

... etc... Haskell is tough. You may have to adapt this to your specific xmonad.hs file, but that's the idea.

I don't understand why such a silly limitation is hard coreded into a utility that other developers are supposed to use. Is there a better place we can appeal this decision? Timeouts ought to be controlled by apps and if apps abuse them, it should be brought up with the app developer. Is notification spam really such a problem that this is necessary?
It seems like a solution in search of a problem that doesn't quite exist

I also like to appeal this decision.

I would like to set a short time, because I use notify-send for displaying my code test results....

notify-send, like any other program, should and must behave as described in its man-page! Please, make the timeout-parameter work as expected.