One thing I am still unsure about. That is /etc/default/keyboard. Maybe it would still make sense to configure it for the user? Because KDE settings to not apply to console. But perhaps we can leave this setting to console users for now?
Can you try if you can start these settings applications from whonix-setup-wizard using xinit please? I am wondering what will happen if a gui app started using xinit is starting another gui app starting xinit. It may or may not work. If it would work, it would certainly be easier. But if it does not, it would certainly still be doable. (Have the main pre-desktop-environment whonix-setup-wizard run as an console application, that will do âxinit whonix-setup-wizard first partâ, âxinit /usr/bin/kcmshell4 kcm_keyboardâ and so forth.
One thing that concerns me a lot is the absence of feedback about the usability aspects from others. Our coders intuitions about usability is often wrong. And it looks like, once we are discussing the technical stuff (kdesudo vs su-to-root, packaging, build issues, debugging, code design, xinit), others not developing/testing this skip reading this thread. So what I want to prevent here is creating a wizard that when finished gets a lot feedback to change the whole thing. Our xinit idea is kinda a radical approach.
Proposal:
Rename this thread to âwhonixsetup wizard technical discussionâ.
We then write a blog post (+ automatic forum post) that explains our current usability approach with screenshots and so forth. And keep that usability discussion clean of technical discussion. Talk there more about formulating things, the order of pages, if xinit looks sane and so forth.
Can you try if you can start these settings applications from whonix-setup-wizard using xinit please?
Good news, it works! Once the X sever is started, it shuts down only after the last application has finished.
Proposal:
- Rename this thread to "whonixsetup wizard technical discussion".
- We then write a blog post (+ automatic forum post) that explains our current usability approach with screenshots and so forth. And keep that usability discussion clean of technical discussion. Talk there more about formulating things, the order of pages, if xinit looks sane and so forth.
itâs still a draft. Please review and tell any improvement you can think of. There are two pages. The finish page should let us edit /etc/default/keyboard if some changes have been made. So far I could not find where KDE stores its keyboard layout setting.
It seems that the locale changes do not work when only running âkcmshell4 languageâ. We still have to edit /etc/default/locale for the changes to take effect. Investigating.
To find out which files are changed how⌠Optionally/ideally start with a fresh system.
Then go to the folders ~/.local and ~/.kde. âgit initâ, âgit add *â, âgit commit -a -m .â them. Then make your changes. Then âgit diffâ them to see what which files have changed and how.
Will look into the commit soon.
I am not surprised, that changing settings in KDE wonât change any files in /etc. KDE apparently only changes settings in userâs home folder ~/home/user. Files in /etc are system wide. And more for ttys.
python-pycountry dependency missing. But before adding, please merge my changes first. (Made small changes to debian/control.) (To avoid merge conflicts.)
What I wanted to say for a long time but always forgot⌠Those boxes you can check⌠They are gray. Usually the surrounding is gray, but the content of actual boxes is white. The boxes being gray is a little confusing. On first sight it reminds at other check boxes that cannot be checked. Is there a way to fix this?
It lets you continue when no settings are checked and then does nothing. This is a bit strange.
When you choose âOtherâ, it should auto check those two settings. (That would also somewhat fix the above.)
If /usr/bin/kcmshell4 is not executable, it should probably just skip the whole thing (as long as no on else adds support for Gnome etc.) (for cases where custom builders / modders install a Gnome, lxde or etc. alternative desktop environment).
We probably need to start it without root - otherwise we would change settings for the root user - but we must change settings for user âuserâ. So in this case, we must allow running without root check.
The second screen of locale_settings should tell:
(You can always change country/language again by going to Start Menu -> âŚ) (You can always change keyboard layout again by going to Start Menu -> âŚ)
?
[quote=âPatrick, post:150, topic:650â]A few whonix-setup-wizard locale_settings notes:
Itâs quite nice.
Back button works!
It lets you continue when no settings are checked and then does nothing. This is a bit strange.
When you choose âOtherâ, it should auto check those two settings. (That would also somewhat fix the above.)
If /usr/bin/kcmshell4 is not executable, it should probably just skip the whole thing (as long as no on else adds support for Gnome etc.) (for cases where custom builders / modders install a Gnome, lxde or etc. alternative desktop environment).
We probably need to start it without root - otherwise we would change settings for the root user - but we must change settings for user âuserâ. So in this case, we must allow running without root check.
The second screen of locale_settings should tell:
(You can always change country/language again by going to Start Menu -> âŚ) (You can always change keyboard layout again by going to Start Menu -> âŚ)
?[/quote]
All implemented in a batch of commits, except for the two first remarks (not much I can do about that)
Can you please make the other check boxes (repository and setup) also white rather than gray?
Do you men the language/ country and keyboard layout? But I have no white at all here (the check boxes are disabled, hence grayed). Could you post a snapshot?
There were some pyc files in the package. Not sure how that slipped through my review. Removed them. Please fetch and merge from my topic (that will remove them from your repo as well).
Do you men the language/ country and keyboard layout? But I have no white at all here (the check boxes are disabled, hence grayed). Could you post a snapshot?
Itâs the same request as this one.
But I was mistaken. In contrast to non-checkable check boxes⌠For non-disabled, checkable check boxes⌠The inner circle of check boxes is not white in other applications either. Was an optical illusion. Nevertheless, it would be a bit nicer if the inner circle of check boxes was white if the surrounding window is gray. Know what I mean?
But I guess it wonât be easy to do this. So donât put too much effort into this.
We can delete https://github.com/Whonix/whonix-repository-wizard.
Done, deleted.
I'll keep https://github.com/troubadoour/whonix-repository-wizard for the early design tricks .
Yeah. That's totally fine. It's just that https://github.com/Whonix is representative, any any deprecated packages pile up. With the exception of packages that made it into releases that are going to be deprecated (most likely control-port-filter in favor of control-port-filter-python). Because if those were deleted, old Whonix versions could be no longer be easily build from source code. Not sure if/how long that matters.
Pushed display first_use_notice only once. On second thought, not sure it's a good idea.
Dunno. That's one of the topics we need more input for.
