This isn’t an API break, as compatibility defines are in place; and the
error code values are the same, so it shouldn’t be an ABI break. The
string value of the error quark has changed, but nobody should be
comparing that against a value which hasn’t come out of libmalcontent,
so changing it should be OK.
This is along the same lines as the previous commit: we don’t need one
error domain per property of an `MctManager`, so reduce the potential
for future duplication by renaming it now.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
If we have a flag type for getting and for setting every type of value
which can be stored on an `MctManager`, that will lead to a load of flag
types which all look identical.
Refactor the types so we only have one shared flags type for getters,
and one for setters.
Add compatibility defines so that this doesn’t break API. It’s not an
ABI break because the flag member values don’t change.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Previously these flags were using automatically assigned enum values,
which would have eventually resulted in having more than one bit set per
flag. Fix that before it happens by explicitly assigning flag-like
values. This was an oversight when they were first written.
This introduces no functional changes because both enums only had one
element so far.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Create a new MctManager object which is used as the anchor for getting
or setting MctAppFilters.
This changes the API naming around quite a bit, but doesn’t really
change its behaviour or functionality — see the tests for examples of
how little things change.
This is one step on the way to emitting a signal (from MctManager) when
a user’s parental controls change.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.freedesktop.org/pwithnall/malcontent/issues/1
Philip Withnall