[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: про X-овую клавиатуру
>
> > Ну это я не понял. Можно еще кое-что "свалить на клиента", но зачем?
>
> 1. Уменьшится размер сервера.
И увеличится Xlib.
> 2. В сервер бинарные модули подгрузить -
> большая проблема, а в клиента - легко.
Если сервер не "железный", то - не вижу разницы.
> > Так что подправлять то?
> > Вместо нынешней схемы где
> > - сервер просто держит раскладку и "раздает" ее приложениям
> > - зависимость флажков-модификаторов от физических кнопок заложена
> > в сервере
> > - а состояние сообщается клиенту с каждой кнопкой.
> > Вы предлагаете
> > - таблицу приложениям грузить не с сервера, а из текстового файла
> > или - опять же с сервера только через properties root'ового окна
>
> тут разницы нет, но с сервера убирается целый блок работы с Keymapping'гом,
> и убирается часть X протокола.
Так а что именно убирается?
Сама таблица? Так вы же ее хотите оставить в properties root'а.
Кусочек, который ее выдает по запросу? Это "мелочевка".
Подпрограмму которая вычисляет Lock'и? Все равно вы их собираетесь запоминать,
чтобы отдать приложению по смене фокуса. А перевод нажатых клавиш в биты
состояния - в core опять же - "мелочевка". А в xkb посложнее, но
- из-за механизма гибкой настроки (он тогда переедет в Xlib со всем "парсером")
- он там еще кое-что делает, Mouse Keys например.
> > - зависимость модификаторов от клавиш вычислять в каждом приложении
> > (а если они это будут делать по разному? Кошмар!!!)
>
> Xlib?
Ну хорошо, в Xlib. А как?
Жестко зашить? Неинтересно.
Сделать настраиваемый из текстовых конфигов?
Утяжелится Xlib. Конечно, shared библиотеки это как-то скомпенсируют, но
- а "статически слинковываные" бинарники? Каждый в себе будет иметь "парсер".
- гибкая настрока потребует адекватных структур данных (динамических),
то есть некоторую таблицу будет держать в себе каждое приложение.
Рассовать в "подгружаемые модули"? Ну это куда не шло, но тоже - данные
у каждого свои. Да и сколько потребуется таких модулей "на все случаи жизни"?
Писать их каждый юзер не будет.
Ну и если речь идет о разнесении клиента и сервера.
Если и клиенты и сервер на одной машине (по-моему, это все-таки самая
распространенная ситуация), то вообще говорить не о чем. Убираем из одной
программы (X server) и тиражируем во все клиенты.
А если сервер и клиент - разные машины, то и клиенты скорее всего -
с разных машин. А кто будет обеспечивать единообразие настроек (или версий
Xlib, или конкретных подгружаемых модулей)?
Опять возможен тот же кошмар.
> > - состояние клавиатуры (если клиент не сам его вычисляет) пусть каждый
> > раз запрашивает с сервера. (Зачем? Ему сейчас его и так докладывают.)
>
> Каждый раз не надо, конечно. При загрузке приложения делается
> XQueryKeymap, затем отслеживаются нажатия/отпускания клавиш; при
> смене фокуса карта нажатых клавиш передается клиенту автоматически.
А что значит - карта? Это и получится то же состояние. Серверу все-равно
надо соображать, что lock'ирующася клавиша даже когда отпущена, все-равно -
нажата. :-)
То есть - что получается. Сервер должен не только знать - какая клавиша
в данный момент нажата, но и
- по всем клавишам - lock'ирующаяся она или нет.
(Ему это жестко зашить? Или сделать настраиваемым?)
- если да, то отслеживать - сколько раз ее нажимали/отпускали.
И что тогда можно из него выкинуть?
Кстати, а как менять раскладку "на лету"? Или уже не надо?
> > Ну и чем это лучше? :-)
>
> Логика переключения состояния клавиатуры переносится в клиента, что позволяет
> 1. облегчить сервер
И и настолько же утяжелить _все_ клиенты.
> 2. большую гибкость за счет подгружаемых модулей.
Если модули у всех клиентов разные - это кошмар.
Если один и тот же - ну так пусть он в сервере сидит (подгружаемый).
--
Ivan U. Pascal | e-mail: pascal@tsu.ru
Administrator of | Tomsk State University
University Network | Tomsk, Russia