Two other possible ideas:
either a “has feature” or “doesn’t have feature” list ↩︎
The WebUI uses Patternfly, which doesn’t guarantee accessibility, but should make it relatively easy to do the right thing.
I’d say either way it’s important to make it clearer what these messages talk about: “this system” is not clear at all. You can only understand it together with the warning: “oh, you mean the (to be) installed system, not this system I’m using right now”.
And once it’s clear that these settings are about the installed system there should be no surprise that the currently running system remains unchanged.
… unlessed I’m confused, too 
Is the initial question “which … do you want to use for the installation process” gone?
- Reverse #2. That is, have a flag for spins which don’t implement systemd-localed functionality.
Looks to me fragile but I’m not opposed to this. I just wonder what would be the benefit.
- Maintain a list[1] of spins and enable or disable the warning based on that.
If possible, I would like to avoid having a hardcoded list in Anaconda. Most of the time that is something you don’t want to have because it’s harder to enable. Situations like my custom spin or I’m just playing around makes the situation worse.
No, that question should stay there. Only the highlighted parts are impacted.
Heh, that label is there for a quite long time, maybe it’s worth to think about the change. Anyway, it seems to me that this idea it is not correct. If we wrote there that these keyboard layouts are only for the installed system that is not correct neither because if systemd-localed is supported by the system it will be propagated.
Anyway, this points me to another option:
Change to message:
“Which keyboard layouts would you like to use on this system?”
To something like:
“Configure keyboard layouts for installed system. If Anaconda keyboard layout switching is supported by the system it will be set to the currently running system.”
However, it would be still confusing because you would see keyboard layout switch in the right corner (not visible on the picture because it’s disabled) I’ll add another picture next to it to show the difference.
I’ve changed the pictures above to make obvious what is changing. Also, I missed to highlight the button in the right corner at first.
In short without this feature, users would have visible current keyboard layout switching everywhere in Anaconda.
Hi, I’m thinking about starting a project to enable the new keyboard switching solution on X11 based systems. However, I wanted to be sure that no-one already done that or started the effort.
If someone knows about that please tell me.
Hi everyone, we released new Anaconda on last week with these changes. Currently there are some issues in the Open QA but we are working on resolving these so during this week the changes should be visible in Rawhide.
So the update got in yesterday:
https://bodhi.fedoraproject.org/updates/FEDORA-2024-e22ef7a242
If you see any issue with Anaconda running on Wayland please make us aware of that.
Hi all,
I would like to notify you about a change we decided to implement to improve the robustness of the keyboard layout switching which is part of this change.
Anaconda will not support keyboard switching by keyboard shortcuts. Users should use the icon in GTK UI which will still work as expected.
This is not related to Web UI in any way.
In this change we were required to drop our keyboard switching library libXKlavier and switch to localed. The localed solution was designed as bi-directional communication layer between Anaconda and the running system. The idea was that if the user will set keyboard layout in Anaconda then Anaconda will set this layout to localed and that will be set to system. This part works as expected if the system we are running on implements it (most should be covered).
However, we also thought about the other direction, where the system will change layout (by keyboard shortcuts usually) and set that to localed and Anaconda will react to that by setting the layout info in the top bar. This feature is harder to achieve than we expected, we already know about at least two issues where this is not working as expected and it would probably be in most of the other places. The issue is that something like keyboard layout change is not a simple term for the system to resolve for multiple reasons:
After hitting this issue, we have decided to change this logic to one-direction which means Anaconda will always force user configuration to the running system. The drawback is that we are not able to support keyboard switching by keyboard shortcut as we have done until now but you can still use the top bar icon to switch the keyboard layouts.
PR to implement this:
I will update existing bugs and issues on desktops about this change.
ping @adamwill