In GTK4, the replacement to accelerators like this are shortcut
controllers.
Add a global shortcut controller to the primary menu button, and
bind it to F10.
Make it an AdwBin subclass. Purge all GtkContainer usage, and expose
GTK4-inspired API to add items to the carousel, and also to control
the internal GtkRevealer.
This simultaneously allows us to remove a lot of code, and make
Malcontent more consistent with the rest of the system.
Port MctUserImage to use an AdwAvatar internally. Make it inherit
AdwBin since it has a single child now.
GtkButton has an 'icon-name' property that greatly simplifies
setting up buttons. GtkMenuButton has a new 'always-show-arrow'
property that also allows us to simplify some code.
This simply changes namespaces. Fortunately, no further widgetry
changes will be necessary - all the widgets and APIs seem to have
an exact match in libadwaita.
This was simple, since few widgets have accessibility properties
manually set. The 'static' role doesn't exist anymore, and GtkLabel
handles everything for us, so we can just drop it.
In GTK4, can-focus usage is much more specific to widget subclasses,
and in almost all cases it's not necessary to set it.
Remove it everywhere, except in one case where it still needs to be
manually set to False.
We now have a nice pre-built widget for status pages
with an icon, title, description, and children.
We should take advantage of that instead of manually
setting up each status page.
This means we can depend on fix 42ba8efaf2 in Meson, which fixes use of
`volatile` in the default templates used by `gnome.mkenums_simple()`.
This fixes compiler warnings with recent compilers, which are promoted
to errors due to `-Werror`.
Meson 0.57.0 is available in bullseye-backports in Debian, which means
it’s available basically everywhere now.
Bumping the dependency required fixing a few deprecations in the
`meson.build` files.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It fixes the build with meson 0.61.0. The positional argument was
ignored in the past, became a warning in meson 0.60 and a hard error
starting with 0.61.0.
When showing the controls, focus them first rather than the user
selector. The correct user is probably already selected.
This has the added benefit of not drawing attention to the ugly focus
rectangle on the user selector.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Clarify that a standard user account has to be created, and then
parental controls enabled for it — and that clicking the button will
open the control centre.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #25
Helps: #26
Try and nudge parents/carers towards the best practice for how to set
parental controls on a user, by linking them to appropriate external
content from people who know what they’re talking about.
This external content can vary in the translations so that parents are
pointed to appropriate localised guidelines. In the UK, for example,
this may be
https://www.nspcc.org.uk/keeping-children-safe/online-safety/.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This simplifies the UI, as nobody really understood the difference
between ‘Restrict Application Installation’ and ‘Restrict Application
Installation for Others’. Now there’s just a ‘Restrict Application
Installation’ checkbox, which controls application installation in the
home and system flatpak repos.
The underlying app-filter representation in libmalcontent still supports
restricting installation to them separately, but the UI will always set
them to the same value.
There is a suggestion that we may want to support user repos again in
future iff the user has added a remote to their user repo. However,
figuring that out for other users (which is what the admin would have to
do when setting this all up) starts to get tricky with permissions for
reading other users’ home directories. Skip that for the moment — we can
reconsider adding that option in future if someone argues a case for it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #30