snap decision timeout needs to be determined by the requesting app

As discussed with Olga last week, a possible solution would be the introduction of a new integer hint (e.g. "x-canonical-private-timeout"), which would allow a snap-decision to divert from the regular timeout-behaviour that's usually the case with snap-decisions.

On could argue if we start using the the regular notify_notification_set_timeout() instead of a dedicated hint.

Status changed to 'Confirmed' because the bug affects multiple users.

If thee is a decision to be made, then the timeout should probably be infinite, unless the app wants it to time out explicitly.

Otherwise, the use of the notification API feels a bit strange to me. Snap decisions feel like something different, which should have a "snap decision API", where an application can express what the /decision/ is about.

This bug was fixed in the package indicator-network - 0.5.1+14.10.20140602-0ubuntu1

---------------
indicator-network (0.5.1+14.10.20140602-0ubuntu1) utopic; urgency=low

  [ CI bot ]
  * Resync trunk

  [ Antti Kaijanmäki ]
  * Use x-canonical-snap-decisions-timeout on the wifi password and sim
    unlock dialogs to prevent them from expiring automatically. (LP:
    #1295762)
 -- Ubuntu daily release <email address hidden> Mon, 02 Jun 2014 11:03:06 +0000

This bug was fixed in the package unity-notifications - 0.1.1+14.10.20140602-0ubuntu1

---------------
unity-notifications (0.1.1+14.10.20140602-0ubuntu1) utopic; urgency=low

  [ Mirco Müller ]
  * Added a snap-decisions-specific hint to allow control over the
    timeout of a notification. (LP: #1295762)
 -- Ubuntu daily release <email address hidden> Mon, 02 Jun 2014 10:58:29 +0000

added telephony-service to affected projects as we still need the incoming call snap decision and some of the messaging snap decisions to use this hint.

marked the Unity as Invalid as no changes needed on that side.

Reopening, because adding the "x-canonical-snap-decisions-timeout" hint was a bad idea. The notification spec already has a timeout parameter on org.freedesktop.Notifications.Notify(). We can just use that one for snap decisions and ignore it for all other notification types.

I've attached branches for unity-notifications and indicator-network.

I disagree. The "x-canonical-snap-decisions-timeout" is intentionally used in favour of the Freedesktop timeout feature, to indicate very clearly, that is is only applicable to snap-decisions notifications.

Using the regular parameter of the Notify() method - and only applying it snap-decisioin notifications - would be misleading, because the intention of that timeout parameter is to be affecting all kinds of notifications.

> I disagree. The "x-canonical-snap-decisions-timeout" is intentionally used in
> favour of the Freedesktop timeout feature, to indicate very clearly, that is
> is only applicable to snap-decisions notifications.

I think that's unnecessary for the same reason I thought introducing hints for
snap decision actions was unnecessary. It's unlikely that developers have a
problem understanding that the timeout only applies to a specific kind of
notification. They already need to know about the different kinds of
notifications and what they can do with them.

Adding additional hints only increases the complexity of the API and makes it
harder to switch between different kinds of notifications.

> Using the regular parameter of the Notify() method - and only applying it
> snap-decisioin notifications - would be misleading, because the intention of
> that timeout parameter is to be affecting all kinds of notifications.

We already go against the intention of that parameter by ignoring it
completely. In fact, we go against the freedesktop specification, which states
that notification servers need to honor this parameter.

Am 11.06.2014 12:20, schrieb Lars Uebernickel:
>> I disagree. The "x-canonical-snap-decisions-timeout" is intentionally used in
>> favour of the Freedesktop timeout feature, to indicate very clearly, that is
>> is only applicable to snap-decisions notifications.
> I think that's unnecessary for the same reason I thought introducing hints for
> snap decision actions was unnecessary.
    The hint "x-canonical-snap-decisions" is an indicating hint, e.g.
like the standard "body" hint, and used to point out that there are
certain rules enforced upon the use of actions, put forth by UX-design,
which deviate from the FDO-standard. Therefore I do not regard
"x-canonical-snap-decisions" as being unnecessary.

Furthermore hints are the designated means to introduce new features (or
different behaviour).

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

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

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