[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