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>
Philip Withnall