xfc4-volumed doesn't set a timeout for its volume notification

Bug #888673 reported by Erkki Seppälä on 2011-11-10
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
xfce4-volumed
Undecided
Unassigned

Bug Description

xfce4-volumed's notifications stay on the screen for a wayy too long time (if otheres don't experience this issue, perhaps it's a libnotify variation, but currently volumed seems to be just using the default).

After some tries, I decided that a one-second timeout should be sufficient for volume changes. Attached is a patch that does just that.

Steve Dodier-Lazaro (sidi) wrote :

There will not be any timeouts in my notifications (if you want to make me change my mind on this, please come up with arguments of why it's preferable and with a plan to allow modifying the decided timeout for people who need it).

As far as I'm concerned, the notification daemon should provide methods for choosing the duration of the notification depending on the average time required to read it (ie. text length, difficulty of the text, information conveyed by the image), and also based on how well users can read the text (internationalization and accessibility issues).

I'm willing to help you define such things if you provide a first effort (I'm limited on time), but I won't impose an arbitrary value on my users (I don't want to receive bug reports asking me to remove this fixed timeout in a few months).

Changed in xfce4-volumed:
status: New → Won't Fix
Steve Dodier-Lazaro (sidi) wrote :

PS: you are totally free to distribute this patch to whoever you want, however! :) You can also give me a patch where an optional value can be set by the user and where the absence of such value lets the notification daemon choose the duration. I may accept it! :)

Erkki Seppälä (flux-inside) wrote :

Well, it depends on the contents of the notification how long it takes one to read it, and when it becomes an annoyance.

How long does one need to read a volume bar to determine the volume? How surprising will the user be to see the notification anyway, given that in the majority of cases it was the user who adjusted the volume in the first place? While I agree it would be optimal for the daemon to choose the best timeout, I doubt that is feasible in the general case (ie. client-provided bitmaps) without an extremely smart algorithm. In the meanwhile, a client-provided timeout would be a good approach.

A customizable timeout would be preferable, but basically that was the patch I applied to my xfce4-volumed and figured it wouldn't hurt to post the patch ;-). However, I cannot see why anyone would ever want to have that notification over their movie for a period longer than two seconds and definitely not for 10 seconds, which is the xfce4-notifyd default. (The patch used one second as the timeout, which appears to be the same as the notification timeout of for example mplayer.)

If I get a sudden urge to contribute more, I'm sure to post a follow-up patch ;-). People interested in the current patch can just get it from this bug tracker.

Steve Dodier-Lazaro (sidi) wrote :

Well, I think the problem then comes from the xfce4-notifyd default not taking into account information such as text length! Of course, an ideal scenario would be that in the specification we can give more accurate information about the content of the notification and the context (feedback vs new information). I don't want to force a behaviour in my application because it doesn't seem like the right way to me.

Now, if I get enough complaints, I may start doing something about it, but so far I'm not moving from my position! Thanks for your patch and comments, however.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers