Re: KSI Linux

[AEN <aen@logic.ru>]

Ivan Pascal wrote:

>   Во-первых, я хотел попросить хозяина не гнать нас отсюда.
> Эта тема, хотя и косвенно, имеет отношение, если не к locale,
> то к "локализации" в широком смысле.

Спасибо Хозяину за гостеприимство.  Лично мне здесь очень хорошо :-)

>
>
> > >   А все ли toolkit'ы используют Xlib? Или кто-то сам переводит Cyrillic
> > > в подходящие коды?
> >
> > Именно так, я об этом писал в этот лист. Qt 2.0 делает это сам, так как хочет
>
>   Извините мою дремучесть. А что такое - Qt 2.0?
> Насколько я понял, последняя "фри" Qt - 1.42 (ну, может быть - 1.44).

Qt 2.0 - та, что будет Open Source - доступна через CVS. Она имеет статус беты.
Можно получить доступ к CVS, написав письмо, а можно зайти на ftp.troll.no и
выкачать достаточно свежий snapshot.
Интересна именно  Qt 2.0, так как ее можно будет модифицировать и, в частности,
добавить кодировки. Qt < 2.0 я не изучал, так что сказать ничего не могу.

>
>
>   И вот разглядывая 1.42, я обнаружил, что...
>
> > работать аж с X11R4. Он определяет charset по _имени_ переменной LANG. Если
> > кодировка в ней указана, то смотрит на LC_CTYPE. Если не указана и там, то
> > смотрит в свои таблицы, содранные с locale.alias. То есть locale.alias зашит в
> > коды Qt.
>
>   Она пытается "вытащить" charset из LANG, если он имеет вид
> lang.charset
>   Если в LANG нет точки, то, действительно, по своим таблицам ищет подходящий
> lang и подставляет свой encoding (для всяких ru, ru_RU, russian - это
> iso8859-5).
> (О LC_CTYPE я там упоминания не нашел.)

Недавно появилась в CVS .

>
>
>   НО! Все это делается для выбора "фонтов".
> На перекодировку вводимых символов из Cyrillic это влиять не должно.

См. Qt2.0, src/tools/qtextcodec.c и далее по ссылкам

>
>
>   Ввод она "пропускает" через Xlib.
> (Так что мой вопрос пока остается открытым - Есть ли такие toolkit'ы,
> которые не используют Xlib на вводе?)
>
>   Что касается "ввода через Xlib"...
>   Для перевода keysym в ascii есть две функции (две ли?)
> XLookupString и
> XmbLookupString (mb - это multi byte)
>
>   Так вот. Первая более "традиционная". Вторая использует "input context".
>   Причем, обе используют разные таблицы (таблицы, конечно, идентичные,
> но физически - это два разных массива) и разные методы определения charset.
>
>   Если приложение пользуется XLookupString (а таких все меньше),

именно

> то
> charset берется либо из "переменной среды" _XKB_CHARSET (я проверял,
> действительно - работает), либо из locale - encoding_name.
>   Чтобы работал второй способ (когда _XKB_CHARSET не определена),
> должна отработать "иксовая" setlocale (именно "иксовая", она описана
> в Xlocale.h).

Да!

>
>
>   А вот если приложение использует XmbLookupString (а именно ее норовят
> вставлять сейчас в приложения), то название charset'а ищется как-то
> по-другому. Похоже, что из той же loacle:encoding_name, но я не уверен.
>   Кроме того, для правильной работы XmbLookup* обычно вызывают не setlocale,
> а XSetLocaleModifiers. Чем это отличается от setlocale - я сейчас и пытаюсь
> понять.
>
>   Кстати, если вернуться к Qt (1.42), то она при инициализации приложения
> вызывает и setlocale, и XSetLocaleModifiers.
>   А для обработки ввода использует XLookup*, если "иксы" старее, чем 5,
> или если почему-либо "input context" не определен.
>   Если этот context определен (что и должно быть в нормальной ситуации),
> то используется XmbLookup*.

Все правильно, но я то собственно о добавлении новых кодировок. Вот добавил 1251.
Почти все работает (все, кроме xterm, разбираться с ним пока недосуг). А стоило ли
это делать? Меня сподвигла на это не только история с надругательством :-) над
KOI8-R, но и постоянный плач восточноевропейцев из mailing-list SuSE (закрытого, к
сожалению) о необходимости 1250. Мнения?

>
>
> --

Rgrds, AEN.