[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

[graphical gui] Whonix Setup Wizard / Anon Connection Wizard - Technical Discussion

Started with internationalization. A new step leading to a new idea, it becomes suddenly logical to integrate gateway_first_run_notice in the wizard. Done in greeter page, whithout the language installation option yet.

Can you please review and comment. Looks like a sensible move?

Tested and merged.

Integrating the whonix-gw-first-run-notice into whonix-setup-wizard might indeed be a good way.

Mixing the language selection screen into the same page as whonix-gw-first-run-notice however looks too much.

Newly introduced bug in latest version: disclaimer windows are now partly outside the screen (vertical) (too big). Disclaimer should always be first. As a related question, could you make it so that the disclaimer does not need to be scrolled? I.e. wider windows or when all cords break, splitting the disclaimer from 2 pages into 3?

Note for later: system language does often, but not necessarily always match the keyboard layout. Also, if we are lucky, and we probably are, we can use Debian’s desktop environment agnostic ways to set system language and keyboard layout. How that can be done has yet to be researched. If you like to work on this as well? I can also help with that.

The newly introduced bug is fixed (a sort of development overlap, started the next step before committing).

The rationale for showing whonix-gw-first-run-notice in the fist page with the language option was to be able to get the whole wizard, including the disclaimer pages (locale plus German) in the local language, when the Whonix translations are done.

Also, if we are lucky, and we probably are, we can use Debian's desktop environment agnostic ways to set system language and keyboard layout.
I am not sure what the agnostic way to set system language and keyboard layout is. The path I'm following at the moment is to propose all the kde-l10-lang options in a wizard page (after "Other language" is chosen), install the language, edit /etc/default/locale accordingly and let the user make the other changes (numbers, money...) in Start Menu -> System settings -> Locale.

So the wizard steps could be:

1- Disclaimer pages
2- Language options
3- Tor
4- whonixrepository
5- whonixcheck

As far as I understand, if the translation is available in the yaml files, the wizard will be run in the local language from step 3.

The rationale for showing whonix-gw-first-run-notice in the fist page with the language option was to be able to get the whole wizard, including the disclaimer pages (locale plus German) in the local language, when the Whonix translations are done.
Certainly a valid point.
I am not sure what the agnostic way to set system language and keyboard layout is.
Keyboard layout:

Please see:

System language:
Dunno. We could ask on unix.stackexchange.com or so.

So the wizard steps could be:

1- Disclaimer pages
2- Language options
3- Tor
4- whonixrepository
5- whonixcheck


Sounds good.
As far as I understand, if the translation is available in the yaml files, the wizard will be run in the local language from step 3.
True. Unless we're able to create a usable and obvious language drop down menu.

[hr]

I was thinking… We shouldn’t invent too much mixes here. I mean, what first. Language or keyboard layout etc. Language with flags or drop down menu. Where to place buttons. How to name them. And so forth. Our programmers intuitions are unfortunately often far away from usability studies. So my suggestion is the following… Could you please look how other wizards, erhm, I mean installers, solve this kind of stuff? Like the Ubuntu installer? And the Tails Greeter? That could give some inspiration on where to place buttons and how and labels for best usability.

Have [re]checked the installation steps in Ubuntu (could not do it with Tails. Seemigly, the greeter does not show when Tails is installed on a DVD).

The first screen in Ubuntu shows the list of the available languages. It defaults to English US. The keyboard list comes after the time zone (from the IP address location), the default layout set according to the latter.

In whonix-setup-wizard, the language page is ready, using brute force (listing all the options individually in the code), but there is a way to refine it, and the keyboard layouts can be done with the same design, which may vary. At the moment, all the available languages from kde-l10 are on a separate page. We could show a list box when the user selects “Other languages”, but the list is long (55 items).

Regarding whonix-gw-first-run-notice, I do agree that mixing it with the language options is probably too much.

So the new wizard (greeter, installer ?? Good point, wizard is too reminiscent of Windows) steps:

  • Greeter: Welcome to Whonix. Default language, other language option. (ready)
  • If other language:
    - languages page (soon ready)
    - keyboard layouts page.
    - download and install page (progress bar)
    - success page (optional ?).
  • Disclaimer pages.
  • Connection page.
  • Tor status page.
  • whonixrepository pages.
  • Finish page.
  • First run notice.

Screenshot of “the old?” Tails greeter (see lang selection menu at the bottom):

(in context: https://tails.boum.org/doc/first_steps/startup_options/index.en.html)

I can see it when booting the Tails DVD in VirtualBox. There is apparently a bug in my version of Tails / VirtualBox. I need to press the maximize button twice and then I can scroll the window down to see all of the greeter.

For example, when you choose “German” as language, it sets locale and keyboard layout to “German” as well. That’s good usability. And once you choose “German”, all the other messages become German as well.

For the keyboard layout, they prefer showing you the ones that are most relevant for the language you selected. That’s all stuff we shouldn’t reinvent and learn the hard way.

The symbol for “language” and “layout” is not super obvious to me. But that could just be me.

I think Tails now has a tails-ux mailing list where they talk to “usability experts” if I haven’t heard wrong.

Please see also, “Revamp the Greeter UI”:
https://tails.boum.org/blueprint/greeter_revamp_UI/

Maybe that is knowledge that has been concluded from these discussions and perhaps even usability studies?

Tails greeter is fortunately a python app:
http://git.tails.boum.org/greeter/tree/

Can you look into it please to get some inspiration?

[hr]

One thing to point out. You cannot download stuff before going through the connection wizard. I am not sure it’s a good idea to automate apt-get using scripts. That’s a rabbit hole. Too much can go wrong. From apt-get repository down, to invalid repositories, mismatches and so forth. Hard to cover all cases in scripts.

There is a package anon-shared-desktop-langpack-kde:


Looks like it’s broken in Whonix 9. But we could fix it for Whonix 10. Would install all the language packages.

If we were to install all language package by default, i.e.:

That’d be + ~310 MB. Not sure if that would be a good idea.

During the build process we could also download all the kde-l10n-* packages (the .debs) into a special folder, but not install any of them. Then whonix-setup-wizard could - if the folder is populated - and, then install the appropriate one and wipe the other ones. Just ideas for now.

This is how I set a generic locale for Debian and Ubuntu templates:

# Set locale... Works for Wheezy & Jessie
localedef -f UTF-8 -i en_US en_US.UTF-8
update-locale LANG=en_US.UTF-8 LANGUAGE

# Set keyboard layout
# Note:  I only used 'cat' to tmp file here since it was difficult to pass the data via chroot
# and / or systemd-nspawn
    cat > "${INSTALLDIR}/tmp/keyboard.conf" <<'EOF'
keyboard-configuration  keyboard-configuration/variant  select  English (US)
keyboard-configuration  keyboard-configuration/layout   select  English (US)
keyboard-configuration  keyboard-configuration/model    select  Generic 105-key (Intl) PC
keyboard-configuration  keyboard-configuration/modelcode    string  pc105
keyboard-configuration  keyboard-configuration/layoutcode   string  us
keyboard-configuration  keyboard-configuration/variantcode  string
keyboard-configuration  keyboard-configuration/optionscode  string
EOF
    debconf-set-selections /tmp/keyboard.conf

The debconf way seems rather difficult, because it requires so many settings. Extrapolating from there to choose a lot other languages looks like reinventing the wheel.

http://git.tails.boum.org/greeter/tree/tailsgreeter/language.py seems to contain lots of stuff we need. Like a python function get_languages (Return a list of available languages codes), language_from_locale (Obtain the language code from a locale code) and much more. They apparnetly also have code to write to /etc/default/keyboard so we don’t have to figure out what to write to such files.

Had a quick glance at the Tails code. Yes, it looks like there is a lot there that we might be able to reuse (if I manage to understand it). But as far as I could gather, the big trick is that Tails greeter is a replacement of the display manager (GDM), which allows the locales to be changed on the fly. And it implies that all the languages are shipped in the ISO.

Whatever the solution we find to change the locales, because the wizard is run after the environment is loaded, I do not know if there is way to make them effective without a reboot.

Tails greeter indeed is a display manager replacement. I followed their discussions. Last time I checked, they discussed difficulties porting it to newer Gnome. I conclude this is desktop environment specific and therefore bes avoided.

There is one solution, that I find quite simple. We could also start a language selection wizard before loading KDE. Directly start the whonix-setup-wizard GUI using xinit.

Try this.

host key + F1 to switch to tty0.

Small background:
Could work similar as whonix-initializer systemd unit:


whonix-initializer runs as an “app” during first boot. Its systemd unit is configured to wait until whonix-initializer finished.

We could do something similar for whonix-setup-wizard. Before kdm/gdm/etc. would start, we could check if “whonix-setup-wizard language” has been run at least once. I.e. check for the existence of a [font=courier].done[/font] file. And if it doesn’t exist, start “whonix-setup-wizard language”. Then let the user select the language and exit normally. From there, the boot process would continue. When the desktop environment has been load, we could continue in the usual “whonix-setup-wizard setup” mode.

Most likely this requires some support from rads (https://www.whonix.org/wiki/Desktop#RAM_Adjusted_Desktop_Starter). I think this would be doable.

Only issue:
Wouldn’t work for Whonix-Qubes, because rads is ignored there. (https://www.whonix.org/forum/index.php/topic,846.0.html) But for Qubes, selection another language wouldn’t work without reboot anyhow. Maybe they’ll find another way (such as pre-seeding language settings from the host) or got another suggestion.

If you you find the xinit approach interesting, I would research further on the boot process integration feasibility.

Tails greeter indeed is a display manager replacement. I followed their discussions. Last time I checked, they discussed difficulties porting it to newer Gnome. I conclude this is desktop environment specific and therefore bes avoided.
There is a lot of Gnome specific code in Tails greeter, but the internationalization magic (like displaying the language names in their own character set) is coming from the icu and pycountry modules (python-pyicu and python-pycountry in Debian). That might help.

Installed xinit (it’s not installed by default in Whonix), it looks like THE solution. For the test, I just replaced the whonixcheck command at the very end with “kdm”.

We could do something similar for whonix-setup-wizard. Before kdm/gdm/etc. would start, we could check if "whonix-setup-wizard language" has been run at least once. I.e. check for the existence of a .done file. And if it doesn't exist, start "whonix-setup-wizard language". Then let the user select the language and exit normally. From there, the boot process would continue. When the desktop environment has been load, we could continue in the usual "whonix-setup-wizard setup" mode.
Yes. As an alternative, we could run the whole wizard before starting the desktop environment, and run first-use-notice and whonixcheck after it's started.

If/when we use tor-launcher, when the user selects the censored option, we set a variable or file to launch it once the environment is loaded. That’s what Tails is doing (a bit confusing, because the user has to reconfirm in tor-launcher that Tor is censored).

A bit off immediate topic, but in the Tails version of tor-launcher, the bridges name/addresse have to be entered manually. Not very handy.

I think it would be much better to keep the xinit part of whonix-setup-wizard as minimal as possible due to ugliness and limitations in that environment. I.e. only let the user choose what’s necessary there. Language. If really necessary, also keyboard layout and locale. All the other questions look so much nice in the full desktop environment. What do you think?

Yes, aesthetically much better (that’s important too). Then the locale and keyboard layout parts do not have to be implemented in the wizard. From my side, programming wise, it would be actually easier to write a standard Qt dialog run by whonix-initializer service.

whonix-setup-wizard could be cleaned and polished with the last missing bits, and I could have a fresh start on a first run Whonix greeter.

Provisionally, something like this:

Whonix default installation language is English (US). You can install another language blah blah… (we could leave the “translation contributors are welcome” bit).

If the user selects other language, we enable some drop-down lists (language, country, keyboard layout) like Tails are doing.

This design implies that the languages are shipped in the Whonix images.

Let’s please not mix this into whonix-initializer. It’s a very different package and I will be happy to deprecate it when Debian reproducible project finished. Whatever whonix-initializer does, we can add this startup hook functionality also to other packages.

If the user selects other language, we enable some drop-down lists (language, country, keyboard layout) like Tails are doing.
Why not do it even simpler? Start with a language selection bar?
This design implies that the languages are shipped in the Whonix images.
Hard decision. But probably no other way if we want to add internationalization support.
whonix-setup-wizard could be cleaned and polished with the last missing bits, and I could have a fresh start on a first run Whonix greeter.
Hm. Wondering if we really need another package. At the moment whonix-setup-wizard has a "repository" and a "setup" mode. Why not add just another "no_desktop_environment" mode, that only asks to setup stuff we cannot setup when the desktop environment has been load?

Having it all inside whonix-setup-wizard, one (Qubes users) could also run all these components from the desktop environment. They’d just need a hint then, that reboot (or restart desktop manager) would be required.

Unless you find it easier doing it in a separate package.

Yes, it would be easier to make a separate package, but it makes sense to integrate it in whonix-setup-wizard, if only for Qubes users. So, lets go that way.

A point of the situation on internationalization in whonix-setup-wizard.

Trying to make it as simple (usable) as possible.

At the moment, two combos boxes (drop-down lists):

  • languages as per KDE when all the languages are installed.
  • keyboards layouts as per KDE in Start Menu -> System Settings -> Hardware -> Input Devices -> Layouts

[If someone knows which files contains those lists, it would be really helpful].

Do we want to add the country selection, for extra settings, like time?

Fix, don’t use hard coded “kdesudo” within “.desktop” file, lintian doesn’t
like this and it’s not desktop environment agnostic. Added a wrapper to
workaround the lack of a Debian utility such as “su-to-root -X” that supports
passing command line parameters.:

- languages as per KDE when all the languages are installed.
*When* they are installed sounds good. Because there will be a build parameter for not installing them.
[If someone knows which files contains those lists, it would be really helpful].
Indeed! Doing it manually creating such lists seems wrong.

How does Tails obtain them?

Could you please ask someone who could know? Otherwise I could also ask arround. (unix.stackexchange.com, stackoverflow, debian-users mailing list, kde-users mailing list, intrigeri, other Debian maintainers)

Do we want to add the country selection, for extra settings, like time?
Country, probably yes. (Tails has it as well.)

Time:
https://phabricator.whonix.org/T71

Internationalization is a nightmare :’(

Tails are hard coding the language codes in http://git.tails.boum.org/greeter/tree/default_langcodes. From there, they get the languages names from a dictionnary.

I am doing that, with the languages available from KDE. Two options (dictionaries) however:

1- icu returns the names in native characters (utf8). At the moment, some languages (Japanese, Chinese, Korean…) are not properly shown in the drop-down list (boxes).
2- pycountry languages return ascii (extended) characters.

it would be nice to have 1, knowing that if the user selects one of those languages, we’ll have to install the right interface anyhow.

The country list is taken from pycountry, which is supposed to be up to date (data taken from Debian pkg-isocodes).

Still looking for the keyboards layout codes. Have to dig in the Tails code, but the list is in /usr/share/X11/xkb/symbols/.

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]