It fixes the build with meson 0.61.0. The positional argument was
ignored in the past, became a warning in meson 0.60 and a hard error
starting with 0.61.0.
When showing the controls, focus them first rather than the user
selector. The correct user is probably already selected.
This has the added benefit of not drawing attention to the ugly focus
rectangle on the user selector.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
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>
Philip Withnall
Heiko Becker
Philip Withnall
AsciiWolf
Bastien Nocera
Philip Withnall
Will Thompson