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>
This will be used in upcoming commits to mark switches as restricting
something when they’re active, rather than allowing something. Their
background will be red, rather than blue.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #11
It was causing translations to be looked for in the wrong place.
Also hard-code `GETTEXT_PACKAGE` since it’s basically API now.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Allow the user controls widget to be used for user accounts which don’t
currently exist. This is necessary for using them in
gnome-initial-setup.
See the big new documentation comment at the top of the widget for
details of how the new semantics work.
This adds API, but does not break existing API.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This means that calling code can extract the app filter manually rather
than having to rely on the `MctUserControls` to save it. This will be
useful in a few commits’ time when support is added for using
`MctUserControls` for not-yet-created users.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
If `self->user == NULL`, don’t clear the app filter, as that leaves us
in a worse-off position than before.
Rename the method to make it clearer that it queries the filter from the
user.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Make it take a `MctUserControls` rather than a member of it. This
introduces no functional changes, but will make some upcoming
refactoring easier.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
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>
Philip Withnall
Philip Withnall
Rafael Fontenelle
Yuri Chornoivan