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.
In GTK4, the replacement to accelerators like this are shortcut
controllers.
Add a global shortcut controller to the primary menu button, and
bind it to F10.
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.
We now have a nice pre-built widget for status pages
with an icon, title, description, and children.
We should take advantage of that instead of manually
setting up each status page.
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 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>
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 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>
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>
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>
This replicates the old interface from Endless’ gnome-control-center,
with no attempt to improve or rework it. That will come later.
It might not work fully.
It allows a user to be selected, and their parental controls to be
changed. It currently doesn’t filter the users.
It supports a simple ‘Loading’ screen, before displaying the main
interface. If loading fails (due to a D-Bus error with accountsservice),
an error page is displayed instead.
Signed-off-by: Philip Withnall <withnall@endlessm.com>