[gentoo-user-ru] linux hotkeys suxx

[gentoo-user-ru] linux hotkeys suxx

[Alex Efros]

Hi!

Походу, с горячими кнопками в линухе творится какая-то фигня. В принципе,
это не новость, все давно в курсе. Но я тут на днях снова погулял по этим
граблям, поэтому решил описать всё на что наткнулся - может всё не так
плохо и кто-нить знает как решить/обойти хоть некоторые из этих проблем.

- Многие комбинации кнопок передаются через Esc-последовательности.
  Из-за этого в терминале не работает одиночное нажатие Esc - он ждёт, не
  пойдёт ли следом Esc-последовательность. Решается в некоторых
  приложениях (пока видел только в mc) заданием таймаута на ожидание
  Esc-последовательности после одиночного Esc. Что криво уже хотя бы
  потому, что это требуется поддерживать индивидуально в приложениях -
  если бы этот таймаут настраивался в xterm, было бы немного адекватнее.

- Из-за Esc-последовательностей возникают некоторые проблемы. Например,
  комбинация Alt+1 в Vim видна как "<Esc>1". Соответственно, возникает
  конфликт с отдельными нажатиями Esc и 1. Типичный пример: для выхода из
  режима вставки и перехода в начало файла требуется нажать Esc и 1G.
  Но при наличии обработчика Alt+1 нажатие Esc и 1 вызывает этот
  обработчик. Решение - после нажатия Esc подождать секунду, а уже потом
  нажимать 1G - дико раздражает.

- Если Esc-последовательности отключить (включить XTerm*eightBitInput и
  выключить XTerm*metaSendsEscape), то в Vim всё становится хорошо:
  Alt+1 посылает "<A-1>", и больше не конфликтует с "<Esc>1".
  Но на самом деле Alt+что-то теперь посылает разные юникодные символы,
  поэтому ввод этих символов (даже через compose key) обрабатывается в Vim
  как нажатие Alt+что-то. И приходится конкретно эти символы вводить через
  Ctrl-V. Но всё это терпимо, и больше чем на пол беды не тянет.
  Настоящая беда в том, что в mc напрочь отрубаются все Alt-комбинации,
  и я не смог через mc.keymap вообще никак уговорить его реагировать на
  юникодные символы, посылаемые xterm-ом. Пришлось возвращать настройки
  xterm обратно и отказываться от использования Alt+1 в Vim.

- У меня не работают никакие комбинации начинающиеся на Ctrl+Shift, нигде -
  даже xkbwatch не видит Ctrl+Shift. Насколько я понимаю, это связано с
  тем, что у меня по Ctrl+Shift переключается язык ru/en, и Xkb просто
  "съедает" Ctrl+Shift лишая другие приложения возможности увидеть любые
  комбинации содержащие Ctrl+Shift.

