Obscure shortcut selector behaviour

[Rulon Oboev]

I'm trying to set a shortcut for keyboard layout switching, but it's impossible to use some keyboard buttons. Also, pressing some combinations leads to unexpected results.

For example:

- Shift+Ctrl - impossible to set
- Shift+Alt - impossible to set
- Ctrl+Alt - impossible to set
- Shift+Ctrl+Alt - impossible to set
- Shift+Alt+Space - this combination is being detected as "Shift+Space"
- Cmd (Win) + any two or three keys is impossible to set (works with 4 keys though).

Since Shift+Ctrl and Shift+Alt are very popular shortcuts (due to being default in Windows for ages), not being able to use them in Ubuntu is a pain.

Reproduction steps:

- Open gnome-control-center
- Go to "Keyboard shortcuts"
- Try to change any shortcut to one from my list

System info:

Ubuntu 20.10
gnome-control-center:
  Installed: 1:3.38.1-1ubuntu1
  Candidate: 1:3.38.1-1ubuntu1

[Gunnar Hjalmarsson (gunnarhj)]

Thanks for your report.

This is an upstream GNOME matter, and should better be discussed there. OTOH, it looks like the discussion has already started.

https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1222

So possibly in GNOME 40 (Ubuntu 21.10).

However, in the meantime you can use another mechanism for setting input source shortcuts. It's available in Tweaks (you need to install gnome-tweaks) and allows several combinations which can currently not be selected via Settings.

[Gunnar Hjalmarsson (gunnarhj)]

On 2021-01-27 08:24, Daniel van Vugt wrote:
> ** Tags added: groovy

Let me ask out of curiosity: Why did you add that tag?

The issue at hand has been there for many cycles. While I see that the OP happens to use groovy, I don't see how the tag adds any relevant info from a bug triaging POV.

[Daniel van Vugt (vanvugt)]

It's a handy tool for dealing with masses of bugs, on average. When a release reaches end of life we can then quickly identify which bugs are no longer affecting any supported release, and close them. This prevents the backlogs from growing indefinitely and has been quite successful...

https://docs.google.com/spreadsheets/d/e/2PACX-1vRDHPxGBHqM6XkT_S8ggtYfD0xchKSUD_z9PopNVE3G1rU05fVSnxDGcDsEstl7gu7N-tzCU6mLUp2V/pubchart?oid=254968654&format=interactive

If you are confident that other releases are affected then just add more tags like 'focal'. And then the bug is protected and will stay open for years to come.

[Gunnar Hjalmarsson (gunnarhj)]

On 2021-01-28 04:29, Daniel van Vugt wrote:
> When a release reaches end of life we can then quickly identify which
> bugs are no longer affecting any supported release, and close them.

That's what I suspected. ;) While I understand, I don't really like it. For bugs of some significance I would prefer them to stay until resolved. For truly upstream and less important bugs, why not just point the bug reporter to upstream and close it with "won't fix", with the explanation that we don't have the resources to fix it in Ubuntu only.

> If you are confident that other releases are affected then just add
> more tags like 'focal'.

Done.

[Daniel van Vugt (vanvugt)]

Any bug reported through the ideal means of 'ubuntu-bug' or from errors.ubuntu.com will get the tags automatically. So the tags themselves are not new.

As for people who don't like the process, that's OK. I find about one in 400 bugs receive a complaint from affected persons. And one in 400 is pretty low so I consider the procedure a success.

[Daniel van Vugt (vanvugt)]

Actually it's much less than one in 400. Most complaints are just "you didn't fix my bug and this is the first notification I've received in N years".

[Gunnar Hjalmarsson (gunnarhj)]

On 2021-01-28 04:58, Daniel van Vugt wrote:
> Any bug reported through the ideal means of 'ubuntu-bug' or from
> errors.ubuntu.com will get the tags automatically.

Ah, ok.

> As for people who don't like the process, that's OK. I find about one
> in 400 bugs receive a complaint from affected persons. And one in 400
> is pretty low so I consider the procedure a success.

Not sure that's the most adequate way to measure the success of the current workflow.

The ultimate purpose of the bug tracker is to improve the quality of the software we make available. The method I outlined would probably result in fewer open bugs, but they would be closed more transparently, and which bugs would stay and which ones would be closed would be determined based on importance and thus less randomly.

There may well be aspects that I miss, but how about giving my idea a thought? :)

@Rulon: Please bear with us for using your bug report for discussing a much more wide topic than the specific issue you reported.

[Daniel van Vugt (vanvugt)]

Bugs are never closed "randomly". Only those that are:

 * Fixed; or

 * Don't have enough information and the reporter fails to respond to questions for 60+ days; or

 * Aren't immediately reproducible, and have no evidence of affecting a currently supported release, and the user fails to respond to further questions.

I think you're getting worried over very little, and the method you describe is one of the things I already do.

[Gunnar Hjalmarsson (gunnarhj)]

Hey, Daniel, please don't sound as if I had questioned the whole workflow for your great work with triaging desktop bugs. It was certainly not my intention to do that; my apologies if it sounded otherwise.

What I brought up was that tag - and the way you said in comment #3 you use it occasionally. In summary, what I want to say is simply: Use that strategy with caution.

As regards the possible approach I mentioned, let's take bug #1913222 as an example (with the same bug reporter as this one).

- Upstream in nature (and reported upstream)
- Low importance
- Very unlikely to be patched in Ubuntu
- "groovy" tag even if the behavior is not specific to groovy

That combo makes me think that "won't fix" would be a proper status right now. I don't see how it's useful to keep it open in Ubuntu's bug tracker for a few months, and then close it in July due to EOL (which would be a reason hard to understand for the bug reporter, who will most likely see the same thing in hirsute).

[Sebastien Bacher (seb128)]

Daniel, Gunnar, it sounds like email would be a better venue to continue this discussion!