Much of this code previously lived in Endless's fork of
gnome-control-center, and so many strings had previously been translated
there. I imported a bunch of them from
https://github.com/endlessm/gnome-control-center/tree/eos3.7 as follows:
cp ~/src/endlessm/gnome-control-center/po/LINGUAS po
ninja -C _build/ meson-malcontent-update-po
for x in po/*.po; do
t3k copy ~/src/endlessm/gnome-control-center/$x $x
done
ninja -C _build/ meson-malcontent-update-po
Then manually reviewed the output from t3k to exclude languages where
only trivial translations such as "Help" were copied.
Many of these translations are for OARS rating descriptions, which are
actually originally from gnome-software, and were imported into our
gnome-control-center in a similar way. I have long been sad that these
strings were not present in some common shared library; hooray! now they
are.
[t3k]: https://gitlab.gnome.org/wjt/translate-o-tron-3000/
This is a hack to allow `MctUserControls` to be used from `GtkBuilder`
templates, where it’s not possible to pass construct-only properties in
to the `MctUserControls` constructor. It’s not feasible to make
`MctUserControls:dbus-connection` not construct-only, because it gets
used to construct an `MctManager` which then subscribes to various
signals.
So for the cases where `MctUserControls` is used from a builder
template, the code has to connect to the system bus manually, which is
possibly (though unlikely) a blocking operation.
This fixes a critical warning when enabling parental controls in
gnome-initial-setup.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
WARNING: Project specifies a minimum meson_version '>= 0.49.0' but
uses features which were added in newer versions:
* 0.50.0: {'install arg in configure_file'}
Without a GType for the error enum, g-ir-scanner fails to properly
associate it with the error quark function, and (for example) error code
matching in JS doesn’t work.
This adds the enum types in a new public header file.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This is a high-level API to indicate whether parental controls are
‘enabled’ for the given user. It’s a mirror of
`mct_app_filter_is_enabled()`, and exposes the existing
`time_limit_enabled_out` argument of
`mct_session_limits_check_time_remaining()` more conveniently.
Includes tests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This is a high-level API to indicate whether parental controls are
‘enabled’ for the given user. Specifically, whether any of the
properties of the `MctAppFilter` differ from their default value.
Includes tests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Get the system bus higher up in the application, so the same system bus
connection can be shared between different parts of the application if
needed in future.
This also means the synchronous I/O needed to connect to the bus is done
before the application UI is shown, which prevents it unnecessarily
blocking initialisation of the `MctUserControls` widget.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Add methods to serialise and deserialise the app filter, and use them to
replace the code in `MctManager` which was previously doing this. This
exposes the variant format for the app filter in the API (although the
format is described as ‘opaque’) so that user code can log it or store
it separately.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When unlocking malcontent-control while running as an unprivileged user
to edit *that* user’s parental controls, the `ChangeOwn` and `ReadOwn`
privileges should also be granted.
Otherwise a second polkit authorisation dialogue is popped up after
editing any of the parental controls, to get permission to save the
changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When malcontent-control is run as an unprivileged user (i.e. a child)
the fact that the unlock wording refers to ‘other users’ is a little
confusing, since the purpose of running malcontent-control was likely to
edit the parental controls for *this* user.
Adjust the wording to make this a little clearer.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Rather than building it again; this is the second half of resolving the
dependency cycle from the previous commit.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #16
This allows the UI components (libmalcontent-ui and malcontent-control)
to be disabled in the build so that a dependency cycle with flatpak can
be avoided (by building malcontent twice, once with `-Dui=disabled` and
then again with `-Dui=enabled`).
The dependency graph is:
malcontent-control → libmalcontent-ui → flatpak → libmalcontent
which becomes cyclic if libmalcontent-ui and libmalcontent can only be
built at the same time.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #16
Will Thompson
Philip Withnall
Piotr Drąg
Philip Withnall
Andika Triwidada
Yuri Chornoivan