Instead of taking an `ActUser` as a property of the
`MctRestrictApplicationsDialog`, take the display name which we would
have queried from it.
This will allow the restrict applications dialog to be used in
situations where an `ActUser` isn’t available, such as when setting the
parental controls for a yet-to-be-created user.
This breaks the `MctRestrictApplicationsDialog` API, but the previous
API hadn’t yet been released.
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>
Moving the widgets out of malcontent-control means they can be reused in
other projects. In particular, I’m interested in reusing them in
gnome-initial-setup.
The new library will not build yet, but this introduces all the build
framework necessary for moving the source files over.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Meson 0.49 has matured its pkg-config file generation a little, and the
API has subtly changed. The main library we’re building a pkg-config
file for is now passed as the first argument; and all dependencies can
be passed to `libraries`/`libraries_private`. Any dependencies which
provide pkg-config files will automatically be moved into the pkg-config
file’s `Requires`/`Requires.private` sections.
See https://mesonbuild.com/Pkgconfig-module.html#implicit-dependencies
This bumps our Meson dependency to ≥ 0.49.0.
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>
The values are the same so this doesn’t introduce any functional
changes, but it does fix the type.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The `GSource` was being removed twice, once in `blacklist_apps_cb()` and
once in `flush_update_blacklisted_apps()`, leading to a critical warning
from GLib.
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>
This isn’t used yet, but will be soon. It encapsulates an
`ActUserManager` with an `MctCarousel` to provide an all-inclusive
widget for selecting a user account.
It’s based off code from the user accounts panel of
gnome-control-center, licenced as GPLv2+, and authored by many people
over time (see
https://gitlab.gnome.org/GNOME/gnome-control-center/commits/master/panels/user-accounts).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Make it fit in with the surrounding code style, and rename the classes
to `MctCarousel` and `MctUserControls`. List them in `meson.build` and
`POTFILES.in`. No other changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Add `CcCarousel` and `CcAppPermissions` from gnome-control-center and
rename the files. None of the contents of the files have been changed
yet. The files are from git master of gnome-control-center on
2020-01-08.
`carousel.{c,h,ui}` are licensed under GPLv2+, and are copyright 2016
Red Hat, Inc. The original author was Felipe Borges.
`user-controls.{c,h,ui}` are licensed under GPLv3+, and are copyright
2018, 2019 Endless, Inc.
`gs-content-rating.{c,h}` are originally from gnome-software, are
licensed under GPLv2+, and are copyright 2015, 2016 Richard Hughes. He
was also the original author. These files are needed by
`user-controls.{c,h}`.
`user-image.{c,h}` are licensed under GPLv2+ and are copyright 2015, Red
Hat, Inc. The original author was Ondrej Holy.
This code will not stay as copy-paste code for too long. The ultimate
plan is to rework most of the widgets:
• `CcCarousel`: Will be reworked to provide more information about the
screen time usage of each user. It will become a summary widget as
well as a selector.
• `GsContentRating`: Will be abstracted out into libappstream-glib, or
some other suitable library, where its implementation can be shared
between gnome-software and malcontent.
• `CcUserControls`: Will be reworked as the UI of malcontent evolves.
Will also be removed from gnome-control-center once malcontent-control
is released.
• `CcUserImage`: As per `CcCarousel`, this will evolve into a new
widget.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The previous version only worked on Fedora-like distributions which have
`libdir = /usr/lib{,64}`. On multi-arch Debian systems, it would
calculate `pamlibdir = /usr/x86_64-linux-gnu/security` which is not
right.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It might be stable one day, but while the functionality of libmalcontent
is growing, the command line tooling will continue to change.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
These tests check that the built `pam_malcontent.so` module can be
loaded using `dlopen()` and that it exports the right symbol. This
should mean that PAM can load it and use it.
Unfortunately, we can’t actually run the module, since PAM hard-codes
its configuration path as being in `/etc`, and there seems to be no way
to override that to load a dummy configuration from a test directory. So
the only way to test the PAM module is to use a file system bind mount
to fake `/etc` (which requires privileges); or to actually install it on
your system and integrate it into your real PAM configuration. Neither
of those are acceptable for a unit test.
It might be possible to re-execute a test under `bwrap` (if installed)
to achieve this, bind mounting a dummy `/etc/pam.d/dummy` service file
into the subprocess’ mount namespace, and otherwise bind mounting `/` to
`/`. It would need a mock malcontent D-Bus API to talk to. Something to
experiment with another time.
(See `_pam_init_handlers()` in
https://github.com/linux-pam/linux-pam/blob/master/libpam/pam_handlers.c
for details of how PAM modules are loaded.)
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Philip Withnall
Philip Withnall