How Qubes installation manages keyboard layout?

Indeed, it is a serious issue, which I’m also suffering from. @adw shouldn’t it be a blocker for 4.2?

1 Like

Well, that’s a decision for @marmarek. What issue are you referring to, exactly? Please provide the qubes-issues link or issue number. Several different ones have been mentioned/linked in this thread, so I’m not sure which one we’re talking about.

Maybe some meta-issue should be created, like “Make layout switching work correctly with propagation approach” (affects-4.1 and -4.2). Because there are at least 3 independent problems as I mentioned above. One is probably fixed, second half-fixed and one not even reported as a separate issue (about double events that have ~1s distance and break layout if user changes active qube during ~ 1s after keyboard layout switch). If you want, I can combine a meta-issue and report the 3rd problem, currently it is only mentioned in comment to other keyboard layout issues.

1 Like

We currently don’t allow meta-issues in the issue tracker. We use projects instead. However, only qubes-issues editors can create projects, and they’re only created when they’ll assist the developers in their work.

Please do create the missing separate issue.

Also, no one has provided an issue number or link for the issue(s) that should be considered 4.2 blockers. If you’d like the priority of such issues to be reconsidered prior to the 4.2 stable release, please do so now.

Meta issues are good stuff to track such multi-bug problems, maybe reconsider one day :slight_smile:

OK, I will report it today.

I will make several comments on github to organize keyboard layout issues better.

Currently I see independent problems:

  1. Issue #8230 - Layout switching eventually breaks key mapping
    Fixed by PR by github user solardiz. They also fixed another layout issue.

  2. Issue #8035 - Change of keyboard layouts with Capslock/Shift+Capslock (shift_caps_switch in setxkbmap) breaks all the time
    Probably fixed by @marmarek’s this commit and my PR (accepted today).

  3. The new issue I will have to report today about double delayed events.

1 Like

I do not insist about blocker status, only if you and the Team think it should be. I personally agree that broken layout switching is unacceptable for majority of non-US users and should be addressed as top priority.
It is also proven to be so by poll/post about what people want in R4.2.

And if you do decide to use blocker for R4.2 than this issue can be used as one that describes the problem in general. Of course, this issue affects-4.2 at the moment, I believe.


Thanks, @balko! This is all very helpful! :slight_smile:

We’re always open to considering better ways of doing things. The main problem with meta-issues is that they don’t seem to do anything that projects don’t do better, and they clutter up the issue tracker with issues that aren’t actionable until each of their sub-issues is closed. Projects seem specifically designed to do the job of meta-issues but better. If there are good arguments in favor of meta-issues, I’d like to hear them.

1 Like

Maybe projects are even better! I was not using them.

About current situation: I think, there is no need to create meta or project for that. We have one general issue that combines possible bugs about layout and that can be used. I also think that most of layout switching issues are fixed (hopefully) by now. One or two steps left to make people enjoy their layouts as it was on R4.0 but now with more universal propagation approach.