Lunar:
> segfault:
>> It looks really nice! I think we wouldn't need an edit mode with the
>> 'Reset' and 'Save' buttons. Instead, we could always allow editing. If
>> the service is running when the user clicks on 'Save', we can tell him
>> that the service needs to be restarted and let him confirm this.
>>
>> I implemented this in the prototype and appended screenshots.
>
> It's unclear to me what happens if a user click on the “Cancel” button.
> Will the settings still be saved somewhere?
My idea was that the settings would simply not be applied when the user
clicks "Cancel". The user could then do whatever he wants to do before
restarting the service and then click "Save" again.
>
> Is there another label than “Cancel” that could describe the action
> better? “Edit again”?
Maybe "Don't Save" or "Don't Apply"?
> In case you go on with such a confirmation dialog, would it make sense
> to have the option to review changes that are going to be performed?
I could list the changes that would be applied in the confirmation dialog.
>
> On another topic: what is the value for a user to be able to edit a
> “Virtual Port”?
This is the port that is exposed on the Tor network. I used the phrase
"remote port" for this in earlier prototypes, but then I noticed that
Tor refers to it as "virtual port" [1]
[1]
https://www.torproject.org/docs/tor-manual.html.en#HiddenServicePort
> Unless you have some experience with how TCP/IP works,
> it might just be a source of confusion.
> Maybe it should be hidden behind an “advanced” section?
I think you are right and there are currently not many use cases for
changing the port. I already planned to create an "advanced" option
group, which will be hidden by default. Maybe I will move it there. On
the other hand, I would like to keep all options regarding the
connection to the service in one place (i.e. the connection string,
onion address, port and password).