[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Зачем он нужен этот XKB? -II
Продолжаю.
Естественно в xkb есть механизм позволяющий по нужным клавишам
менять модификаторы и номер группы - так называемые actions.
Эти actions выполняются на сервере и никаких примочек не требуют.
Причем заметьте - они навешиваются на символы, а не скан-коды, поэтому
одна и та же клавиша может взводить разные модификаторы или выставлять
номер группы в зависимости от того - "с чем ее нажали" (Shift, Control и т.п.)
В core такого просто нет, поэто сравнивать не с чем.
А в xkb это позволяет по крайней мере без внешних примочек конструировать
переключатели из нескольких клавиш.
А вот дальше - можно только матерится.
Механизм это крив до безобразия. Я так и не понял - из каких соображений
автор исходил.
Внутренних модификаторов может быть до 32, но они не будут работать даже
внутри сервера, если их не связать с одним из восьми "традиционных"
модификаторов. Тогда что толку, что их 32.
Под запоминание номера группы и набора модификаторов отводится по три
внутренних (внутри сервера) переменных. Но у каждой свое поведение и
мало того, что они меняются разными actions (это то нормально), но и
в рамках action нельзя из одной переменной просто переписать в другую.
Вместо этого они зачем-то суммируются.
На один символ нельзя навесить несколько actions, а действие каждого
сильно ограничено.
В общем - получился какой-то странный "виртуальный микропроцессор"
с ограниченным набором команд, без подпрограмм и с регистрами весьма
специфического назначения. При этом клавиша (символ) может выполнить
только одну команду.
Но несмотря на свою ублюдочность этот механизм позволяет хоть что-то
сконструировать (переключатель L_Shift+R_Shift). Core вообще этого не может.
Достоинство?
Сомнительное. Все-равно язык C богаче. И на нем можно написать все что
надо, оформить это "примочкой" и запустить поверх core protocol'а.
Правда "примочке" придется "грабить" с сервера все нужные клавиши, зато
сервер полегчает на программу обработки actions.
(Я не говорю о том, что писать на C саму "примочку" не проще чем сочинить
переключалку в терминах actions. Все-равно и то и другое пишутся отдельными
"спецами" а потом юзаются всеми.)
Дальше. Индикаторы.
XKB может сам (без примочек) упрвлять индикаторами. Как физическими LED'ам,
так и внутренними "виртуальными", которые можно отбразить простенькой
программкой.
ПРичем, управление опять же сделано максимально гибко - LED может зависеть
от чег угодно - номера группы, модификаторов и их комбинации.
Кроме того, можно делать "обратную связь" - даешь серверу команду
"включи мне такой-то LED", а он заодно и модификатор "поднимает".
В core это вообще нет.
Достоинство?
Кому как. LED'ы уже никого не удовлетворяют (хотя в консоли обычно ими
как-то обходятся). Если уж есть графическая оболочка, хочется видеть
красивую "лампочку Ильича" в самом видном месте экрана.
А для этого все-равно нужна "примочка". (Не хотите же вы, чтобы авторы
сервера сам решали - какю лампочку вам рисовать - Ильича или Эдисона
и в каком углу экрана).
Дальше идет совсем "мелочевка" (которая в core напроч отсутствует)
Радиогруппы из кнопок. Хотя в GUI радиогруппы часто используются,
никто не привык, что так могут вести себя и кнопки на клавиатуре.
К тому же он физически не будут залипать/олипать, значит - не наглядно.
Да и кнопок лишних на клавиатуре нет.
Перекрытия (overlay). Можно на одну группу клавиш навешать несколько
разных скан-кодов. Говорят, что это для "лаптопов", где отсутствует, например
"дополнительная цифровая клавиатура".
Кому это надо? Особенно если мы сидим на "десктопах", а не "лаптопах".
Да и keypad в большинстве случев - вещь не такая без которой не обойтись
(тем более если чтобы его получить надо что-то там переключать и не забыть -
в каком режиме у меня сейчас клавиатура).
Mouse Keys. Север может по нажатию клавиш эмулировать события мыши.
Как movement, так и "клики". Причем movement может быть как равномерный,
так и ускоряющийся.
Ну и - зачем?
Если не ошибаюся, то же самое умеют делать некоторые WM.
Да и нафиг нужна такая "мыша", если для ее "таскания" все-равно нужна
клавиатура.
AccessX. Средство для людей "с ограниченными физическими возможностяим".
Имеются ввиду инвалиды, у которых или "пальцы плохо слушаются" или вообще
протез вместо руки.
Главная проблма в этом случае - нажимать несколько кнопок одновременно.
Ну и еще то, что они при нажимании могут задевать "не те клавиши" или
создавать "дребезг" клавиши.
Для них предусмотрена сложная система "таймаутов" и звуковой индикации,
которая помогает преодолеть эти проблемы. (Подробнее рассказывать мне лень,
но если кого интересует - могу.)
Ну и опять же - зачем?
Нет, конечно такие люди есть и пользуются этими "фичами" (по крайней
мере кого-то, кто очень этим интересовался, я консультировал).
Но всем остальным - зачем лишний кусок в сервере. Пусть это делает отдельная
"надстройка" (Unix way).
Ну о bell-event'ах как-то даже неприлично гворить.
Все равно в этой части xkb только посредник. Опять - сплошные надстройки
без корых эта "фича" - ничто. (А память в сервере отедает).
Ну и есть еще куча "мелочных" controls, которые меняют поведение как самого
сервера, так и клиентсткой части.
Но некоторые из них вообще не работают (значит - до сих пор никому не
понадобились). А те, что работают нигде не используются.
Вот такие дела.
Я честно говоря, когда писал "документацию по XKB" надеялся, что теперь
то кто-нибудь начнет помаленьку задействовать "фишки" xkb.
(Учтите, что на английском подобной документации просто нет. Так что у
русскоязычных некоторое приемущество).
Но...
Большинство ищет короткие ответы - "где че сказать чтобы заработало".
Кто что-то сделал, делают это "под себя" и не спешат делиться
(Алексей Новодворский - исключение).
А главное - все поняли, что это "очень сложно". Да и фантазия редко
когда выходит за рамки "куча раскладок 2x2".
Опять же xruskb уже написан (хотя и чуть позже чем xkb).
--
Ivan U. Pascal | e-mail: pascal@tsu.ru
Administrator of | Tomsk State University
University Network | Tomsk, Russia