segfault:
> sajolida:
>> segfault:
>> The disadvantages are that:
>>
>> - You have duplicate information between the two screens, with one
>> version describing the state (eg "Persistence Off") and another
>> changing the setting (eg "Store service configuration and data on the
>> persistent volume"). In Spencer's design both the state and the
>> widget the state were the same thing and that's simpler and probably
>> easier to understand.
>
> Right, there is duplicate information. But I don't think this is that bad.
> The first I call the "status panel" and the other the "configuration
> dialog". The status panel should only display the information that is
> important / often needed. I implemented this by adding a
> "display_status" attribute to the Option class. If this attribute is set
> to True, the option will be displayed in the status panel. But currently
> I only display the red/green "light", which only makes sense of bools.
> If the option type is string or int, it should display a label instead.
> I think by the use of the red/green "lights" for bools and labels for
> strings and integers it is quite clear that the options are not
> configurable in the status panel.
> Also, there is the same kind of duplicate information with the red/green
> "light" in the service list on the left and the on/off switch in the
> status panel.
FWIW, I like the approach you took here, segfault. In most cases users
will only need what is shown on the status panel, so let's not make it
harder for them to find what they need by also showing options they may
not even understand.
>> - I have to click Configure to see the password of the Mumble and give
>> it to my users. The same probably applies to other settings of other
>> services.
>
> The server password is of course information that is often needed and
> should also be displayed in the status panel. Like I wrote above, I
> didn't implement this for strings and ints yet, but will do so if we
> decide to keep the status panel.
Perhaps it's worth making a special case for passwords, i.e. initially
show it as "***" in the status panel, and only show the password after
some deliberate action, like a small label saying "Reveal password". Or
perhaps just show a "copy password to clipboard" button/label?
I also think there should be an option to generate new (safe) passwords
in the configuration panel, with some button/label next to the setting.
>> - More design, testing, coding, maintenance, etc.
>>
>> Regarding the problem that you were trying to solve: convey to the user
>> that she needs to restart the service to apply the changes, I'm
>> confident that this can be solved without loosing the advantages of
>> having a single screen. For example we could:
>>
>> A. Show a dialog saying that the changes will be applied only after
>> restarting the service, when once of these options is changed.
>
> I think a popup dialog for every option modified would be very annoying.
> Maybe a notification (like the ones created with notify-send) would be
> less annoying - but I associate those more with notifications from the
> system and I think it would be strange to get those from the application
> I am currently interacting with. Another option would be displaying a
> warning somewhere in the application window. But I think the additional
> configuration dialog makes the workflow clear without displaying any
> messages.
I fully agree with you scepticism regarding all solutions for how to
notify the user of this, so...
>> B. Gray out the controls that require restarting the service while the
>> service is running. This would force the user to shutdown the
>> service to change its configuration. I quite like this option as:
... I think this is what makes most sense, mostly because of what
follows below:
>> - It could make quite easy to differentiate in the future the
>> options that require restart and the ones that don't. Even if for
>> now on you can gray out everything.
>> - Instead of talking about "reconfiguring and restarting" we would
>> talk about "stopping, reconfiguring, and starting" which is maybe
>> a bit slower but might be clearer in terms of mental model. For
>> example, because it prevents confusion on whether the changes are
>> applied already or not (with respect to option A).
Perhaps this is what you suggest, but let's make this proposal clear:
let's KISS and skip supporting changing *any* option while a service is
running. In other words: let's grey out the "Configure" box while the
service is started, and enable it again once the service is stopped. A
label can be shown next to the greyed out button saying: "Services can
only be configured while stopped".
This will be very easy to explain to users, and simplify implementation
and reduce the design complexity.
> I think B is better than A but I'm not sure if it makes it clear to the
> user that:
>
> - After starting the service, he will not be able to modify the options
> he sees (unless he stops the service again)
This is fixed by my proposal: the status panel now only shows
information, and has no controls except the "Start"/"Stop" toggle, and
(if stopped) the "Configure" button.
> - He will be able to configure the grayed out options once he stopped
> the service. Of course, if he pays attention to it, he will notice that
> the options gray out while starting the service.
This is fixed by my proposal: the configuration dialog is only
accessible when the service is stopped, and then all options are available.
> Also, I already gray out the "Automatically start on boot" option while
> the persistence is not enabled, which might be confusing.
IMHO this can also be in the configuration dialog only.
>> Now, putting everything on a single screen doesn't prevent us from
>> layering this screen, for example putting advanced options in a
>> toggleable area, but the key idea here is that a single option should be
>> in a single place. Maybe it would be interesting to list the different
>> options that we would have for different services in the ones from the
>> blueprint [2], just to see how big this could get.
>
> The main reason for thinking up the status panel and configuration
> dialog separation was this point of yours:
>
>> What if a service always requires some configuration before being
>> started? For example the password of a Mumble server? Would it work
>> to display the settings dialog when toggling on if some settings
>> are required?
>
> I don't see how this would be solved with either option A or B.
When adding a service we get the configration dialog, so all options are
shown there. Add an attribute/tag "mandatory" for such options, and only
allow finalizing the addition of the service once such options are set
-- this also makes sense later, when reconfiguring. However, in most
cases we can generate such things, e.g. for passwords, but I guess there
might be things we haven't thought about yet.
> But maybe all of these concerns don't outweigh the more simple design of
> your option B, I'm not sure.
So I think we can eat the cake and keep it too, with the above proposal! :)
>> I also prefer the shorter labels (at least for "Persistent",
>> "Auto-start") which can still have longer labels as tool tips. These
>> options will be the same for every service so people will get use to
>> them and shorter labels are easier to scan and recognize.
>
> I think George suggested more descriptive labels, but maybe I overdid
> this. Are tool tips still a thing? I don't recall seeing any in GNOME 3
> applications. Maybe I just didn't notice.
Personally I find GNOME Settings very uninformative because of the lack
of a way to get information quickly for each option. I know sajolida
will hate me, but IMHO, feel free to diverge from GNOME on this point.
What about adding some sort of "Help" indicator (perhaps some stylised
question mark) that can be place next to some short option label, and
that shows a pop-up when hovered over? They can even double as links to
the user docs when available.
If pop-ups are a no-no, what about having some part of the panel
dedicated to showing the help? We display it when hovering over the
option's label or control.
Cheers!
