>> It's unlikely that developers have a problem understanding that the >> timeout only applies to a specific kind of notification. > Being explicit rather than implicit avoids misunderstanding and > possible "false-positive" bug-reports due to that.
I agree with that sentiment, but think it's the wrong trade-off with regards to simplicity. We already have precedence for snap decisions behaving differently when using the standard API (for example, snap decisions must have at least one action and they're the only notification type that can be cancelled). Did we see many bug reports from confused developers for that? >> Adding additional hints only increases the complexity of the API and >> makes it harder to switch between different kinds of notifications. > By design every introduced notification-type serves a very > specific purpose, that differs in behaviour, visuals and interaction. > Thus switching between different notification-types is not a common > thing to do for a developer, unless UX-requirements change later on. UX requirements change all the time. Also, just because it's not common doesn't mean we need to make it difficult. I'll stop arguing about this though if you feel strongly about it. I don't think we'll be using this API for much longer anyway. -- You received this bug notification because you are a member of DX Packages, which is subscribed to unity in Ubuntu. Matching subscriptions: dx-packages https://bugs.launchpad.net/bugs/1295762 Title: snap decision timeout needs to be determined by the requesting app Status in Network Menu: Fix Released Status in Telephony Service: New Status in Ubuntu UX bugs: Fix Committed Status in Unity: Invalid Status in Server and client library for desktop notifications in Unity: Confirmed Status in “indicator-network” package in Ubuntu: Fix Released Status in “telephony-service” package in Ubuntu: New Status in “unity” package in Ubuntu: Invalid Status in “unity-notifications” package in Ubuntu: Fix Released Bug description: Problem: If user receives an SMS/call, snap decision for incoming SMS/call stays on screen for always only 60sec. and then disappears from screen (by default). There was no interaction from user. Possible solution: The snap decision should stay on screen for the amount of time the app asks it to, being always app dependant. A 60sec. time-out is too short due to use cases where an action from user is mandatory. Use case example: A class 1/2 SMS arrives after user triggered a USSD command from dialer. These type of SMS always requires a response from user (CANCEL or a further COMMAND). Thus a timeout of only 60 sec is too short because it can be missed and these type of SMS is NOT saved into the usual messages thread. To manage notifications about this bug go to: https://bugs.launchpad.net/indicator-network/+bug/1295762/+subscriptions -- Mailing list: https://launchpad.net/~dx-packages Post to : dx-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~dx-packages More help : https://help.launchpad.net/ListHelp
