На Slackware14.1 и KDE4.10.5 у меня не работают хоткеи Ctrl+C, Ctrl+V и т.п. если в системе включена русская раскладка. При английской раскладке всё работает. Баг проявляется только в приложениях KDE (например Kile, Kwrite). В Libreoffice, например, всё нормально. Как это исправить?
LinuxForum.Fans
KDE-приложения и русская раскладка Slackware14.1
Автор: vvk
23 сообщений
5118 просмотров
Когда-то такой баг был в QT, но это было давно.
vvk,
можно пару слов про способ добавления русской раскладки?
vvk,
можно пару слов про способ добавления русской раскладки?
А что - есть варианты? Это уже лет 20, как нативно поддерживает xfree86/xorg и даже в базовом режиме, без расширения XKEYBOARD
s.xbatob,
по теме сказать что хотели?
У вас в Slackware 14.1 и KDE 4.10.5 в русской раскладке горячие клавиши Ctrl+C/Ctrl+V и т.п.
1) работают
2) не работают
3) частично работают (с описанием где работают/не работают)
?
Обнаружилась тут такая картина.
Slackware64 14.1, KDE 4.10.5, qt-4.8.5, русский через /etc/X11/xorg.conf.d//90-keyboard-layout.conf,
Option "XkbLayout" "us","ru"
В русской раскладке вместо Ctrl+Key срабатывают сочетания Ctrl+Shift+Key.
В английской раскладке вместо Ctrl+Key сочетания Ctrl+Shift+Key не срабатывают.
Похоже, речь про
https://bugs.kde.org/show_bug.cgi?id=320423
https://bugreports.qt.io/browse/QTBUG-15319
Может иметь (или не иметь) отношение к
https://bugs.kde.org/show_bug.cgi?id=309193,
https://bugreports.qt.io/browse/QTBUG-32908,
https://codereview.qt-project.org/#/c/96993/
Русскую раскладку добавлял по этой инструкции http://www.slackware.ru/wiki/%D0%A0%D1%83%D1%81%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F
Вот мой /etc/X11/xorg.conf.d/90-keyboard-layout.conf
text
Section "InputClass"
Identifier "keyboard-all"
MatchIsKeyboard "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
Option "XkbLayout" "us,ru"
#Option "XkbVariant" ""
Option "XkbOptions" "grp:caps_toggle,grp:switch,terminate:ctrl_alt_bksp"
EndSection
Да, действительно вместо Ctrl+C и т.п. при включённой русской раскладке срабатывают Ctrl+Shift+C и т.п.
vvk,
причём в строке поиска К-меню Ctrl+C/Ctrl+V работают правильно вне зависимости от раскладки.
Запустите xev и посмотрите, какие события приходят на нажатия клавиш и правильно ли они мапируются в символы/коды
И - я так понял в приложениях Qt/KDE всё работает правильно. А где нет - Gnome? OpenOffice?..
И - я так понял в приложениях Qt/KDE всё работает правильно
При английской раскладке всё работает. Баг проявляется только в приложениях KDE (например Kile, Kwrite). В Libreoffice, например, всё нормально
LO использует GTK+. Вывод, мягко говоря, странный.
Запустите xev и посмотрите, какие события приходят на нажатия клавиш и правильно ли они мапируются в символы/коды
И - я так понял в приложениях Qt/KDE всё работает правильно. А где нет - Gnome? OpenOffice?..
1. xev показывает, что всё обрабатывается нормально. Нажатия определяются правильно. Вот лог xev, для русской и английской раскладки он одинаковый.
Показать
text
KeyPress event, serial 40, synthetic NO, window 0x3800001,
root 0x9f, subw 0x0, time 389924, (737,577), root:(741,602),
state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 40, synthetic NO, window 0x3800001,
root 0x9f, subw 0x0, time 390596, (737,577), root:(741,602),
state 0x14, keycode 55 (keysym 0x76, v), same_screen YES,
XLookupString gives 1 bytes: (16) ""
XmbLookupString gives 1 bytes: (16) ""
XFilterEvent returns: False
KeyRelease event, serial 40, synthetic NO, window 0x3800001,
root 0x9f, subw 0x0, time 390731, (737,577), root:(741,602),
state 0x14, keycode 55 (keysym 0x76, v), same_screen YES,
XLookupString gives 1 bytes: (16) ""
XFilterEvent returns: False
KeyRelease event, serial 40, synthetic NO, window 0x3800001,
root 0x9f, subw 0x0, time 390829, (737,577), root:(741,602),
state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
2. Qt/KDE как раз не работает, а Libreoffice работает
vvk,
причём в строке поиска К-меню Ctrl+C/Ctrl+V работают правильно вне зависимости от раскладки.
Да, в строке поиска KMenu всё работает
И - я так понял в приложениях Qt/KDE всё работает правильно
1) В KWrite, Dolphin, ... при активной русской раскладке наблюдается баг, при котором Ctrl+Key не срабатывают, вместо этого срабатывают Ctrl+Shift+Key.
2) В строке поиска К-меню все работает правильно, независимо от активной раскладки.
3) В не-KDE приложениях (Firefox, LibreOffice) описанного бага нет.
Надо глянуть какое-нибудь QT, но не-KDE приложение на предмет наличия/отсутствия.
Кстати, отдельно надо глянуть, не может ли тут быть виноват caps_toggle в качестве переключателя, повторяется ли баг с другим переключателем раскладки. Хотя, с учётом (2) -- вряд ли.
1. В Qt, но не KDE приложениях всё работает как надо (QtCreator, LibreCAD)
2. Поменял caps_toggle на ctrl_shift_toggle --- результата нет. Он здесь ни при чём.
vvk,
описанное поведение полностью соответствует ранее упомянутому:
https://bugs.kde.org/show_bug.cgi?id=320423
Там же есть упоминание https://bugs.kde.org/show_bug.cgi?id=320423#c76 , что откат QTBUG-15319 ситуацию исправляет.
В Slackware-вских исходниках qt в каталоге /source/qt откатываемый фрагмент присутствует.
Осталось проверить, пересобрав qt с патчем из упомянутого выше комментария и переустановив собранный пакет.
Точно, была такая бага! Только она исправлена больше года назад. Я про неё уже забыл. Неужели она в Slackware до сих пор не в upstream?
s.xbatob,
Slackware 14.1 вышла
text
+--------------------------+
Mon Nov 4 17:08:47 UTC 2013
Slackware 14.1 x86 stable is released!имея в составе стоковый qt-4.8.5.
Согласно https://bugreports.qt.io/browse/QTBUG-15319 первый (явившийся причиной ошибки) фикс вошел в 4.8.5. Исправление QTBUG-15319 вышло давно, но только в qt5.
Поэтому в том, что в релизе qt-4.8.5 имеет место баг релиза qt-4.8.5, ничего удивительного не вижу.
bormant, Ну, замечательно! Только в других дистрибутивах это исправлено. В Fedora этой проблемы точно давным-давно нет.
s.xbatob,
в Slackware тоже давно исправлено:
http://slackware.osuosl.org/slackware64-current/ChangeLog.txt
text
+--------------------------+
Tue Apr 29 23:35:59 UTC 2014
l/qt-4.8.6-x86_64-1.txz: Upgraded.
http://slackware.osuosl.org/slackware64-current/source/l/qt/
В Fedora было исправлено в Fedora-19:
* Thu Sep 12 2013 Rex Dieter <rdieter@fedoraproject.org> 4.8.5-8
- Keyboard shortcuts doesn't work for russian keyboard layout (#968367, QTBUG-32908)
Кстати как? Затыканием головы в песок (откатом QTBUG-15319 и неработой шоткатов при первой не-US раскладке, вроде ru,us)?
И тут же:
Dmitry Veltishev 2014-06-02 09:49:14 UTC
Still having this issue with Qt 4.8.6 on FC20.
https://bugs.kde.org/show_bug.cgi?id=320423#c58
Someone 2014-08-24 18:44:47 UTC
This is present in Plasma 5 (Plasmashell) though..
https://bugs.kde.org/show_bug.cgi?id=320423#c72
Спасибо за помощь! Пересобирать я ничего не стал, а вместо этого я взял пакет qt-4.8.6 от slackware-current и, пользуясь тем, что в Slackware отсутствуют зависимости, заменил им системную qt. Теперь всё работает как надо.
пользуясь тем, что в Slackware отсутствуют зависимости
Это утверждение неверное.
Пакетный менеджер Slackware не поддерживает автоматическое отслеживание зависимостей пакетов. Однако, это вовсе не означает, что файлы пакетов не имеют зависимостей времени исполнения.
Другое дело, что эти зависимости до определенной меры гибки, ровно до той степени, пока сохраняется интерфейс между
1) использующими библиотеку и самой библиотекой
2) самой библиотекой и используемыми ей библиотеками
Когда изменения слишком велики (как правило по тем или иным причинам выброшено что-либо), принято изменять номер библиотеки таким образом, чтобы исключить динамическое связывание с ней прежних версий. Изменения минорных версий, как правило, подобных изменений лишены.
Тем не менее, нужно быть готовым к тому, что взяв пакет из -current после того, как в -current уже были внесены существенные изменения (как правило основа основ -- glibc, и т.п.), есть риск получить глюки. Тем выше риск, чем дальше -current убежал по базовым компонентам от используемого релиза.
Войдите или зарегистрируйтесь, чтобы ответить.
