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>
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.
Rafael Fontenelle
Philip Withnall
Philip Withnall
Yuri Chornoivan