Re: [Tails-ux] Tails Server GUI Design

sajolida:
> 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.
>
> This would be:
>
> 1. I turn the service off through the switch.
> 2. I change some options.
> 3. I turn the service on through the command line.

Yes, that's what I meant.

>
> Then the problem is to know what happens to the options I changed in
> step 2, right? I think these changes should be applied, as if I had
> turned the service on through the switch. Now if the command line allows
> passing conflicting options when starting the service (let's say a
> different password), then these options should any be kept in sync in
> the GUI anyway, no?

Hmm. I think you are right. I missed that we would have to somehow
monitor the config files anyway if we want to support this mixed use of
CLI and GUI. I thought that it would be sufficient to check the values
when the dialog is opened, but of course the status of the options in
the status panel would need be checked by other means.

So, after having realized that, I think we should not support this use
case :) At least not in the first implementation, we could add this later.

> So I understand that keeping a GUI and a CLI in sync makes
> implementation more complicated, but I don't see how this affect a
> design more than other one. But I probably missed something.