Comment 23 for bug 390508

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