segfault:
> Lunar:
> > segfault:
> >> segfault:
> >>> sajolida:
> >>>> A strength of Spencer's design THREE [1] was to have all the controls in
> >>>> the same screen. I understand that you wanted to make it more clear that
> >>>> the service had to be restarted for the changes to be effective but I'm
> >>>> not sure that the benefits of this change outweigh the disadvantages.
> >>>
> >>> This is about more than making it clear that services have to be
> >>> restarted.
> >>
> >> Another problem we would have if we dropped the configuration dialog
> >> came to my mind:
> >> Currently, the service status indicator and the on/off switch are
> >> automatically set if the service starts or stops. So if the service runs
> >> into an error or is stopped or started via the command line, the GUI
> >> still displays the correct state. (I implemented this by listening to
> >> systemd unit signals via dbus.)
> >>
> >> Now with your proposal B, we would have to apply the options when the
> >> on/off switch is clicked. But since there are other ways to start the
> >> service, for example via the CLI, this could lead to an incorrect state
> >> in the GUI, where the options don't display their correct state.
> >> This might be a bit far-fetched and maybe the user can't expect the GUI
> >> to be in a consistent state if he mixes it's use with the CLI - but this
> >> issue would not exist with the configuration dialog.
> >
> > Feels there's a potential usability trap here. I think it's important
> > to distinguish between the desired state and the current state. If the
> > application crashed and can't be restarted automatically, this is a
> > different state than not wanting the application to run.
> >
> > I think both the data model and the interface should reflect this
> > distinction.
> […]
> But I'm not sure if I get what you mean. I didn't implement service
> failure handling yet. I think turning the switch off automatically and
> somehow notifying the user that the service ran into an error would be
> nice behavior. Would you agree to this, or do you think the switch
> should stay in the "on" state?
Picture this scenario: the software crashed because the computer was out
of memory, then I restart Tails. What happens? Is the service restarted
automatically or must I revisit the settings to turn it on again?
Error handling is *always* a tricky part.
My own take: the computer should not change settings behind my back.
Things should be as predictable as possible. So if I tell the computer
“provide this service” and something goes wrong, it should tell me
“something wrong happened, you can try to do this to fix it or would you
rather turn the service off?” and only proceed to change the
configuration if I've answered to that last question.
I hope this makes sense.
--
Lunar <lunar@???>
