spec: Clarify feedback noisiness
The old wording could be interpreted as the feedback being discarded if it's noisier than the currently selected profile which is not the case. Also take the new per application settings into account.
This commit is contained in:
@@ -25,14 +25,18 @@ theme for a given device.
|
|||||||
|
|
||||||
# Implementation
|
# Implementation
|
||||||
|
|
||||||
When an application triggers feedback for an event in the feedback
|
When an application requests feedback for an event via the feedback daemon
|
||||||
daemon the daemon selects the provided feedback like this:
|
the daemon selects the provided feedback like this,
|
||||||
|
capping the noisiness for each limit:
|
||||||
|
|
||||||
1. feedbacks from a nosier profiles like the currently selected are
|
1. The currently selected profile provides the (global) upper limit for noisiness
|
||||||
ignored
|
|
||||||
|
|
||||||
2. All other feedbacks for this event are selected and run to provide
|
2. Per application settings impose another upper limit
|
||||||
feedback to the user
|
|
||||||
|
3. Per event noisiness is the last noisiness constraint
|
||||||
|
|
||||||
|
4. All feedback consistent with the resulting limit are selected
|
||||||
|
and run to provide the feedback to the user
|
||||||
|
|
||||||
With the above a feedback theme in YAML format could look like:
|
With the above a feedback theme in YAML format could look like:
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user