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.
--
Lunar <lunar@???>
