Re: Fw: X11 keysym to Unicode mapping

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

> From: Ivan Pascal <pascal@info.tsu.ru>
> >  Вот это - очень мило. Вместо того, чтобы "добить" Xlib (а там utf8
> > с таблицами уже есть), будут добавлять "hardwired" поддержку в отдельные
> > приложения.
> 
> 
>  Я кстати заинтересовался этой таблицей и решил ее поискать.
  Я, кстати, говорил о той, что "зашита" в Xlib :-)

>  Поскольку Qt 2.0 от Troll Tech многоплатформенная (X11/Win32)
> вся внутренняя обработка текста у нее происходит в UNICODE.
> Под это дело у них сделан специальный класс QString -
> UNICODE-овая строка. Сверху все красиво. Поэтому было
> весьма интересно посмотреть, как оно там взаимодействует с X11.
  Точно. Внутри она все старается хранить в UNICODE.

>  Вот, выкачал ftp://ftp.troll.no/qt/snapshots/qt-2.00beta-DATE.tar.gz
> Смотрю, и постепенно прихожу в ужас. Таблицы я не нашел.
> Может я неправ, кто копал Qt 2.0, покажите место.
  Вытащу - покажу :).
(Тот "снапшот", что был у меня  я выкинул. Но, кажется, я там находил.)

>  Поэтому Qt совершенно через через зад пытается
> определить текущий Charset : разбором имени locale
> вручную, всякими загадочными эвристиками и т.д.

  Вот тут есть один интересный момент (я об этом писал Алексею Новодворскому).

  Дело в том, что Xlib "не хочет делиться" информацией о своей locale.
Она ведь, по setlocale находит нужный файл (через свои locale.dir,
locale.alias), "парсит" его и запоминает все, что там есть в своих
"структурках".
  Все функции ввода/вывода текста (символов) активно пользуются этими
данными. Но...
  Из приложения никакими стандартными вызовами "добыть" эти сведения нельзя
(и сами структурки и функции, работающие с ними - "приватные").
  Есть несколько "ублюдочных" вызовов типа - "дай locale input метода",
"дай locale output метода" и т.п. Но они возвращают просто то же значение,
что Xlib вначале получила от setlocale.
  А вот в какой файл XLC_LOCALE она его превратила и, тем более - какие
там значения установлены - узнать нельзя !
(Теоретически, я могу не только locale.alias подправить, а вообще свой
XLC_LOCALE сочинить с нужными параметрами. Xlib то будет работать в
соответствии с ним, а вот приложения...)

  Вот и приходится "тулкитам" (если они хотят узнать что-то типа
encoding_name) или проходить весь путь самостоятельно (читать locale.dir,
locale.alias, сопоставлять, находить файл, "парсить" его)
или "городить" что-то свое. Что и сделано в Qt.

  Самое интересное в том, что куча функций, дающих нужную информацию,
в Xlib есть. Пример тому - моя testXlc (но, как не трудно заметить,
она использует пару "приватных" "хидеров" из Xlib).
  Надо только сделать их "публичными" (или добавить "враперы" к ним).

  А вот кто это может решить?
 
>  И это практически при том, что есть готовое 16-bit
> значение XKB, которое преобразуется в UNICODE
> как 1:1 .
  Угу. И процедура преобразования в Xlib есть. Но, опять же - приватная.
А вот как заставить "публичные" (типа X[mb|wc|]LookupString) вызвать
именно ее (и потом еще не "испаганить" ее выдачу) - я так и не понял.

P.S. Александр. Я тебе отправлял письмо с просьбой о помощи.
Ты его читал? Или как?
(Я спрашивал - может ли команда locale и процедурка setlocale показывать
разные значения? И если да, то - почему?)
-- 
 Ivan U. Pascal         |   e-mail: pascal@tsu.ru
   Administrator of     |   Tomsk State University
     University Network |       Tomsk, Russia