Signals that a list of keys have possibly changed. Backend
implementations should call this if keys have possibly changed their
values.
path must be a valid path (ie starting and ending with a slash and
not containing '//'). Each string in items must form a valid key
name when path is prefixed to it (ie: each item must not start or
end with '/' and must not contain '//').
The meaning of this signal is that any of the key names resulting
from the contatenation of path with each item in items may have
changed.
The same rules for when notifications must occur apply as per
Settings.backendChanged. These two calls can be used
interchangeably if exactly one item has changed (although in that
case Settings.backendChanged is definitely preferred).
For efficiency reasons, the implementation should strive for path to
be as long as possible (ie: the longest common prefix of all of the
keys that were changed) but this is not strictly required.
Signals that a list of keys have possibly changed. Backend implementations should call this if keys have possibly changed their values.
path must be a valid path (ie starting and ending with a slash and not containing '//'). Each string in items must form a valid key name when path is prefixed to it (ie: each item must not start or end with '/' and must not contain '//').
The meaning of this signal is that any of the key names resulting from the contatenation of path with each item in items may have changed.
The same rules for when notifications must occur apply as per Settings.backendChanged. These two calls can be used interchangeably if exactly one item has changed (although in that case Settings.backendChanged is definitely preferred).
For efficiency reasons, the implementation should strive for path to be as long as possible (ie: the longest common prefix of all of the keys that were changed) but this is not strictly required.