This happens with xfce4-settings git head, as per October 7, commit 894db1, but also happens on earlier releases. When adding one or more layouts with variants, or changing the default layout in a list of those, the variants are frequently dropped or even moved to a different layout (which then breaks entirely). Unfortunately this seems to be somewhat random, but I played around with three layouts "us", "de,nodeadkeys", and "de,drovak", and I've seen combinations like <property name="XkbLayout" type="string" value="us,de,de"/> <property name="XkbVariant" type="string" value=""/> (i. e. dropped both variants) <property name="XkbLayout" type="string" value="de,us,de"/> <property name="XkbVariant" type="string" value="dvorak,,"/> (dropped one variant) or, after deleting the two German layouts, <property name="XkbLayout" type="string" value="us"/> <property name="XkbVariant" type="string" value="nodeadkeys"/> (broken) or <property name="XkbLayout" type="string" value="us"/> <property name="XkbVariant" type="string" value=","/> (somewhere in the internal state it thinks that it still has variants for two layouts) It seems to be reasonably well reproducible with starting with Layout="us" and Variant="", and adding de/nodeadkeys to it, without changing the default. This results in an empty variant for German.
Note that while the dialog is still open, the displayed layouts/variants are correct, but the xfconf values are written wrongly. If you close and reopen the dialog, the displayed values are wrong, too, of course.
I'll debug this now and work on a fix.
Created attachment 3134 Fix handling of empty keyboard variants Ah, that wasn't too hard. Turns out that empty variants came back as a NULL value instead of "" from the tree iterator, so we tried to concat NULL, comma, next value, which just resulted in NULL. This also explains the xfconf_channel_set_string assertion failures that were commonly seen.
Patch committed and pushed to git head. Thanks a lot.