Make it look more and more like a combo box. This widget really should
have been a combo box to begin with. We’re eventually going to end up
re-implementing a combo box from first principles at this rate.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #11
This will store information about the user which is related to parental
controls. Currently, that’s just a boolean indicating that the user is a
parent, and hence that their account should be presented differently in
UIs.
See: https://gitlab.gnome.org/GNOME/gnome-initial-setup/issues/94
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The labels are too long to fit on a single line, given the default width
of the user controls widget, so allow them to wrap onto multiple lines
rather than unhelpfully ellipsising.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #11
To make it more obvious that it triggers a drop-down menu. Potentially,
this should be a `GtkComboBox` rather than reinventing the wheel using a
`GtkMenuButton` — but that’s a change for another day.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #11
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>