Зачем он нужен этот XKB?

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

  Ладно. Попробую немного рассказать о "достоинствах" XKB.
Только сразу договоримся, что
- к cyrillic символам это отношения не имеет
- формат файлов сравнивать не будем
- можно говорить не о "достоинствах", а о "функциях" или "фичах" XKB.
А вот являются они "достоинствами" или нет - вопрос другой.

  Да. И сравнивать надо core protocol и xkb.
Давайте xmodmap сюда не приплетать.

  Итак первое и главное отличие - форма таблицы символов.
В core имеется "плоская" таблица, где к каждому скан-коду (keycode)
привязан вектор символов (keysym) длиной до 255.
  ТО есть - не так уж мало :-), но ...
Стандартными средствами указать - какой из символов нам нужен сейчас
можно только первые четыре. Mode_switch выбирает одну из пар колонок,
а Shift - колонку внутри пары.
  Обратите внимание, что -
Shift и только Shift - на другой модификатор возложить эту функцию нельзя.
А что касается Mode_Switch, тут все еще круче.
  Сама по себе клавиша Mode_switch ничего не меняет. С ней должен быть связан
какой-то из "безымянных" модификаторов (Mod1-Mod5). При старте приложение
"выспрашивает" у сервера - какой модификатор привязан к Mode_switch, и этот
модификатор потом использует для выбора "группы".
  Поскольку модификатор можно привязать только к скан-коду, то и группа
будет переключаться при нажатии этой клавиши независимо от остальных
модификаторов. То есть подвесить это действие на "два shift'а" не получится.
(Однако - верх простоты и логичности :-)

  В xkb - все символы, привязанные к keycode делятся на группы, которые
в свою очередь делятся на level'ы.
Групп может быть всего четыре, но если оставить наши "заморочки" с "семью
русскими языками" и использовать их именно для разных алфавитов, то этого
не так уж мало (можно слелать одновременно латиницу, кириллицу, греческий,
а последнюю группу поделить между еврейским и арабским, благо у них нет
деления на большие/маленькие :-)
  Level'ов может быть до 64.
Причем -
- номер группы явно передается приложению в виде двубиного поля
(и нет необходимости извращаться с косвенным указанием через mode_switch)
- номер level'а может зависить от любой комбинации модификаторов (а не только
Shift).
  Причем привязка level'а к комбинации модификаторов сделана максимально
гибко - функция, отображающая модификаторы в level задается отдельно как
именованны "тип клавиши". А уже этот тип и указывается в описании клавиши.
То есть - разные клавиши могут по-разному менять свои символы в зависимости
от модификаторов. И даже больше - тип может быть свой в каждой группе.
То есть группа - это не просто алфавит, а вообще - другая клавиатура

  Итак. Если клиентская строна поддерживает xkb, то мы можем безо всяких
надстроек задействовать все 4x64 возможных значений клавиши, а не
"два по два" как в core protocol. И не ограничены в назначениях
переключателей на любые комбинации (L_Alt+R_Alt+L_Shift+Esc :-)

  Что же касается того, что xrus может примерно то же самое...
поскольку в core protocol мы все-равно ограничены раскладкой "два по два",
xrus (и ему подобные) просто на каждое переключение "заливают" в сервер
новую раскладку. Причем учтите, что раскладка клавиатуры как в xkb, так и
в core зачитывается из сервера в приложение и хранится (и интерпретируется)
там. Так что, после того как xrus залил новую раскладку в сервер, сервер
должен всем приложения послать event о том, что раскладка сменилась и теперь
уже каждое приложение должно закачать новую раскладку себе (то, что xrus
теперь запоминает раскладку для каждого окна, только усугубляет ситуацию -
теперь раскладка может "перезакачиваться" не только по нажатию переключателя,
но и по каждому изменению фокуса).
  Вот вам и расход bandwith. Но кого он сейчас волнует?

  Что касается xkb - если сразу составить одну раскладку со всеми нужными
символами, то ничего гонять к серверу и обратно не придется.
  Сервер сам по нажатию нужной комбинации поменяет поле "группа" и комбинацию
модификаторов, и будет сообщать их приложению. А приложение по ним само
вычислит нужный символ.
  Естественно, недостаток в том, что xkb раскладка (да еще и с функциями
"тип клавиши") занимает больше места в памяти приложения. Но зачитывается
один раз.
  Так что в данном вопросе xkb vs. core это - дополнительный расход памяти
vs. дополнительный расход bandwith.

  Кстати, что касается форматов файлов.
Как в xmodmap сказать, что данная клавиша должна быть "залипающей" или
без автоповтора (вопрос - зачем, пока оставим)?
  Ну с "залипанием" еще как-то можно, хотя и опять же через anus причем
недокументированый.
  А вот с автоповтором - никак. Хотя core protocol (если не ошибаюся)
позволяет это делать, но - "примочками".
  А в конфиге xkb я могу просто просто написать lock=yes или repeat=no
для любой клавиши. (Или это сложнее, чем в xmodmap? :-)

  Ну а теперь решим - достоинство ли это?
Наверное - нет. Памяти жрет много. Конфиг сложный (это же еще надо умудрится
представить себе - четыре клавиатуры в одном флаконе, да еще в каждой больше
двух символов на клавишу).
  Обычному юзеру "два по два" привычнее (да и надо ли что-то еще?).
А когда этих "два по два" не хватает, то можно их наплодить сколько хочешь
(опять же в каждой надо уметь считать только до четырех :-), а специальная
"примочка" будет их заливать в сервер, который бастренько разольет по
всем приложениям. Ну а дополнительный расход канала, как я уже сказал,
все равно никто не заметит.

   Продолжение следует...

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