sajolida:
> segfault:
>> I think both anonym's suggestion of graying out the "configure" button
>> and the current design solve the problems we would have if we used only
>> a single panel. anonym confirmed that he didn't actually test the
>> prototype before writing the mail and didn't know the problems he
>> addressed are already solved in the current design.
>>
>> So currently I see the following proposals:
>>
>> 1. Use a single panel with either;
>>
>> A. Somehow make it clear to the user that he needs to restart the
>> service after changing options
>>
>> -or-
>>
>> B. Gray out the options which require restart if the service is running
>
> If we go for a single dialog I think we should go for B and make options
> read-only when the service is started. I proposed A to have some
> alternative to B but I never really believed in it :)
>
>> 2. Use the separate status panel and configuration dialogue with either:
>>
>> C. Name the ok button "Accept and Restart Service" and do exactly that
>> when it's clicked.
>>
>> D. Gray out the "configure" button in the status panel while the
>> service is running.
>>
>> I would be glad if we could decide on this soon, so I can continue
>> working on this and implement all the functionality needed for initial
>> usability tests.
>>
>> Some of the sarah's ideas would make A less awkward, but I would still
>> prefer 2. because of the arguments I made in my previous mail.
>>
>> I prefer C over D - they solve the same problems, but I think D will
>> provide slightly better UX, because users will be able to look at the
>> configuration panel and change the controls while the service is
>> running, only having to restart it to apply the changes.
>
> I would still go for the single dialog (B) which still has the
> advantages of:
>
> 1. Less design and less code.
This is true, but it's not that much more design and code.
> 2. One option lives in one place where the user can both see its state
> and change it.
Users would of course also see the option's state in the config dialog.
And I think as long as the configure button is visible on the same
screen, clicking it would be the obvious action if the user wants to
change an option. So no risk of "Wtf I see the option but why can't I
change it?!"-like situations IMO.
> I'm not sure whether after the recent discussions there are still clear
> disadvantages to this proposal (but of course I'm partial). But hey, I'm
> not going to be pissed of or whatever if you decide to go for the
> configuration dialog :)
Really, I'm not that convinced (anymore) of the config dialog and I
don't want to make this decision on my own.
Currently I think the main argument I have left is that with B it might
be not immediately clear to the user what he has to do to enable the
grayed out options. Additionally confusing might be the fact that we are
also using graying out to disable options while prerequisite options are
not set. So maybe more risk of the "Wtf do I have to do to change this
option?!" situation. But then again, if they start the service by
clicking the switch in the first place, it's likely they notice that
this causes the graying out. So I don't think this is very important.
>
> While exploring GNOME Settings today I saw stuff like this:
>
> - In Users and Printers, the options are displayed as labels but when
> hovering them they turn out to be buttons that you can click to
> change.
Wow. I just tried this and I found it very surprising and totally
unexpected behavior, even though I read this first :D
I really think we should not do this, but use a textbox when we want to
allow editing a string.
> - In Date & Time, the options are grayed out until you click "Unlock"
> and enter the administration password.
Not sure about this. We could use something like this to work around the
issue that the GUI has to be started as root at the moment.
