Ted, I'm cc'ing you on this because of the app developer interface issues it raises. Mirco, your comments would be valuable too.
An obvious solution to the apps-that-spew-notifications problem is to encourage the app developers to keep track of notifications and use appends / replaces more efficiently. You give a good example, of a music player that has a user skip through a series fo tracks very quickly. It makes sense for the app to say "hey, I put a notification on the queue, and I replace it with the latest playing track whenever that changes, till it dies". That way, once it gets displayed it's current (and can even be updated during display, extending its life). At least, that makes sense to ME. Ted however feels that it's too much to ask of developers to track their notifications. That drove some of the design on the interface to appends, it's possible to do appends as a series of notifications tagged "append please". Does anyone want to look at the additional complexity required to make the music player behave that way? It would put a notification on the stack and then update it rather than putting new ones out there, till it died (after which it would put a new one on there if the track changed). Mark -- design problem? infinite wait for long queue https://bugs.launchpad.net/bugs/334809 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
