Hi,
> > 2. No feedback while looking for upgrade.
> > When the menu launcher is first started it takes several seconds
> > before having any visual feedback. This can be really confusing.
> > How hard would it be to display a spinner or something? That looks
> > pretty important to me.
>
> I have no idea how to plug with GNOME's "application is starting"
> mechanism, but I can have a look and evaluate how painful it is.
In the .desktop, you had
StartupNotify=false
Just set this to true and you're done.
> > 3. The "click link" in the dialog messages are unclear.
> > I know we already talked about that, so feel free to remind me of
> > the technical limitations here but I thought we agreed on
> > displaying the full path of the link so people can type it in.
>
> FTR, we're talking of strings like:
>
> copy <a href='%{details_url}s'>this link</a> and open it in the
> browser to learn more.
>
> The technical limitation is that the user under which the upgrade
> frontend runs has no rights to instruct the browser (run by `amnesia')
> to do anything (and no, I don't want to set up a wrapper that allows
> the former to run stuff with sudo as the `amnesia' user).
>
Why? Why not a wrapper to launch this specific link as amnesia?
> > 8. Hide the details of the error by default.
> > The technical details of the error will be of little use for most
> > user.
>
> At least for a while, I think that any such error should be reported
> as a bug, so in the current state of things I beg to disagree with
> this statement.
>
I support sajolida's remark. The debugging info looks scary.
> > It is mainly displayed to be copy & pasted for debugging purpose.
> > So we should hide it by default and have a expandable area and a
> > "Show technical details" button or similar.
>
> I agree it will be nicer this way once this code is tested more
> broadly, that is, after it is enabled by default, and most bugs are
> fixed. Once such errors will be more likely to be caused by issues on
> the user's side (e.g. network problems) than by bugs in our software,
> I'll like your proposal very much. IMHO this is worth a normal
> priority ticket, in the "Incremental upgrades" category, but not as
> part of phase three. Could possibly be assigned to me, but I'm not
> asking for it.
>
What about an expandable area labeled "Show debugging info that you
would include in your bug report" or something like that?
> Slightly OT, but still: the current code checks that there's enough
> available memory before doing anything, but sure, if the user starts
> hacking huge pictures in Gimp while the download is in progress, it
> may fail. IMHO this is a UI or doc issues: we should probably tell the
> user right away, when proposing them to perform an incremental
> upgrade, that they should simply wait, and avoid starting
> applications: doing so might have the download fail (or leave their
> Tails system in a broken state, if this happens while the upgrade is
> applied). Thoughts, phrasing proposals?
Stupid question: couldn't a task tell the kernel to "reserve" the memory
it will need?
> > 11. Do not disable the networking without warning.
> > At the end of the process the network is disabled: we should warn
> > the user about that as this might be unexpected and problematic.
>
> It took me a few minutes, but I now understand why I didn't think of
> this at all, and why this whole topic looks very strange to me.
>
> I think I can explain. On the one hand, the current state of the UX
> suggests that one may freely use Tails during this process, with no
> risks implied; the timing of the "we're now going to shutdown the
> network" warning shows up clearly suggests this. On the other hand,
> the current code (and its author, and its design) doesn't take this
> requirement into account. Well.
>
> 1. I'd be pissed off to see this requirement explicitly added *now*.
> I'm very sorry that the current UI has been suggesting, for more
> than a year, that I was already, and implicitly, taking this
> requirement into account.
>
> 2. I think we really have to make this all more consistent, starting
> with avoiding making promises we can't hold (well, these promises
> are not explicit, but the current UI suggests it, which is enough
> to be a problem IMHO). See below.
>
> > So either
> > we warn them at some point in the process that this will happen at
> > the end, for example in the first dialog before choosing to do the
> > upgrade, either we add another confirmation dialog between the
> > download and the upgrade. I prefer the second one but it implies
> > more code.
>
> > I think this is important but not a blocker.
>
> The first one could be done right now, as part of phase three.
> It's just a sentence to write and add, feel free to file a child
> ticket of #6014, assigned to me. This could go with a general warning
> against running apps during the upgrade process, and generally solve
> the mismatch between the code and what the UI suggests.
>
> The second one encourages people to do things while the upgrade is
> downloaded and applied, which I'd rather not to. If one wants to go
> this way, IMHO one would at least have to check available memory
> again, before displaying this confirmation dialog, and think seriously
> of the consequences of trying to support this usecase.
>
I think it's fine to tell the user they shouldn't do something else
during the upgrade and add this as a requirement.
On the long run, perhaps there could even be an "upgrade" mode,
selected in the greeter, that would start an upgrade-only session?
If I remember well, you can have a GTK application be "system modal",
meaning it is the only usable application.
>> 12. Explain you need to restart to apply the upgrade.
>> I don't remember the phrasing of the last dialog,
Why not to force the user to restart, like "You should now restart
Tails, click here to restart"?
Cheers
