@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 subscriber
> of the bug.
>