boyska authored Mar 22, 2023 and segfault committed Mar 23, 2023

When reading this, I wondered if a GObject.Object could be False-ish. In fact, that's how if not self.switch works. So I needed to wonder, and guessed that it should never be the case, and then I can be sure I'm understanding what this is checking.
A more specific expression would have saved me this reasoning.

I don't think this is serious enough to deserve being changed in all our codebase, though.

sajolida authored Mar 16, 2023 and segfault committed Mar 23, 2023

Closes #8447

It works in more cases than `shutil.rmtree` and therefore allows the
user to recover from more error cases, for example when a file exists
at the path instead of a directory.

Apparently, callign Gtk.Switch.set_state(False) also causes the
Gtk.Switch.active property to be set to False, which means that the
switch is put in the "off" position. That caused out "notify::active"
handler to run which deactivated the feature.

... even if we fail to refresh one of the properties. This ensures that
the frontend can display a state which is as close as possible to the
actual state, for example if refreshing HasData fails, the IsEnabled and
IsActive properties should still have the correct value.

In these steps we check a condition and don't bring about a condition.

Check that all features are still enabled when activating the
PersistentDirectory feature failed.

Also improve the implementation of step "all tps features are active".

Use "tps feature" instead of "persistence preset".

In the Persistent Storage context, "active" means that a binding is
currently active (e.g. bind mounted), "enabled" means that it's in the
config file.

Show the "Your Persistent Storage is unlocked" message when the
Persistent Storage was unlocked and some some features failed to
activate.

In cases where the user did something unexpected which caused the
failure, the output of the command can help the user to debug the issue
themself.

It doesn't contain any useful information.

To ensure that the result of an Activate/Deactivate call is either the
expected state or an error (which nudges users to send a bug report).

Changes of the IsActive and IsEnabled properties were signaled with the
same PropertiesChanged signal, causing the UI to briefly display an
"inconsisteng state" error. We now signal changes of IsEnabled, IsActive
and HasData all with the same signal.