segfault:
> sajolida:
>> I'm offline right now so I'm missing Spencer's screenshot as well. My
>> comments only take into account your Glade prototype.
>
> Spencer's design differs quite a lot from my initial one and anonym and
> myself already said that we find it superior, so I think you should take
> a look at it :)
> Sadly, most of your comments are not applicable to Spencer's design.
Indeed, I'm sad I didn't have these in the train...
Spencer's mockups follow a typical GNOME 3 pattern that's surely a good
basis. They also indeed solve most of my comments and since you like his
drawings I'm happy! Good job!
To see similar patterns in action we can check:
- Settings → Network
- Settings → Printer
On this one I like how the status of the
printer is displayed in the left pane: gray if "off", ticked is
"default". We'll need such info to depict whether the server is on
or off. Spencer put "On" and "Off" labels but maybe we can find
something else.
They also use check boxes for "Default printer". I was worried
that check boxes were not recommended anymore but it seems like we
can use them in some places.
- Settings → Users
On this one the bigger icons in the left pane are interesting. Also
the green dot: does this mean "User connected" ("On")?
Also the vertical split between "My Account" and "Other Accounts".
Could we use this to split between persistent and ephemeral
services?
>> 1. In GNOME, switches are often on the right of their label (like in
>> Settings → Power or Settings → Universal Access) but also sometimes,
>> more rarely though, on the left of their label as you did (like in Tweak
>> Tool → Extensions). In the case of Tweak Tool, each label come with a
>> small description (like in your case) and more buttons (Settings, Remove).
>>
>> So my first reaction was to think that switches should be on the right,
>> but now that I see Tweak Tool you're probably fine. Maybe it would be
>> worth checking the GNOME HIG https://developer.gnome.org/hig/stable/.
>
> If we go with Spencer's design, there won't be a list with switches
> anymore like the one in Tweak Tool → Extensions. Spencer already put the
> switch on the right in his proposal three, which I like best.
Ok.
>> 2. From the Tweak Tool screenshot maybe you can reuse the placement of
>> the description which is smaller, gray, and below the label.
>
> Yes, that would look better. Again, Spencer already did something
> similar in his proposal :)
Great spirits meet :)
>> 3. I wonder whether we could do without the "more" expander as we
>> already have another layer of interface with the "settings" button. Then
>> we could:
>> - Always display the onion address. People will definitely need it to
>> use the service so hiding it forces everybody to go through "more"
>> (and defeats the purpose of "more" as a way of layering the
>> interface for more advanced users).
>>
>> - Always display the settings button like Tweak Tool does. Maybe
>> we can also use the gear logo which is quite common in GNOME,
>> though I dislike buttons without a label.
>>
>> - Move "Autostart" and "Allow LAN" to the settings. This could make
>> it easier to solve George's concern regarding the meaning of "Allow
>> LAN" since we could give it a bit more space.
>
> I think all of these propositions are already solved well in Spencer's
> design :)
> There is no "more" expander anymore and I think it provides enough space
> to show all the settings at once, so we can get rid of the "settings"
> button too.
Ack.
>> 4. I also wonder whether the "Persistent" option deserves to be always
>> shown. I think it should be off by default to follow our usual practive
>> of "not saving anything by default". But then I expect that many people
>> will want to use it or will be interested in its status so that would be
>> an argument in favor of displaying it in the main window. But if we
>> display it in the settings, then all settings are in a single window,
>> out of the overview, and we can also use a switch for it (as I think
>> that check boxes are not recommended anymore in the GNOME 3 guidelines).
>
> Also superfluous if we only show all settings or none as in Spencer's
> design.
Ack.
>> 5. The settings button could then open a dialog with:
>>
>> - Some generic options ("Autostart", "Allow connections from local
>> network", "Persistent", etc.)
>>
>> - Some options that are specific to the service (and might be defined
>> in whatever plugin mechanism we design to specify a new service).
>>
>> As a consequence, I don't really like the idea of anonym to "have all
>> connection info *and* all options/settings shown in the frame exposed by
>> clicking the "More" expander". I'm in favor of a single settings button
>> and something that looks more like Tweak Tool → Extensions.
>
> I skip this one because too, because it does not apply to Spencer's design.
Ack.
>> 6. For "Allow LAN" do we want to display the local IP address? Otherwise
>> people would have to find it out somewhere else before being able to use
>> it. Displaying it might also clarify what it is about.
>
> That's a good idea! I will include this in the next version of the
> prototype.
:)
>> 7. Regarding toggling "Persistent" on and off. To simplify things, and
>> as anonym pointed out, I would:
>>
>> - Prevent switching it off if the service is started already.
>>
>> - Maybe allow switching it on if the service is started already as
>> suggested by George. But maybe it's good enough to keep this as a
>> future improvement.
>>
>> - Propose to erase all data related to the service when switching off.
>> This is a problem we have with persistence features in general,
>> see #8447. But since we're designing something new here, let's not
>> duplicate this problem elsewhere.
>
> I spent some time thinking about anonym's comment on this one. I tried
> it with the mumble server and at least with this one it worked perfectly
> if I simply moved the config file to the persistence storage when making
> it persistent and removing the link and moving the config file back in
> place when removing the persistence, without ever restarting the service.
> By the way, I think at least copying the files to the persistence
> storage and mounting the persistent directory should also be implemented
> in the current persistence assistant. This would remove the necessitiy
> of a reboot before the persistence is applied. I witnessed multiple
> times that users forgot this reboot while setting up a new Tails device
> and they lost they're newly created mail address and PGP keys because
> they were not stored persistently.
Yeah, I'm aware of this issue and I think it's quite bad. You should
chat about this with intrigeri :)
> But I see that this replacement of config files might cause problems
> with other services, so I agree that disabling the persistence switch
> while the service is running would be the safest and easiest way.
Right, Mumble doesn't rely so much on the files in the file system
evolving as the service runs but what would happen for an Etherpad
service or a Gobby maybe storing content locally, for example?
I would be very happy if we can find a generic solution that works for
every possible service and I don't mind experimenting with it, but we
probably anyway need some safe behavior as a fallback.
>> 8. I'm not 100% convinced by the onion address in the text box but I
>> understand your arguments and I'm fine trying it this way.
>>
>> 9. As George pointed out, "Autostart" only makes sense if the service is
>> persistent already. This should be translated in the interface.
>
> Agreed. I will try to come up with something addressing this in the new
> version of the prototype.
Maybe "Autostart" could be a check box that's be grayed out until the
"Persistent" check box is selected.
>> 10. Also, I feel like we need to clarify what is the workflow of
>> configuring and starting a service. Especially since here we have an
>> on/off toggle that can be manipulated independently of the settings button:
>>
>> - As anonym pointed out, some settings would require restarting the
>> service.
>>
>> - 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 think with Spencer's design we could open a dialog when a new service
> is set up with the + sign.
I'm not sure about the use of the + sign on Spencer's design.
I see two options:
A: Plug sign to add a service. By default the list is empty, you click
on + to display a list of services and choose one to add it to the list.
The disadvantage I see with this is that we need a different and
separate dialog for the "list of options". It might also be more
annoying for ephemeral services that will always disappear from the list
on each reboot. But on the other hand, this seems a more common pattern
in the examples I gave from GNOME Settings.
B: Display all possible services upfront. The list is already full with
all the possible services and the state of each service ("On"/"Off" and
"Persistent"/"Ephemeral") is translated by some graphical element in the
list. The advantage is that we have only one dialog. The disadvantage is
that it might be harder to depict the state of each service and if the
list of services gets long the whole thing will get noisy.
>> - Toggling persistence might require restarting the service.
>
> Like you suggested above, this could be solved by disabling the
> persistence switch while the service is running.
>
>> Do you think you could implement some prototype for this workflow in
>> Glade in your next iteration (as it might change the layout if we find
>> big issues in the workflow)?
>
> Will do.
Cool!
>> Maybe in the back end we need to know for each setting if it is required
>> on start and if it requires restarting the service if changed.
>
> Indeed, I think we should create a "RequiresRestart" attribute in the
> TailsOptions class. All options which have this set to True would then
> be disabled in the GUI (and refuse modification through the CLI) while
> the service is running.
Yes. Note that I was talking about "each setting" (and not "each
service"). Maybe some services allow some settings to be changed on the
fly and some other settings to restart. But if you want to simplify and
treat the service as a whole as "RequiresRestart" that's fine with me :)
>> Now I'm wondering whether this design and the design of the
>> current persistence assistant should be consistent or unified
>> somehow (as they are both proposing opt-in persistence features). But
>> that sounds scary and out-of-scope for now. Maybe your design can later
>> on inspire some improvements to the current persistent assistant :)
>
> I took a look at the code of the current persistence feature and was
> scared so much that I scrapped my plan of implementing the mounting of
> non-directory files through persistence.conf, although that feature
> would come in very handy for the Tails Server.
I'm not sure what you mean by "mounting of non-directory files". You
mean mounting regular files? Is this Unix? We have the Dotfiles feature
that creates symlinks in the right places and that can be used to do
crazy stuff.
Ah, and I was talking about the design of the graphical assistant (in
Perl), not the back end. I really think that you should reuse the
syntax, mounting and symlinking mechanism of persistence.conf, probably
from a different but similar file.
If I remember correctly, anonym has coded some features for that in the
Debian Live back end so he knows what this is about (I actually don't).
intrigeri wrote the Perl front end but we shouldn't look at that :)
> Thanks a lot for the comprehensive input! Please keep it up, this way we
> will get a really user-friendly interface :)
Yeap. And once you get a new Glade prototype of this one you could
almost already show it to some potential users and gather some early
feedback.
