The toggle switches remain focusable, but the rows should not be
focusable. Otherwise tabbing through the list involves two tabs per row.
The screen reader continues to work correctly with this MR applied: when
tabbing to a new switch, it reads out the label from the row, plus the
switch state.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #52
An app which currently depends on malcontent-ui-0.pc or
MalcontentUi-0.gir will fail to compile or run, respectively, aganist
the GTK 4-ified version.
Bump the API version, which is used in both those names. This will also
(I think) allow the two versions of libmalcontent-ui to be
parallel-installed.
When validating the .ui files, we need to determine the path to GTK 4's
relaxng schema. Previously this was erroneously looked up in the prefix
of GTK 3, which malcontent otherwise doesn't depend on.
Define the GTK dependency once, and use that variable everywhere.
AdwPreferencesPage is intended to be used as the first widget
inside page. It has an AdwClamp and a scrolled window to handle
just that.
Putting it in the MctUserControls widget is undesired, because
it introduces an oddly positioned scrolled window in the parental
controls page of Initial Setup, and if we ever reintroduce this
widgetry in Settings, it would suffer from the same problem.
Remove AdwPreferencesPage from MctUserControls, and replace it
with a vertical box. Add an AdwPreferencesPage in malcontent-controls
to compensate for that.
This was supposed to be a project-wide commit, but actually only
MctRestrictApplicationsDialog had APIs to be updated. MctUseImage
will undergo a major surgery soon, so it's left out.
GtkButton has an 'icon-name' property that greatly simplifies
setting up buttons. GtkMenuButton has a new 'always-show-arrow'
property that also allows us to simplify some code.
This simply changes namespaces. Fortunately, no further widgetry
changes will be necessary - all the widgets and APIs seem to have
an exact match in libadwaita.
This was simple, since few widgets have accessibility properties
manually set. The 'static' role doesn't exist anymore, and GtkLabel
handles everything for us, so we can just drop it.
In GTK4, can-focus usage is much more specific to widget subclasses,
and in almost all cases it's not necessary to set it.
Remove it everywhere, except in one case where it still needs to be
manually set to False.
Depend on libappstream-dev, and include appstream.h instead of
appstream-glib.h.
We can depend on a new enough version of libappstream that all the
content rating symbols we need are available, which means that
`gs-content-rating.[ch]` can be dropped entirely.
Turns out no code changes are needed other than that.
Fixes: #51
This means we can depend on fix 42ba8efaf2 in Meson, which fixes use of
`volatile` in the default templates used by `gnome.mkenums_simple()`.
This fixes compiler warnings with recent compilers, which are promoted
to errors due to `-Werror`.
Meson 0.57.0 is available in bullseye-backports in Debian, which means
it’s available basically everywhere now.
Bumping the dependency required fixing a few deprecations in the
`meson.build` files.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fix using the up and down keys to change the keyboard focus between rows
between the listboxes. Previously, keynav would fail at the bottom of
the first listbox, and at the top of the second.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
They are being dropped in Endless OS, and would have been filtered out
by the fact they’re not flatpaks anyway.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Previously, we sorted apps based on their display name, but
(confusingly) displayed their name. This leads to inconsistencies like
Rhythmbox being sorted (in French) as "Lecteur de musique Rhythmbox"
which places it between Krita and LibreOffice, but displayed as
"Rhythmbox".
Fixes#32
Try and nudge parents/carers towards the best practice for how to set
parental controls on a user, by linking them to appropriate external
content from people who know what they’re talking about.
This external content can vary in the translations so that parents are
pointed to appropriate localised guidelines. In the UK, for example,
this may be
https://www.nspcc.org.uk/keeping-children-safe/online-safety/.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This simplifies the UI, as nobody really understood the difference
between ‘Restrict Application Installation’ and ‘Restrict Application
Installation for Others’. Now there’s just a ‘Restrict Application
Installation’ checkbox, which controls application installation in the
home and system flatpak repos.
The underlying app-filter representation in libmalcontent still supports
restricting installation to them separately, but the UI will always set
them to the same value.
There is a suggestion that we may want to support user repos again in
future iff the user has added a remote to their user repo. However,
figuring that out for other users (which is what the admin would have to
do when setting this all up) starts to get tricky with permissions for
reading other users’ home directories. Skip that for the moment — we can
reconsider adding that option in future if someone argues a case for it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #30
This prevents a polkit authentication prompt popping up unexpectedly if,
for example, a non-privileged user has opened and immediately closed
malcontent-control.
Spotted by Andre Moreira Magalhaes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
While the label for the OARS pseudo-combobox was updated when loading a
user’s app filter, the internal state (`self->selected_age`) was not.
Similarly, the set of restricted apps wasn’t loaded until the restricted
apps dialog was opened.
This caused problems when loading a user’s parental controls and then
editing a control which *wasn’t* restricted apps or the OARS level. The
resulting app filter would be built using default values for those two
controls, overwriting and losing their previous values when it was
saved.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Since the changes to avoid reloading the app list entirely when loading
an app filter (commit 9d4639cf49), the switch states haven’t been set
properly when loading a new app filter, since the app rows already
exist, and the switch states were only set on creation.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This is a backport of commit f742cc3cf2428 from appstream-glib:
as-content-rating: Align the OARS/CSM mappings of sex-*
Align the OARS/CSM mappings of sex-homosexuality and sex-themes, as the
two are identical apart from discriminating on sexual orientation.
This is a follow-up to commit 01e9ee8113a8ad.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
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.
Philip Withnall
Will Thompson
Georges Basile Stavracas Neto
Christopher Davis
Philip Withnall
Philip Withnall
Matthew Leeds