Rather than waiting until an app filter is set on the application
selector, load the app list immediately at construction time. This is
now possible because it can be diffed easily when the app filter is set.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #28
Instead of removing all the entries in the list store when the set of
installed apps is updated, diff the old and new lists so that removed
apps can be selectively removed from the list store, and added apps can
be selectively added.
This means that we can (in subsequent commits) reload the app list less
conservatively, as doing so will no longer remove in-progress user
modifications to the set of blocked apps. Modifications are still only
saved when the restrict applications dialogue is closed.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #18, #28
This doesn’t achieve anything by itself, but makes some upcoming commits
to diff the new/old app lists work properly.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #18, #28
The latter doesn’t work well when building as a subproject — it
explicitly refers to the parent project root.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Replace usages of the terms whitelist and blacklist with the more
inclusive and more precise terms allowlist and blocklist, which are
actually also more consistent with parts of the codebase, e.g.
mct_app_filter_is_content_type_allowed().
The only API break here is in libmalcontent/app-filter.h but the
relevant API is not used anywhere else in Endless OS beyond this repo,
nor to my knowledge in any other distribution. Also, per the README,
this project's API is not stable, so now is a good time to make this
change.
This is a backport of commit 01e9ee8113 from appstream-glib:
as-content-rating: Lower the OARS/CSM mapping of sex-homosexuality/intense
This rationalises it with the OARS/CSM mapping of
sex-themes/intense, and with many western societal norms. It is
against the laws and morals of various western countries to discriminate
on sexual orientation, so the mappings for sex-homosexuality/intense and
sex-themes/intense should be the same.
The mappings for the other values of sex-homosexuality and sex-themes
remain different, as their descriptions aren’t as comparable (for
example, for `mild`, the descriptions are “Indirect references to
homosexuality” vs “Provocative references or descriptions”).
The sex-homosexuality ratings category does need to continue to exist,
though, as it’s illegal in some countries to *not* discriminate on
sexual orientation. Those countries can provide and maintain their own
OARS/age mappings.
See https://gitlab.freedesktop.org/pwithnall/malcontent/-/issues/21.
This issue is now being solved in appstream-glib as the content rating
code has been moved there so it can be shared between malcontent and
gnome-software.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: https://gitlab.freedesktop.org/pwithnall/malcontent/-/issues/21
If a suitably new version of appstream-glib is available, use its
implementation of content rating systems (see
https://github.com/hughsie/appstream-glib/pull/364), rather than our
forked one.
This adds a dependency on libappstream-glib, but no particular version.
Eventually, our copy of `gs-content-rating.[ch]` can be dropped.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #7
This incorporates the following commits from gnome-software:
• 4db48ef429501d86a45e87eaf8dd97e59dea0d58
• a62b57a60f886a61c30f17b08277c1b826068a9d
• 617f0de4f109efe319de36cbc42076e667578eda
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This aligns the copy of the API here with what’s being proposed in
appstream-glib (https://github.com/hughsie/appstream-glib/pull/364). In
a few commits’ time, this copy will be deprecated.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This incorporates commit ed981f1d26f9a2c086eeccdee2909959de64f908 from
gnome-software, which ensures that content rating systems are chosen by
territory rather than language.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This incorporates commit 7d00c4d84b2a47dd815dc88da1a82dc54800d4b6 from
gnome-software, which allows the ESRB strings to be localised.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Previously, just the button at the end was activatable, but making the
whole row activatable makes it an easier hit target.
From a suggestion by Nick Richards
(https://www.nedrichards.com/2020/04/endless-3.8.0-beta-1-trip-report/).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This means the strings are always translated using the correct domain,
regardless of which program libmalcontent-ui is used in.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Rather than application i18n functions and `#include`s. This ensures
that the correct translation domain is used.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This is a hack to allow `MctUserControls` to be used from `GtkBuilder`
templates, where it’s not possible to pass construct-only properties in
to the `MctUserControls` constructor. It’s not feasible to make
`MctUserControls:dbus-connection` not construct-only, because it gets
used to construct an `MctManager` which then subscribes to various
signals.
So for the cases where `MctUserControls` is used from a builder
template, the code has to connect to the system bus manually, which is
possibly (though unlikely) a blocking operation.
This fixes a critical warning when enabling parental controls in
gnome-initial-setup.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Get the system bus higher up in the application, so the same system bus
connection can be shared between different parts of the application if
needed in future.
This also means the synchronous I/O needed to connect to the bus is done
before the application UI is shown, which prevents it unnecessarily
blocking initialisation of the `MctUserControls` widget.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When the user object changes one of its properties (for example, the
user’s locale might change if the administrator is editing a user in
g-c-c while viewing their parental controls in malcontent-control),
update the UI.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
If the user’s locale changes, we need to update the set of entries in
the OARS menu before selecting a new one and updating the label.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
On laptops which have a 1366 by 768 display, in gnome-initial-setup the
OARS dropdown is cut off by the edge of the screen. Only the first
couple entries are visible. So make it open to the right instead, where
more room is available.
Make it look more and more like a combo box. This widget really should
have been a combo box to begin with. We’re eventually going to end up
re-implementing a combo box from first principles at this rate.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #11
The labels are too long to fit on a single line, given the default width
of the user controls widget, so allow them to wrap onto multiple lines
rather than unhelpfully ellipsising.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #11
To make it more obvious that it triggers a drop-down menu. Potentially,
this should be a `GtkComboBox` rather than reinventing the wheel using a
`GtkMenuButton` — but that’s a change for another day.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #11
This will be used in upcoming commits to mark switches as restricting
something when they’re active, rather than allowing something. Their
background will be red, rather than blue.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #11
Allow the user controls widget to be used for user accounts which don’t
currently exist. This is necessary for using them in
gnome-initial-setup.
See the big new documentation comment at the top of the widget for
details of how the new semantics work.
This adds API, but does not break existing API.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This means that calling code can extract the app filter manually rather
than having to rely on the `MctUserControls` to save it. This will be
useful in a few commits’ time when support is added for using
`MctUserControls` for not-yet-created users.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
If `self->user == NULL`, don’t clear the app filter, as that leaves us
in a worse-off position than before.
Rename the method to make it clearer that it queries the filter from the
user.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Make it take a `MctUserControls` rather than a member of it. This
introduces no functional changes, but will make some upcoming
refactoring easier.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Instead of taking an `ActUser` as a property of the
`MctRestrictApplicationsDialog`, take the display name which we would
have queried from it.
This will allow the restrict applications dialog to be used in
situations where an `ActUser` isn’t available, such as when setting the
parental controls for a yet-to-be-created user.
This breaks the `MctRestrictApplicationsDialog` API, but the previous
API hadn’t yet been released.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
They need to be re-used in gnome-initial-setup. The other widgets which
remain in malcontent-control don’t need to be used in g-i-s so can stay
where they are for now. They might move across to libmalcontent-ui later
if there’s a need for it.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Moving the widgets out of malcontent-control means they can be reused in
other projects. In particular, I’m interested in reusing them in
gnome-initial-setup.
The new library will not build yet, but this introduces all the build
framework necessary for moving the source files over.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Philip Withnall
Philip Withnall
Matthew Leeds
Philip Withnall