sajolida:
> 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.
I use the "on/off" string and a green/red dot like the one in Settings
-> Users as status indicator.
> 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?
Currently I only use the status indicator in the status panel to display
the persistence status. But maybe we could also use this split to make
it even more obvious which services are persistent and which are not.
> [cut the points which we already agreed on]
>>> 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?
Yes, these might cause problems.
>
> 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.
I opted for the safe behavior in the new prototype.
>
>>> 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.
That's what I implemented :)
>
>>> 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.
I understood the + sign like you described it in A. I don't think the
additional dialog is very annoying. This way it is clear which services
are configured and ready to use.
>>> - 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 :)
I was also talking about each setting / option, I proposed to add this
in the TailsOptions class. But I left this out for now. The support of
"on the fly" options could be future work and they could probably be
configurable directly in the status panel.
>>> 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.
Yes, I mean mounting regular files. That's Unix and it works just like
with directories, i.e. "echo "foo" > foo; echo "bar" > bar; sudo mount
--bind foo bar; cat bar" outputs "foo". I talked with anonym about this
being a desired feature of the persistence config. My problem with the
symlink feature is that it requires a directory containing the files on
the persistence volume. This way I have to create a unique directory on
the persistence volume for each location I want to make a regular file
persistent in.
>
> 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.
I thought it would be sufficient to just define a list of files in the
respective service file (e.g. services/gobby.py) which should be made
persistent when the persistence option is enabled. Do you think there
will be situations in which a user wants to make only some files
persistent (e.g. the gobby config file but not the documents)?
>
> 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.
I already showed the new prototype to some friends who are possible
users and got positive feedback. But I think this makes more sense when
the functionality is more complete.