- Более того, схожая проблема "съедания" кнопок наблюдается и в других
  случаях. Например, у меня в fluxbox настроено переключение на предыдущий
  рабочий стол по кнопке Win (a.k.a. Super_L a.k.a. Mod4). В результате,
  никакие комбинации Win+что-то ни в одном приложении больше не работают.
  Точнее, они работают, но уже после того, как сменится рабочий стол. :(
  Как я догадываюсь, это вызвано тем, что комбинация кнопок обрабатывается
  не в момент отпускания кнопки (как, вероятно, в винде), а в момент её
  нажатия. Если бы был способ переключить Xorg в режим обработки кнопок в
  момент отпускания, возможно удалось бы более точно определять нажатую
  комбинацию и исключить эти ложные срабатывания по первым кнопкам
  комбинации вроде Ctrl+Shift или Win.

Одним словом, всё это полная лажа. :( Линух 21 год назад родился как
эмулятор терминала, но до сих пор делает это паршиво.

-- 
			WBR, Alex.

Re: [gentoo-user-ru] linux hotkeys suxx

[Sergey Kobzar]

On 06/02/12 08:56, Alex Efros wrote:

> - У меня не работают никакие комбинации начинающиеся на Ctrl+Shift, нигде -
>    даже xkbwatch не видит Ctrl+Shift. Насколько я понимаю, это связано с
>    тем, что у меня по Ctrl+Shift переключается язык ru/en, и Xkb просто
>    "съедает" Ctrl+Shift лишая другие приложения возможности увидеть любые
>    комбинации содержащие Ctrl+Shift.

Пару раз натыкался на подобное с внешней клавиатурой (если проблему не 
решу - отпишусь сюда).


> - Более того, схожая проблема "съедания" кнопок наблюдается и в других
>    случаях. Например, у меня в fluxbox настроено переключение на предыдущий
>    рабочий стол по кнопке Win (a.k.a. Super_L a.k.a. Mod4). В результате,
>    никакие комбинации Win+что-то ни в одном приложении больше не работают.
>    Точнее, они работают, но уже после того, как сменится рабочий стол. :(
>    Как я догадываюсь, это вызвано тем, что комбинация кнопок обрабатывается
>    не в момент отпускания кнопки (как, вероятно, в винде), а в момент её
>    нажатия. Если бы был способ переключить Xorg в режим обработки кнопок в
>    момент отпускания, возможно удалось бы более точно определять нажатую
>    комбинацию и исключить эти ложные срабатывания по первым кнопкам
>    комбинации вроде Ctrl+Shift или Win.

У меня тоже fluxbox. Win+Fn - перенос активного окна на указанный 
workspace. Если запущен Stardict и выделенос слово, то при нажатии Win 
всплывает его перевод. Проблем не замечено ни там, ни там.


> Одним словом, всё это полная лажа. :( Линух 21 год назад родился как
> эмулятор терминала, но до сих пор делает это паршиво.

Re: [gentoo-user-ru] linux hotkeys suxx

[Голубев Александр]

02.06.2012, 09:56, "Alex Efros" <powerman@powerman.name>:
> Hi!
>
про иксы и раскладку:
проблема действительно старая... где-то в инете плавал патч на иксы, который делает переключение по отпусканию клавиши. Для себя решил это, как и многие, перейдя на капс-локк для rus/lat

про win для преключения рабочих столов:
ССЗБ

Re: [gentoo-user-ru] linux hotkeys suxx

[Голубев Александр]

по поводу патча смотри баг:
https://bugs.freedesktop.org/show_bug.cgi?id=865

Re: [gentoo-user-ru] linux hotkeys suxx

[Alex Efros]

Hi!

On Sat, Jun 02, 2012 at 11:53:38PM +0300, Sergey Kobzar wrote:
> У меня тоже fluxbox. Win+Fn - перенос активного окна на указанный 
> workspace. Если запущен Stardict и выделенос слово, то при нажатии Win 
> всплывает его перевод. Проблем не замечено ни там, ни там.

Насколько я понимаю как всё это работает, проблему скорее всего можно
заметить так: при запущеном Stardict выделить слово и нажать Win+Fn для
переноса активного окна. При этом должен всплыть перевод слова в качестве
нежелательного побочного эффекта (впрочем, если он всплывёт в предыдущем
workspace, то это можно не заметить).

-- 
			WBR, Alex.

Re: [gentoo-user-ru] linux hotkeys suxx

[Alex Efros]

Hi!

On Sun, Jun 03, 2012 at 03:22:31AM +0400, Голубев Александр wrote:
> про иксы и раскладку: проблема действительно старая... где-то в инете
> плавал патч на иксы, который делает переключение по отпусканию клавиши.

спасибо за ссылку на баг, читаю…

> Для себя решил это, как и многие, перейдя на капс-локк для rus/lat

Ну, проблема ведь несколько больше чем просто конфликт с xkb по одной
комбинации. Capslock у меня используется как compose key, для ввода
юникодной фигни - на что тогда вешать compose key?

> про win для преключения рабочих столов: ССЗБ

:) Ну, да, выглядит как типичный ССЗБ. Но дело в том, что обходить эти
недостатки путём выбора неудобных но зато работающих комбинаций кнопок -
знаете, это было нормально в 98-м, но в 2012 это уже сложно продолжать
считать нормой.

У меня 24 постоянных рабочих стола (по Alt+Fn плюс Alt+Shift+Fn), и мне
очень удобно использовать Win/Shift+Win для переключения на
следующий/предыдущий, и Menu для переключения между двумя последними.
Я использую это много лет, и мало того, что привык, так ещё и, честно
говоря, даже не представляю, куда можно их перевесить не потеряв в
удобстве использования. Но терять из-за этого все Win+что-то хоткеи тоже
очень жалко.

А по Alt-1/Alt-2 было очень удобно переключать табы предыдущий/следующий.
Посадила на это opera - в ней когда-то из коробки работали 1 и 2 для этой
цели. Потом они спохватились, что просто 1 и 2 это всё-таки хамство и
из-за этого возникает много проблем, и попытались от этого отказаться.
Но я просто заменил 1 и 2 на Alt-1 и Alt-2 и продолжил пользоваться
фактически не потеряв в удобстве.
Сейчас пытаюсь переучиться на Ctrl-PgUp/PgDn. Значительно менее удобно
(Alt-1/Alt-2 не требует убирать руку с мышки), но вроде бы это
относительно стандартная комбинация (из коробки работает в vim, pidgin и
firefox как минимум).

-- 
			WBR, Alex.

Re: [gentoo-user-ru] linux hotkeys suxx

[Alex Efros]

Hi!

On Sun, Jun 03, 2012 at 03:28:20AM +0400, Голубев Александр wrote:
> по поводу патча смотри баг:
> https://bugs.freedesktop.org/show_bug.cgi?id=865

Нда. Ну, что, конфликт с хоткеем переключения раскладки клавы они
пофиксили, но в целом проблема осталась - при нажатии Win обработчик
по-прежнему реагирует на нажатие, а не отпускание.


P.S. У нас это в https://bugs.gentoo.org/show_bug.cgi?id=379827

-- 
			WBR, Alex.