Configure global preload disposable in the installer

[ben-grande]

The problem you're addressing (if any)

Configuring preloaded disposables requires an action post install. If, since the install, the user can set the number of preloaded disposables, they don't need to worry about configuring this later.

The solution you'd like

On the anaconda-addon, add a spin button on Main configuration below Create default system qubes because it creates the default DispVM. For consistency, use a checkbox also.

The value to a user and who that user might be

Any user of unnamed disposables that have enough memory will have faster retrieval of fresh disposables.

Completion criteria checklist

No response

[deeplow]

The thing with adding another setting is that it's already a bit overwhelming. If there's a way to set a sane default or to ask the user when it's really needed, I'd say that's preferable from the UX perspective. But I'm no UX expert.

Off the top of my mind I can see a few alternative approaches without adding more initial setup options:

• When disposable is opened for the first time, a notification asks the user if they want to preload or not.
• On initial setup invisibly set number of default preloaded disposables based on available RAM. 1 preloaded disposable per 6Gb of ram, up to a certain default max. (Although this would only help for the default disposable).

[ben-grande]

• When disposable is opened for the first time, a notification asks the user if they want to preload or not.

I don't like this approach because I don't like wizards or popups. I dislike that the first boot of a Whonix Gateway pops-up systemcheck and anon-connection-wizard (the latter might not be true anymore). Also, the second option is more in line with not making the user think of an optimal number, but choose it for them, which would be recommended for most users.

• On initial setup invisibly set number of default preloaded disposables based on available RAM. 1 preloaded disposable per 6Gb of ram, up to a certain default max. (Although this would only help for the default disposable).

I like this approach. @marmarta or @HW42 has recommended this also. Marta, is implementing a single checkbox button (no spin button at all) to enable preloaded disposables (a number calculated by system resources), a better approach than duplicating the global config buttons here? I think we can safely do that.

[marmarek]

When disposable is opened for the first time, a notification asks the user if they want to preload or not.

I don't like this either. It's going to popup the prompt at unexpected time, disrupting whatever user was trying to do. Users likely will try to dismiss the prompt without reading, making it useless...

As for automatic default value - IMO should be fine. But I'd do a more conservative one - if the system has 16 GB RAM or more, set to "1", otherwise don't enable.

[HW42]

• On initial setup invisibly set number of default preloaded disposables based on available RAM. 1 preloaded disposable per 6Gb of ram, up to a certain default max. (Although this would only help for the default disposable).

I like this approach. @marmarta or @HW42 has recommended this also. Marta, is implementing a single checkbox button (no spin button at all) to enable preloaded disposables (a number calculated by system resources), a better approach than duplicating the global config buttons here? I think we can safely do that.

Having only a single checkbox in the installer (and leaving any more advanced config to the global settings, post install) seems like a reasonable option too.

Probably wasn't meant quite that way, but if taken literally 1 preloaded disposable per 6 GiB would mean even for our absolute minimum of 6 GiB RAM we would spend some on a preloaded disposable. Either we go with Marek's very conservative approach (mem > 16 GiB ? 1 : 0) or something like min(floor(max(mem - 16 GiB, 0) / 6GiB), 5) (exact values up to debate).

[deeplow]

Yes, the exact number was just a random suggestion. My main point was that the more thinking the user has out of context, the more overwhelming that choice is. While I think that a simple toggle in the setup is acceptable, I'll try to make my contextual choice point more clear, to see if that changes some minds 😉.

When disposable is opened for the first time, a notification asks the user if they want to preload or not.

I don't like this either. It's going to popup the prompt at unexpected time, disrupting whatever user was trying to do. Users likely will try to dismiss the prompt without reading, making it useless...

Most people dislike them, myself included. But what I'm suggesting is not aimed at being disruptive. In fact, there is already a notification when a qube is starting:

While the above notification is shown, the user has to wait anyways for the qube to start. So, if there is a button to make the next time faster, it's less likely to be missed, but if ignored, it wouldn't be to big of a loss either.

The suggestion is nothing new. Here are a few similar examples:

[Onion available] button	Save login button
Qubes' website is make use of this to make its onion site version more easily discoverable	it shows right in the place where it is the most useful

In both cases, were the features not brought up in the context where they are useful, they would have much less use.
Perhaps it's still not to everyone's liking. I just wanted to make it clearer what I meant.

[ben-grande]

While the above notification is shown, the user has to wait anyways for the qube to start. So, if there is a button to make the next time faster, it's less likely to be missed, but if ignored, it wouldn't be to big of a loss either.

It is clear now. Yes, this type seems like a good idea. I can further restrict it to only be called once per qui-domains combined with once per disposable of a default-dvm that has no preload-dispvm-max. I see there is an Notification.add_button in Gio. The downside is that the GUI applications do not support focusing on a widget.

qubes-vm-settings --tab advanced default-dvm
qubes-global-config [--open-at-page general]

So it will just open at a tab/page instead of emphasizing where the user should customize. @marmarta, what do you think of having Widget.grab_focus in Global Config and VM Settings? If positive, I will open a separate issue for this, as it will possibly take longer than doing the installer button.