gnome-initial-setup, language and keyboard layout choice #512
Labels
No labels
a11y
btrfs
Closed As
Can't fix
Closed As
Deferred to upstream
Closed As
Fixed
Closed As
Won't fix
default-apps
easyfix
experience
help-wanted
installation
meeting
meeting-request
nvidia
packaging
pending-action
qa
testing
user-docs
wg-docs
wg-meta
No milestone
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
workstation/tickets#512
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
In https://src.fedoraproject.org/rpms/gnome-initial-setup/c/76c62029d39ec7653e82b34fca29243dba39bf8f?branch=rawhide, a vendor config for gnome-initial-setup was added to disable language & keyboard selection for the gnome-initial-setup dialog on first boot after a fresh installation from Anaconda (the configuration option name is confusing, I had to read https://gitlab.gnome.org/GNOME/gnome-initial-setup/-/blob/master/README.md?ref_type=heads&plain=1#L105).
But I don't think that it's the logic that we would want. The idea behind the split between the Anaconda installer and the initial system & user setup on first boot is that you can have someone do the installation, potentially automated via Kickstart, and then hand over the computer to someone else that will create their user on first boot and select their language. The language & keyboard selection in the installer step can not predict what a user will want to use, they should be set to defaults that match the physical keyboard layout to avoid confusion on first boot but that's it. Anything else is picked by the user who may change the default language for the system or use another layout.
This is a flow very similar to what you get when you boot a macOS or Windows system for the first time after installation and I think it's the same flow we have in KDE Plasma Setup.
So I'm opening this here to start a discussion.
This came up as we had done a workaround Silverblue in
atomic-desktops/config@4fa76fea06for https://bugzilla.redhat.com/show_bug.cgi?id=2362164 and we are now stepping on each others toes, so Adam W. started a discussion in https://github.com/fedora-silverblue/issue-tracker/issues/700.Note that there was a practical benefit to hiding these pages: it means we don't have to care about things like g-i-s still not knowing how to do switched keyboard layouts properly. If we put them back, we really ought to fix that. As the Resident "Awkward Input Cases" Nerd, I appreciate having as few places as possible to try and keep an eye on for switched layout and input method problems.
I can see both arguments in theory, tbh. I'd say that in the majority of cases repeating the choices is just needless confusion and a bug entry vector. In a minority of cases it's exactly what is desired.
How big is the majority, how small is the minority? I don't know.
Then at least we should keep the language part and disable the keyboard one. Users can figure out the keyboard layout by looking at the key, not so much the language.
My primary goal was to not break Reduce Initial Setup Redundancy. The principle is we should not ask the same question more than once. But I agree, that's a problem for OEM style install, where the user does not perform the install themselves. We should probably have a separate OEM mode that somehow flags gnome-initial-setup to run language and keyboard layout selection again. But I'm not sure how exactly we would do that. We would need: (a) some way to tell anaconda that this is an OEM install (perhaps a flag in kickstart?), and (b) some way for anaconda to tell gnome-initial-setup that this is an OEM install.
P.S. I'm planning to work on #504 soon, so if anybody is interested, now would be a good time to focus on this.
https://gitlab.gnome.org/GNOME/gnome-initial-setup/-/work_items/103 is going to be a problem soon regardless due to #504.
I see that I forgot to update this issue after the last meeting, where we've talked briefly about it. WG members see the use-cases brought by @siosm valid, but we currently don't have a way forward and @catanzaro will explore it more once he will start to work on #504. He raised a question though whether web based Anaconda still supports the configuration of what it will present as part of the wizard (what used to be spokes in the old Anaconda) and then instructing GNOME Initial Setup to what it should present/hide. I wanted to mention Aleksandra here, but it doesn't seem that I can, so I will ping her.
In the interest of keeping things aligned as much as possible and to keep the test matrix reasonable for Adam, I'll update Silverblue to follow the same logic as Workstation and we can revisit that later.
We can live with Silverblue keeping its current behavior for now, if you prefer, it's not really a problem.
OK, I'll try the current installation flow again to refresh my memory of how this works. I've also made atomic-desktops/config#765.