GNOME Bugzilla – Bug 695823
some key combination for typing not working
Last modified: 2021-07-05 14:12:23 UTC
Zenkaku_Hankaku key is designed to switch half-width and full-width character, which nearly means turning on/off input method and widely used in various input methods on Windows say. shortcut key settings on control-center accepts that. but it doesn't take any action. aside from that, apparently shift + something combination also not working, which is also accepted on control-center's UI. though apparently it looks like implicitly reserved modifier key to move back. though it looks strange to me since they have "Switch to previous input source" configuration and is disabled.
(In reply to comment #0) > Zenkaku_Hankaku key is designed to switch half-width and full-width character, > which nearly means turning on/off input method and widely used in various input > methods on Windows say. This is being discussed in bug 682319, can you comment there? The specific question is how do you think this key should behave: a) as a general switch forward through all input sources; or b) as a toggle switch latin <-> hiragana key? > aside from that, apparently shift + something combination also not working, > which is also accepted on control-center's UI. though apparently it looks like > implicitly reserved modifier key to move back. though it looks strange to me > since they have "Switch to previous input source" configuration and is > disabled. Can you be a bit more specific here? The default shortcut for the switch-input-source keybinding is Super+Space. It happens that the general infrastructure we have in mutter/gnome-shell to handle these keybindings implicitly assumes Shift+"regular keybinding" to mean "go backward". We also have a switch-input-source-backward keybinding though that you can set if you want. It's the same as the switch-windows keybinding for instance. Or are you referring to the modifiers-only keybinding which works differently?
(In reply to comment #1) > This is being discussed in bug 682319, can you comment there? The specific > question is how do you think this key should behave: > > a) as a general switch forward through all input sources; or > b) as a toggle switch latin <-> hiragana key? Does b) mean one needs a global shortcut key to switch engines to corresponding engine and the engine-specific shortcut key (I'm assuming Zenkaku_Hankaku key here) will works to switch the input mode between Latin and Kana then? If so, I'd prefer a) then. or I should make that ibus engine as primary input source and settle it down in engine itself to default Latin there. dunno. anyway, my objection here is, acceptable keybindings doesn't work as expected. > Can you be a bit more specific here? > > The default shortcut for the switch-input-source keybinding is Super+Space. It > happens that the general infrastructure we have in mutter/gnome-shell to handle > these keybindings implicitly assumes Shift+"regular keybinding" to mean "go > backward". We also have a switch-input-source-backward keybinding though that > you can set if you want. It's the same as the switch-windows keybinding for > instance. > > Or are you referring to the modifiers-only keybinding which works differently? Well, just my guess. due to the above implication, for instance, currently control-center accepts Shift+Henkan_Mode for switch-input-source though, it doesn't take any actions when pressing that key. presumably isn't gnome-settings-daemon looking for function that Henkan_Mode is being assigned to behave its backward? Given that it's true, why don't you set Shift+"regular keybinding" to blahblahblah-backward as default keybinding and stop implying it with Shift key combinations?
(In reply to comment #2) > (In reply to comment #1) > > This is being discussed in bug 682319, can you comment there? The specific > > question is how do you think this key should behave: > > > > a) as a general switch forward through all input sources; or > > b) as a toggle switch latin <-> hiragana key? > > Does b) mean one needs a global shortcut key to switch engines to corresponding > engine and the engine-specific shortcut key (I'm assuming Zenkaku_Hankaku key > here) will works to switch the input mode between Latin and Kana then? > > If so, I'd prefer a) then. or I should make that ibus engine as primary input > source and settle it down in engine itself to default Latin there. dunno. As I said, this should really go into bug 682319. > anyway, my objection here is, acceptable keybindings doesn't work as expected. > > > Can you be a bit more specific here? > > > > The default shortcut for the switch-input-source keybinding is Super+Space. It > > happens that the general infrastructure we have in mutter/gnome-shell to handle > > these keybindings implicitly assumes Shift+"regular keybinding" to mean "go > > backward". We also have a switch-input-source-backward keybinding though that > > you can set if you want. It's the same as the switch-windows keybinding for > > instance. > > > > Or are you referring to the modifiers-only keybinding which works differently? > > Well, just my guess. due to the above implication, for instance, currently > control-center accepts Shift+Henkan_Mode for switch-input-source though, it > doesn't take any actions when pressing that key. Yeah, this is a bug in g-c-c — it accepts key combinations that don't work. > presumably isn't > gnome-settings-daemon looking for function that Henkan_Mode is being assigned > to behave its backward? > Given that it's true, why don't you set Shift+"regular keybinding" to > blahblahblah-backward as default keybinding and stop implying it with Shift key > combinations? I'm not sure what you mean here. The very nature of using an OSD switcher implies that we need a modifier+regular key since the OSD remains up until the modifier is released. Also, OSD switchers, being lists, can be traversed forward or backward and the traditional way to switch in the backwards direction is pressing shift (analogous to keynav in applications) which means that you can't have just Shift+regular key for this shortcut. Maybe your use case would be better served by the other kind of shortcut? The one that doesn't show an OSD.
*** Bug 695372 has been marked as a duplicate of this bug. ***
*** Bug 693395 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > Also, OSD switchers, being lists, can be traversed > forward or backward and the traditional way to switch in the backwards > direction is pressing shift (analogous to keynav in applications) which means > that you can't have just Shift+regular key for this shortcut. I'll take that back. You are right. These implicit shift == backwards thing we do sucks and prevents use cases like yours to work. Here's a pair of patches that should make it work.
Created attachment 240446 [details] [review] schemas: Provide a default for switch-input-source-backward We are removing the switch-input-source keybinding behavior of silently forging a fake backward keybinding by adding Shift to the regular combo since that prevents it being defined to otherwise valid combos like Shift+Hangul. As such we should provide a default for the explicit -backward keybinding.
Created attachment 240447 [details] [review] status/keyboard: Disregard the backwards flag for the popup switcher This seems to cause more harm than good. It puzzles users looking at the shortcuts list in g-c-c and it prevents otherwise valid shortcuts like Shift+Hangul from working.
*** Bug 703956 has been marked as a duplicate of this bug. ***
i cant switch input language between english and korean language. mostly, we can use hangul key i use ubuntu gnome 13.10, gnome 3.8.4 on acer aspire one 756 laptop computer.
I am almost sure what prevents to use "Hangul" key: Korean users use "Hangul" key as default for switching input between English and Korean Hangul. Keyboards with this additional keys are common in the Korean PC market and people have used it for decades, so remember that we can never change this. The problem is this key is implemented in XKB Korean keyboard layout "kr" and "kr104". So after switching XKB to English, this key is not available so users can't switch back to Hangul! I'm not sure how to fix this. Should "Hangul" key be implemented in a different way? I am the one who contributed the "kr"/"kr104" layouts so suggestion of changing XKB is also welcome.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.