Comment 89 for bug 390508
Revision history for this message
| Marco Chiappero (mchiappero) wrote Re: notify-send ignores the expire timeout parameter | #89 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
> 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.