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
Following on from commit b5b1ac2, change a couple of other strings to be
the same to reduce the number of translatable strings. These strings are
unlikely to ever be seen by the user, so it’s not an issue that they’re
becoming a little less specific.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Philip Withnall pointed out that if mct_manager_get_session_limits()
fails with G_DBUS_ERROR_ACCESS_DENIED or
org.freedesktop.Accounts.Error.PermissionDenied, the error message
will wrongly refer to app filter data. Make it more generally applicable.
Signed-off-by: Simon McVittie <smcv@debian.org>
In distributions that package shared libraries and daemons separately,
it's possible to have the shared library (because it's required to run
something like Flatpak) but not the accountsservice daemon or its
malcontent extension (because the administrator of this particular
installation has no interest in parental controls, and their choice of
desktop environment is such that nothing else depends on accountsservice
either). This minimizes the memory and disk space cost of enabling the
libmalcontent feature in Flatpak for those who do not need it, while
keeping it available for those that do.
Treat this the same as if accountsservice is available but the
malcontent extension is not: fail open, by returning
MCT_MANAGER_ERROR_DISABLED.
Resolves: https://gitlab.freedesktop.org/pwithnall/malcontent/-/issues/27
Bug-Debian: https://bugs.debian.org/972145
Signed-off-by: Simon McVittie <smcv@debian.org>
Rather than updating the packages on a generic Debian Unstable image
every time a CI build happens, pre-build the image and pre-download all
the dependencies.
This should speed the CI runs up; they currently take about 4 minutes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This time, add it as a wrap module rather than a git submodule. They’re
easier to manage, and integrate better with Meson.
The subproject has to be re-added so that malcontent can be built on
Debian Stable and Fedora 31 for the gnome-software CI. See
https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/487.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
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>
We’ll drop the Transifex translation machinery downstream after this, so
this is the last time the translations will be synced.
I have not verified any of these translations, but am upstreaming them
on the premise that some strings are better than no strings.
This commit was produced by:
1. `ninja malcontent-update-po`
2. Copy in po files from downstream
3. `ninja malcontent-update-po` again
4. Manually drop header-only changes
5. Manually drop changes to `translator-credits`
6. Manually drop some conflicted strings from `id.po` (prefer the
upstream versions)
7. Manually merge headers
There are no more `help/` translations to upstream.
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.