release 0.20

[hsitter]

• mark wayland support experimental (in changelog?)
• revert locale1 use for keyboard configuration for later refinement before we declare wayland support stable org.freedesktop.locale1 integration destroys existing keyboard layout configuration #1669
• make changelog
• bump version
• make tarball
• create release on GH

[hsitter]

@aleixpol for #1669 @davidedmundson and I are thinking that we can unblock 0.20 by simply declaring wayland support experimental for this release and revert the locale1 use for the time being. What's your thinking on this?

also CC @Vogtinator

[Vogtinator]

I switched the order of the list around a bit.

@aleixpol for #1669 @davidedmundson and I are thinking that we can unblock 0.20 by simply declaring wayland support experimental for this release and revert the locale1 use for the time being. What's your thinking on this?

+1

[aleixpol]

Reverting the locale1 change also leaves us without any way to switch locales.

Declaring it experimental is fine, reverting I think breaks even more than the current implementation does.

[alebastr]

Reverting the locale1 change also leaves us without any way to switch locales.

kwin_wayland --locale1 should handle switching even without a language indicator in the sddm greeter. But it doesn't work anyways, as locale1 support in kwin is broken:

    xkb_rule_names ruleNames = {
        nullptr,
        qPrintable(properties["X11Model"].toString()),
        qPrintable(layouts),
        qPrintable(properties["X11Variant"].toString()),
        qPrintable(properties["X11Options"].toString()),
    };

The code creates a bunch of temporary QByteArrays that are destroyed right after this statement and xkb_rule_names contains garbage:

Jun 23 02:16:36 sddm-helper-start-wayland[2333]: "kwin_xkbcommon: XKB: Compiling from RMLVO: rules 'evdev', model 'pc105', layout '\xEF\xBF\xBD\xEF\xBF\xBD""C\xEF\xBF\xBD\xEF\xBF\xBDU', variant 'r', options 'grp:alt_"
Jun 23 02:16:36 sddm-helper-start-wayland[2333]: "shift_toggle'\n"

Once you fix this (by creating proper non-temporary QByteArrays just like in Xkb::loadKeymapFromConfig), you can get the switching working:

Jun 23 02:30:59 sddm-helper-start-wayland[2520]: "kwin_xkbcommon: XKB: Compiling from RMLVO: rules 'evdev', model 'pc105', layout 'us,ru', variant '', options 'grp:alt_shift_toggle'\n"

As for the language indicator in sddm - it could be hidden on Wayland until a better implementation appears.

[Vogtinator]

Reverting the locale1 change also leaves us without any way to switch locales.

kwin_wayland --locale1 should handle switching even without a language indicator in the sddm greeter.

Not sure what you mean. Without the indicator, how would you switch?

The issue with the locale1 way of switching keyboard layouts is not that it didn't work, it's that it irreversibly destroyed the system configuration.

But it doesn't work anyways, as locale1 support in kwin is broken:

Can you report that upstream and/or provide a MR?

[alebastr]

Not sure what you mean. Without the indicator, how would you switch?

$ localectl
System Locale: LANG=en_US.UTF-8
    VC Keymap: us
   X11 Layout: us,ru
  X11 Options: grp:alt_shift_toggle

With the grp:alt_shift_toggle that is configured via regular keyboard configuration tool (OS installer, GUI configurator from the user session or even localectl).
I'll be sad that there's no visual indication of a currently active layout, but it's not a fatal flaw.

Can you report that upstream and/or provide a MR?

https://invent.kde.org/plasma/kwin/-/merge_requests/4209

[alebastr]

Not sure what you mean. Without the indicator, how would you switch?

The issue with the locale1 way of switching keyboard layouts is not that it didn't work, it's that it irreversibly destroyed the system configuration.

Apparently, KWin-specific implementation for layout selection indicator already exists (https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2088), works perfectly with fixed kwin_wayland --locale1, makes the layout switcher behave exactly the same way as on X11 and is non-destructive. It looks like the right approach to me, so I have no idea why it was abandoned.