Lunar:
> 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?
This would depend on the value of the "autostart" option. This is
independent from the on/off switch.
>
> Error handling is *always* a tricky part.
I agree.
>
> 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 think there is confusion here. I know of no way to catch errors of the
systemd services to *prevent* them from exiting. This is only about
wether the service *stopped*. I implemented this by listening to changes
of the systemd unit's "ActiveState" property. If this turns to
"inactive" or "failed", the service is to be considered off already. So
I think it would be correct to turn the on/off switch off independently
from user action. Then we tell the user "something wrong happened" and
he can try to fix it and turn the service back on again. I think waiting
for the user to turn it off doesn't make sense, because it already stopped.
>
> I hope this makes sense.
>
>
>
> _______________________________________________
> Tails-ux mailing list
> Tails-ux@???
> https://mailman.boum.org/listinfo/tails-ux
>
