Clarify that a standard user account has to be created, and then
parental controls enabled for it — and that clicking the button will
open the control centre.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #25
Helps: #26
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 is handled on the primary instance, and causes the tab to be
switched to show the given username (if possible).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #19
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>
This causes the controls on the main window to be centred at their full
width (when there’s enough window width to do so), rather than expanding
to fill the entire window.
It’s not currently possible with GTK+3 to easily set a maximum width
(of, say, 600px) to the column, without writing a custom widget (like
`HdyColumn` does).
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>
When ordering commercial translations, at least one translator
translated these literally, eg "Sitio web de mal gusto" and
"créditos-de-traductor".
It's likely that translators familiar with GNOME would not make this
mistake, but let's be explicit anyway.
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 unlocking malcontent-control while running as an unprivileged user
to edit *that* user’s parental controls, the `ChangeOwn` and `ReadOwn`
privileges should also be granted.
Otherwise a second polkit authorisation dialogue is popped up after
editing any of the parental controls, to get permission to save the
changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When malcontent-control is run as an unprivileged user (i.e. a child)
the fact that the unlock wording refers to ‘other users’ is a little
confusing, since the purpose of running malcontent-control was likely to
edit the parental controls for *this* user.
Adjust the wording to make this a little clearer.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Otherwise an application won’t be able to override the CSS installed by
libmalcontent-ui if this is ever moved into libmalcontent-ui.
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>
If the user has the restrict applications dialogue open and has made
some changes, then installs/uninstalls a flatpak (for example) from
gnome-software in another window, then the list of apps in the restrict
applications dialogue will be reloaded and the user’s changes will be
lost.
Prevent that by not reloading when the set of installed apps changes.
This is not a long-term solution: ideally we’d diff the changes against
the list of apps in the restrict applications dialogue and only update
what’s changed.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The switch is actually controlling whether to allow web browsers, not
block them, and is enabled by default.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Rather than assuming that having no GPermission means we do have
permissions, which was a little confusing and didn’t match other points
in the code.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Since this code has moved out of our downstream g-c-c fork, the issue
tracking is now upstream, so update an issue link.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Sometimes, when closing the application,
`flush_update_blacklisted_apps()` would be called after
`MctRestrictApplicationsSelector` had been destroyed, leading to a
critical.
This was because the `MctRestrictApplicationsDialog` was being disposed
early due to its `destroy-with-parent` property being set. The dispose
function of `MctUserControls` was run several times due to GTK calling
`g_object_run_dispose()`, and the critical would be emitted the second
time.
Make the dispose function’s call to `flush_update_blacklisted_apps()` be
safe for multiple dispose calls, and ensure the dialog isn’t destroyed
too early.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
`dest_x` is not set if `gtk_widget_translate_coordinates()` fails, which
it can do before the widget is realised.
This fixes a valgrind warning, but doesn’t change any user-visible
behaviour as far as I can tell.
This has been upstreamed to gnome-control-center as
https://gitlab.gnome.org/GNOME/gnome-control-center/merge_requests/691.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Children can’t be administrator accounts, otherwise applying parental
controls to them would be pointless and ineffective. So hide the
administrator accounts from the parental controls app.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
We don’t want to show administrators in the parental controls app,
since child accounts are not administrators (if they are, they are too
powerful to be constrained by parental controls).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
After the user’s current set of permissions have changed, they may now
be able to query the app filter whereas previously they weren’t allowed
to. So try re-querying it.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Add an unlock screen to the application, which is shown on startup if
the current user doesn’t have permission to view the parental controls
of other users. It requests permission using a new polkit action which
implies the various accounts-service actions we need.
This adds a dependency on `polkit-gobject-1`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
A fairly arbitrary decision which seems to match the new controls a bit
better, removing the large whitespace gap at the bottom of the window.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Following the redesign of the app filter controls, redesign the rest of
the controls on the window to match the list-box-like new style. This
doesn’t change their functionality.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Rather than having a scrollable listbox within a scrollable list of
widgets, move the listbox out to a separate dialogue.
This involves separating out all the code to query the apps, to get and
to set the app filter, from `MctUserControls` out into the new
`MctRestrictApplicationsSelector`. Most of it is unchanged, aside from
its interaction with the filter: the filter is now provided to the
widget by the calling code, rather than being queried by the widget
itself. The widget’s status can be queried into an
`MctAppFilterBuilder`, rather than being used to set the app filter
directly.
This commit redesigns the appearance of the relevant widgets in the main
window so that they follow the new list-box-like visual design. A
following commit will apply similar changes to the other widgest in the
main screen.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The application doesn’t hold a ref to some of the widgets it holds a
pointer to, since their ownership is controlled by the main window. The
main window’s lifecycle is controlled by the application, but its
dispose cycle runs at a slightly different time.
Hence, we should disconnect from the widget signals when we can, but
without holding a strong ref.
The error domain was renamed in libmalcontent, so we should use the new
domain rather than the compatibility defines.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
If there are no suitable users to show in the user selector, then no
user can be selected, so the controls have to handle a NULL user.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Philip Withnall
Bastien Nocera
Philip Withnall
Will Thompson