Re: про X-овую клавиатуру

[Ivan Pascal <pascal@info.tsu.ru>]

> Прочитал я дискуссию по поводу XKB vs. xmodmap, и решил внести свою
> лепту :)  Все изложенное ниже есть теоретические измышления.
> 
> Вопрос: что именно (минимум) требуется от X сервера для
> локализации клавиатуры? Нужны ли вообще XKB и modmap?
> 
> Вот моя версия: от сервера не нужно почти ничего. На сервере должна
> храниться информация о том, в каком режиме находится клавиатура. В
> режим входит CapsLock, текущий язык и т.п. Все остальное может быть
> сделано на клиенте (в Xlib'е), в том числе изменение режима клавиатуры
> (и CapsLock'a тоже). Нажатие отдельных клавиш уже хранится на сервере
> и может быть получено клиентами (XQueryKeymap), автоповтор также уже
> контролируется core-протоколом (XChangeFeedbackControl), лампочки
> клавиатуры тоже могут меняться клиентами (XChangeKeyboardControl).

  А вот как сейчас сделано :-)
- на сервере хранится информация о том, в каком режиме находится клавиатура
- В режим входит состояние (нажат/отжат) CapsLock, Shift, Control и т.п.
и "текущий язык" - номер группы (которую надо выбрать в раскладке)
- все остальное сделано на клиенте (в Xlib'e). В смысле - какой символ
надо сопоставить keycod'у в зависимости от CapsLock, Shift, etc. и
"текущего языка"
- Таблица (не "нажатие клавиш") для всех этих переводов хранится на сервере
и может быть получена приложением (XQueryKeymap), а "нажатие клавиши" (keycode)
вместе с состоянием (state, куда входят все эти CapsLock/Shift/"текущий язык")
передается приложению в XKeyEvent по мере появления этих "нажатий".
  Дальше как я сказал - все делает приложение.
(Кстати управление автоповтором на PC'шках работает только в 4.0.1 :-)

> modmap или прочие таблицы могут храниться и у клиента, хотя они будут
> зависимы от конкретных keycode'ов и могут различаться у разных
> клиентов.

  Modmap хранится у клиентов и там же и интерпретируется. Вот только -
откуда она берется? Приложение при старте выспрашивает ее у сервера
с помощью XQueryKeymap. Ну еще сервер при изменении у него keymap
рассылает приложениям ChangeKeyboardMappingNotify и приложения, если
"не дураки" снова перезапрашивают у него "modmap или прочие таблицы"
   Теоретически, приложению можно подсунуть специфическую для него
таблицу, а не ту, что на сервере. Но стандартных функций для этого нет.
Хотя написать - не проблема. Проблема только в том, что надо будет в
Xlib встраивать "парсер" для зачитки таблиц из текстового файла.
 
> Состояние клавиатуры может храниться на уровне Properties root'ового
> окна. В принципе туда же можно запихнуть таблицы KeySym'ов, если нужно.

  Состояние и так хранится в сервере в виде 16-битной переменной и
как я уже сказал сообщается приложению вместе со скан-кодом при каждом
нажатии кнопки. Какая разница будет это переменная сервера или "свойство
root'ового окна"? К Property надо будет еще и какое-то имя и приложение
должно будет его запрашивать по каждому получению keycode.

> Почему состояние должно храниться на сервере: оно должно быть
> одинаково для всех клиентов (хотя это спорно, некоторые хотят, чтобы в
> каждом приложении был свой режим клавиатуры - это тоже может быть
> легко решено на клиентской стороне).

  Вот это действительно было бы не плохо, особенно с "текущим языком".
(Собственно ради этого и была написана xxkb). Но тогда приложение
должно и само отрабатывать нажатие клавиш CapsLock/Shift/Control и т.п.
Не говоря уж о комбинациях типа L_Shift+R_Shift.
  В общем случае получится не такая уж простая программа.
Ну и что дальше? "Зашить" ее в Xlib? Или в каждом приложении писать свою?

> Что есть сейчас: режим клавиатуры меняется на сервере, таблицы
> хранятся на сервере, Lock-клавиши обрабатываются на сервере. Состояние
> и таблицы скачиваются Xlib'ом для трансляции keycode'ов.

  Не совсем так.
Что есть сейчас -
- режим клавиатуры меняется на сервере (но сообщается приложению с каждым
keycode)
- таблицы хранятся на сервере, но только для того, чтобы приложение знало -
откуда их взять. Интепретируются они в клиенте.
- Lock-клавиши? Их состояние хранится на сервере и там же они "вычисляются",
но ... какой символ должен получиться в зависимости от того нажата эта
Lock или не нажата - решает клиент.
- таблицы скачиваются, а состояние "само приходит" с каждым нажатием.

> Таким образом, имеющееся _серверное_ решение не минимально.

  Ну это я не понял. Можно еще кое-что "свалить на клиента", но зачем?
  Единственное, что еще можно отдать клиенту - "язык".
А представьте себе, если каждое приложение начнет само решать - какая
клавиша типа CapsLock, Shift, L_Win, Menu и т.п. - как меняет состояние.
  В одном приложении CapsLock работает как CapsLock, в другом - переключает
"язык". В одном приложении правый Shift - Shift, в другом - Meta.
Ну и так далее.
  Сами же взвоете и захотите "однообразия".
Так вот оно уже есть. :-)

> Второй вопрос - как лучше реализовать трансляцию keycode'ов в текст
> и команды внутри Xlib'a. Но это уже никак не относится к X серверу.

  Ну и как-то же делается сейчас :-)

> На мой взгляд, loadable module вполне подходит на роль транслятора
> keycode'ов, язык C богаче всяких скриптов :)

  Вот это масль хорошая. И кстати, такая возможность, по крайней мере
для всех "локалезавсимых" функций Xlib уже сейчас есть.
  Только никто ей не пользуется.
 
> Заключение: теоретически можно обойтись без XKB и без modmap, нужно
> только выкинуть все лишнее из X сервера и подправить Xlib. :)

  Так что подправлять то?
Вместо нынешней схемы где
- сервер просто держит раскладку и "раздает" ее приложениям
- зависимость флажков-модификаторов от физических кнопок заложена
в сервере
- а состояние сообщается клиенту с каждой кнопкой.
  Вы предлагаете
- таблицу приложениям грузить не с сервера, а из текстового файла
или - опять же с сервера только через properties root'ового окна
- зависимость модификаторов от клавиш вычислять в каждом приложении
(а если они это будут делать по разному? Кошмар!!!)
- состояние клавиатуры (если клиент не сам его вычисляет) пусть каждый
раз запрашивает с сервера. (Зачем? Ему сейчас его и так докладывают.)

  Ну и чем это лучше? :-)

-- 
 Ivan U. Pascal         |   e-mail: pascal@tsu.ru
   Administrator of     |   Tomsk State University
     University Network |       Tomsk, Russia