| Summary: | Keyboard layout switcher does not work | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Ilya <neptunia> |
| Component: | system | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | bugwatch, darrella, johnbull1066, julius.schwartzenberg, michele.calgaro, ogldelphi, sid_evg, slavek.banko |
| Priority: | P5 | ||
| Version: | 3.5.13.x [Trinity] | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Bug Depends on: | |||
| Bug Blocks: | 2247 | ||
| Attachments: |
add russian layout
xkb options |
||
|
Description
Ilya
2009-07-02 08:53:25 CDT
Yes, russian keyboard switch doesn't work, but we are using a workaround called kkbswitch (http://kkbswitch.sourceforge.net/). Is it possible integrate it in Trinity? Actually the standard layout switcher works well here on KDE 3.5.10 in openSUSE. It works flawlessly. So you are only running into an issue with the keyboard shortcuts? Can you please provide a brief test case, describing: 1.) Your interaction with the program (in detail, e.g. I press "alt+something" when I am at the main Trinity desktop) 2.) What you expect to happen 3.) What actually happens? This will help us isolate the offending code rapidly. Thanks! All works well for me now. If this is no longer a bug in version 3.5.12 or higher of Trinity, please close this bug report as RESOLVED INVALID. Thanks! Created attachment 74 [details]
add russian layout
add russian layout.
Created attachment 75 [details]
xkb options
xkb options
I add russian layout and set xkboptions to Alt+Shift and press Apply. So, if I press Alt+Shift - nothing happens and layout doesn't switch as it is in standart KDE 3.5.10. Am I doing something wrong? (In reply to comment #9) > I add russian layout and set xkboptions to Alt+Shift and press Apply. So, if I > press Alt+Shift - nothing happens and layout doesn't switch as it is in > standart KDE 3.5.10. > Am I doing something wrong? Which version of KDE3/Trinity are you experiencing this problem under? (In reply to comment #10) > Which version of KDE3/Trinity are you experiencing this problem under? I'm using TDE 3.5.12 with Debian Squeeze Same with 3.5.13 nightly build. This problem is a regression that is related to newer versions of the X.org X11 server. It does not seem to be related to the version of setxkbmap however, but really to the version of X11 server. I do not have this problem with the stock X.org server from Ubuntu Lucid (version 1.7.6). When I upgraded my X.org server on Lucid to version 1.10.4 the switching stopped working properly for me. Now I'm running Trinity on Ubuntu Precise (12.04) with X.org version 1.11.3 and it does not work either. The problem is in at least version 3.5.11 and 3.5.13 of Trinity. KDE4 does not have any problems and works fine with the newer X.org server versions. Debian Squeeze uses X.org 1.7.7 it seems, so maybe the problem is related to a change that happened between X.org 1.7.6 and 1.7.7. The flag of Trinity's layout switcher does get updated properly and is also remembered for each window if you have a separate layout per window. The layout always stays on the first one however. There is one work-around: When you press the key you use to switch layouts and then also press any other key before you release the switching key, there will be a proper switch to the new layout. This is then even remembered properly for that window as well. Timothy, this can be complicated to understand and reproduce if you are not experienced with special keyboard layouts. If you need help with reproducing this you can write me any time on IRC (Z_God) and I will help with reproducing this problem. It is very inconvenient for users that need to write multiple alphabets so a solution would be very welcome. It seems that initially after start-up, this bug does not occur. After restarting the layout switcher, it will work properly for some seconds (or switches?) and then it will be broken again. Is this bug still happening in the R14 nightly builds? I have been debugging the kxkb tool and have yet to see any truly broken behaviour, although the documentation for kxkb does not generally line up with how the program actually behaves. It still doesn't work here, the installed tdebase-trinity-bin package version is: 4:14.0.0-0ubuntu7+r735+pr47~precise More info on the exact behavior. When you quit kxkb and the start it again, the first switch will always work correctly! The second time an attempt to switch is made, only the flag changes (except when using the work-around: holding an extra button). Restarting kxkb will once again allow the switching to work once properly and then it breaks again. I use caps lock to switch between layouts here btw., which is a common key for this purpose. Once you add grp:caps_toggle to your xkboptions, you can also change the kxkb shortcut from ctrl+alt+k to it. (It should show up as ISO_NEXTGROUP or something like that.) I think with the default ctrl+alt+k I saw the exact same issue however. This problem does not occur on Debian Squeeze with X.org 2:1.7.7-14, it seems to be a Ubuntu-only issue. I just reproduced this problem in Ubuntu Natty. It initially did *not* occur with the default shortcut ctrl+alt+k, but when I switched it to ISO_Next_Group, the switching stopped working correctly. I don't think there is a way to change the shortcut, which in and of itself qualifies as a bug. What you probably changed was a shortcut key for the underlying xkbd program. There is: 1. Open the "Keyboard & Mouse" control pane 2. Goto Keyboard Shortcuts 3. Under "Shortcut Schemes", "Global Shortcuts", scroll to the bottom There you will find "Switch to Next Keyboard Layout". This shortcut should be set to ISO_Next_Group (by pressing the key that's set switch the group in xkb, I use caps). Seems I found the cause of the issue. Starting with Ubuntu Natty, a patch 208_switch_on_release.diff is included in the xorg-server package which alters the xkb layout switching behavior. This breaks Trinity's kxkb. It does not break the layout switcher in KDE 4, so it should be possible to work around this on the Trinity side. On Debian, this patch is not included and everything works correctly. The stock X.org versions on Lucid and Maverick also do not have this patch and they also do not have the issue. The problem exists in Ubuntu Natty and later versions of Ubuntu. It seems this switch_on_release patch is intended to solve this issue: https://bugs.freedesktop.org/show_bug.cgi?id=865 https://bugs.archlinux.org/task/29190 The patch has also been included in OpenSUSE at one point or another (I'm not aware of the current situation), which explains why Ilya saw the same issue on OpenSUSE. https://build.opensuse.org/package/view_file?file=switch_on_release.diff&package=xorg-x11-server&project=home%3Aslavb18%3Abranches%3AX11 Is this problem still valid? For 3.5.13.1 it is still an issue. As soon as the nightly build will be useable, I will try this for R14, but it's likely the problem is not solved yet. Is this report still valid? Probably yes. More investigation shows that this is related to the DCOP signal being sent and processed as soon as a key is pressed instead of when it is released. I will test it again with the new nightlies to be sure however. I just tested. This bug is still present in the current R14 nightlies. It's 2019 and I'm still having this issue? Will this ever be fixed? This has been fixed by the following PR on TGW: https://mirror.git.trinitydesktop.org/gitea/TDE/tdebase/pulls/304 Please reopen this bug (or better file an Issue on TGW) if you still have issues. |