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
> 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<https://launchpad.net/%7Eayatana>>
> with details.
>
> ** Changed in: notify-osd (Ubuntu)
>        Status: Triaged => Won't Fix
>
> --
> 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.
>