[sisyphus] I gtk+-1.2.9

[sisyphus] I gtk+-1.2.9

[Aleksey Novodvorsky]

Господа, новая версия gtk+ страдает серьезными глюками. Я буду признаетелен за сообщения об их проявлениях.
Чиню.
Rgrds, AEN

Re: [sisyphus] I gtk+-1.2.9

[Vlad Harchev]

On Sat, 3 Mar 2001, Aleksey Novodvorsky wrote:

> Господа, новая версия gtk+ страдает серьезными глюками. Я буду признаетелен за сообщения об их проявлениях.
> Чиню.

 А что за глюки, можно поподробнее? Наверно с вводом русского в GtkEntry? 

 Best regards,
  -Vlad

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Vlad Harchev]

On Sat, 3 Mar 2001, Aleksey Novodvorsky wrote:

> Vlad Harchev wrote:
> 
> > On Sat, 3 Mar 2001, Aleksey Novodvorsky wrote:
> >
> > > Господа, новая версия gtk+ страдает серьезными глюками. Я буду признаетелен за сообщения об их проявлениях.
> > > Чиню.
> >
> >  А что за глюки, можно поподробнее? Наверно с вводом русского в GtkEntry?
> 
> Глюки в gdk.

> Первая глюка -- функция sanitize_ctext из gdkselection.  Она, судя по
> тексту, правильно работает со стандартными charsets (iso), но ее авторы не
> прочитали про нестандартные, а потому в заголовках окон появляются %xkoi8.  
> Смысл этого sanitize_ctext состоит, насколько я понимаю, в обеспечении
> независимости от X. Вторая -- пока мне непонятная. Она проявляется,
> например, в Sylpheed, он падает при перемещении курсора по русскому
> тексту. Связано это с выводом симоволов, с новой функцией
> _gdk_font_wc_to_glyphs (gdkfont.c). Здесь я пока не разобрался, просто
> откатился назад.

 Вторая - навеяна частично моими усилиями :)

 http://bugzilla.gnome.org/show_bug.cgi?id=50834

 Наверно это sylpheed виноват.. У меня все остальное с таким gdk (вернее с
тем, который указан в bugzilla и слегка пропатченной на предмет malloc lists
corruption) и gtk-1.2.8 (тоже пропатченном как указано мной в bugzilla page) 
работает прекрасно (правда я убил /etc/gtk/gtkrc.ru).

 Но вы откройте новый bugzilla ticket про первую ошибку - чтобы 1.2.10 вообще
вышел (а то хотят 1.2.9 сделать последним в ветке 1.2).

 Best regards,
  -Vlad

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Aleksey Novodvorsky]

Vlad Harchev wrote:

> On Sat, 3 Mar 2001, Aleksey Novodvorsky wrote:
>
> > Господа, новая версия gtk+ страдает серьезными глюками. Я буду признаетелен за сообщения об их проявлениях.
> > Чиню.
>
>  А что за глюки, можно поподробнее? Наверно с вводом русского в GtkEntry?

Глюки в gdk.
Первая глюка -- функция sanitize_ctext из gdkselection.   Она, судя по тексту, правильно работает со
стандартными charsets (iso), но ее авторы не прочитали про нестандартные, а потому в заголовках окон появляются
%koi8.  Смысл этого sanitize_ctext состоит, насколько я понимаю, в обеспечении независимости от X.
Вторая -- пока мне непонятная. Она проявляется, например, в Sylpheed, он падает при перемещении курсора по
русскому тексту. Связано это с выводом симоволов, с новой функцией  _gdk_font_wc_to_glyphs (gdkfont.c). Здесь я
пока не разобрался, просто откатился назад.
gtk-1.2.9-ipl3mdk сегодня выложу, но полной ясности пока нет, хотя все работает.


Rgrds, AEN

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Aleksey Novodvorsky]

Hi!
Vlad Harchev wrote:

>
> > тексту. Связано это с выводом симоволов, с новой функцией
> > _gdk_font_wc_to_glyphs (gdkfont.c). Здесь я пока не разобрался, просто
> > откатился назад.
>
>  Вторая - навеяна частично моими усилиями :)
>
>  http://bugzilla.gnome.org/show_bug.cgi?id=50834

Любопытно, спасибо.
Замечу, что бага с неправильным определением ширины символов проявлялась и в присутствии gtkrc.*, если в нем был
указан любимый шрифт друга Пабло "*-r-*". Надо посмотреть текст на предмет обработки этого зверя, который сейчас
пошел гулять по куче приложений.

>
>
>  Наверно это sylpheed виноват..

Возможно. Разобраться в этом действительно необходимо, так как он может быть не одинок.


> У меня все остальное с таким gdk (вернее с
> тем, который указан в bugzilla и слегка пропатченной на предмет malloc lists
> corruption) и gtk-1.2.8 (тоже пропатченном как указано мной в bugzilla page)
> работает прекрасно (правда я убил /etc/gtk/gtkrc.ru).
>
>  Но вы откройте новый bugzilla ticket про первую ошибку - чтобы 1.2.10 вообще
> вышел (а то хотят 1.2.9 сделать последним в ветке 1.2).

Нет, здесь надо по делу писать правильный sanitize_ctext, вооружившись инструкциями Ивана Паскаля. Беда
разработчиков gtk в том, что описание всех этих esc-последовательностей есть только на русском :-)

Rgrds, AEN

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Vlad Harchev]

On Sat, 3 Mar 2001, Aleksey Novodvorsky wrote:

 Hi, 

> Vlad Harchev wrote:
> 
> > On Sat, 3 Mar 2001, Aleksey Novodvorsky wrote:
> >
> > > Господа, новая версия gtk+ страдает серьезными глюками. Я буду признаетелен за сообщения об их проявлениях.
> > > Чиню.
> >
> >  А что за глюки, можно поподробнее? Наверно с вводом русского в GtkEntry?
> 
> Глюки в gdk.

> Первая глюка -- функция sanitize_ctext из gdkselection.  Она, судя по
> тексту, правильно работает со стандартными charsets (iso), но ее авторы не
> прочитали про нестандартные, а потому в заголовках окон появляются %koi8.  
> Смысл этого sanitize_ctext состоит, насколько я понимаю, в обеспечении
> независимости от X.

 А вот первая глюка проявляется только на XFree-4.x? Просто люди, пробовавшие
этот новый gtk говорят что в XFree-3.x все с заголовками окон нормально.

 Ну и некоторые говорят, что stuphead работает и не валится при перемещении по
тексту с новым gtk.

[...]

 Best regards,
  -Vlad

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[rider]

Vlad Harchev wrote:

> On Sat, 3 Mar 2001, Aleksey Novodvorsky wrote:
>
>  Hi,
>
> > Vlad Harchev wrote:
> >
> > > On Sat, 3 Mar 2001, Aleksey Novodvorsky wrote:
> > >
> > > > Господа, новая версия gtk+ страдает серьезными глюками. Я буду признаетелен за сообщения об их проявлениях.
> > > > Чиню.
> > >
> > >  А что за глюки, можно поподробнее? Наверно с вводом русского в GtkEntry?
> >
> > Глюки в gdk.
>
> > Первая глюка -- функция sanitize_ctext из gdkselection.  Она, судя по
> > тексту, правильно работает со стандартными charsets (iso), но ее авторы не
> > прочитали про нестандартные, а потому в заголовках окон появляются %koi8.
> > Смысл этого sanitize_ctext состоит, насколько я понимаю, в обеспечении
> > независимости от X.
>
>  А вот первая глюка проявляется только на XFree-4.x? Просто люди, пробовавшие
> этот новый gtk говорят что в XFree-3.x все с заголовками окон нормально.
>
>  Ну и некоторые говорят, что stuphead работает и не валится при перемещении по
> тексту с новым gtk.
>

Проявляется на XFree4 - потому, что там все сделано правильно.

Патч уже есть в Sisyphus.

Rgds
Anton

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Sergey Vlasov]

On Sun, 11 Mar 2001 17:06:21 +0400 (SAMT)
Vlad Harchev <hvv@hippo.ru> wrote:

> On Sat, 3 Mar 2001, Aleksey Novodvorsky wrote:
> 
>  Hi, 
> 
> > Vlad Harchev wrote:
> > 
> > > On Sat, 3 Mar 2001, Aleksey Novodvorsky wrote:
> > >
> > > > Господа, новая версия gtk+ страдает серьезными глюками. Я буду
> признаетелен за сообщения об их проявлениях.
> > > > Чиню.
> > >
> > >  А что за глюки, можно поподробнее? Наверно с вводом русского в
> GtkEntry?
> > 
> > Глюки в gdk.
> 
> > Первая глюка -- функция sanitize_ctext из gdkselection.  Она, судя по
> > тексту, правильно работает со стандартными charsets (iso), но ее
> авторы не
> > прочитали про нестандартные, а потому в заголовках окон появляются
> %koi8.  
> > Смысл этого sanitize_ctext состоит, насколько я понимаю, в обеспечении
> > независимости от X.
> 
>  А вот первая глюка проявляется только на XFree-4.x? Просто люди,
> пробовавшие
> этот новый gtk говорят что в XFree-3.x все с заголовками окон нормально.
> 
>  Ну и некоторые говорят, что stuphead работает и не валится при
> перемещении по
> тексту с новым gtk.

Комбинацию gtk+-1.2.9 + XFree-4.x я еще не пробовал, но вот icewm < 1.0.6 с XFree-4.0.2 дает мусор с koi8-r в заголовках и с gtk+ 1.2.8. А на 3.3.6 все нормально. (Это все было на 7.0 RE + Appendix + самосборный 4.0.2).

stuphead я сейчас выкинул, а вот sylpheed вместе с gtk+-1.2.9 --with-native-locale валился действительно. Одно место я нашел:

http://bugzilla.gnome.org/show_bug.cgi?id=51644

Но там еще есть ошибки, так что я --with-native-locale убрал, и sylpheed-0.4.62cvs4 (из Sisyphus, покореженный на предмет сборки старым rpm) работает, и не падает (им, собственно, и пишу :-). Но опять же с XFree 3.3.6.

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Vlad Harchev]

On Sun, 11 Mar 2001, Sergey Vlasov wrote:

 Hi, 

> On Sun, 11 Mar 2001 17:06:21 +0400 (SAMT)
> Vlad Harchev <hvv@hippo.ru> wrote:
> 
> > On Sat, 3 Mar 2001, Aleksey Novodvorsky wrote:
> > 
> >  Hi, 
> > 
> > > Vlad Harchev wrote:
> > > 
> > > > On Sat, 3 Mar 2001, Aleksey Novodvorsky wrote:
> > > >
> > > > > Господа, новая версия gtk+ страдает серьезными глюками. Я буду
> > признаетелен за сообщения об их проявлениях.
> > > > > Чиню.
> > > >
> > > >  А что за глюки, можно поподробнее? Наверно с вводом русского в
> > GtkEntry?
> > > 
> > > Глюки в gdk.
> > 
> > > Первая глюка -- функция sanitize_ctext из gdkselection.  Она, судя по
> > > тексту, правильно работает со стандартными charsets (iso), но ее
> > авторы не
> > > прочитали про нестандартные, а потому в заголовках окон появляются
> > %koi8.  
> > > Смысл этого sanitize_ctext состоит, насколько я понимаю, в обеспечении
> > > независимости от X.
> > 
> >  А вот первая глюка проявляется только на XFree-4.x? Просто люди,
> > пробовавшие
> > этот новый gtk говорят что в XFree-3.x все с заголовками окон нормально.
> > 
> >  Ну и некоторые говорят, что stuphead работает и не валится при
> > перемещении по
> > тексту с новым gtk.
> 

> Комбинацию gtk+-1.2.9 + XFree-4.x я еще не пробовал, но вот icewm < 1.0.6
> с XFree-4.0.2 дает мусор с koi8-r в заголовках и с gtk+ 1.2.8. А на 3.3.6
> все нормально. (Это все было на 7.0 RE + Appendix + самосборный 4.0.2).

 А с любым другим WM (и с версиями icewm > 1.0.5) на XF-4.0.2  (ну и
gtk-1.2.9 и gtk-1.2.8) проблемы с заголовками окон есть? А то может проблема
с заголовками - это проблема с icewm а не gtk?

> stuphead я сейчас выкинул, а вот sylpheed вместе с gtk+-1.2.9
> --with-native-locale валился действительно. Одно место я нашел:
> 
> http://bugzilla.gnome.org/show_bug.cgi?id=51644
> 
> Но там еще есть ошибки, так что я --with-native-locale убрал, и
> sylpheed-0.4.62cvs4 (из Sisyphus, покореженный на предмет сборки старым
> rpm) работает, и не падает (им, собственно, и пишу :-). Но опять же с
> XFree 3.3.6.
> 

 Спасибо за информацию!

 Best regards,
  -Vlad

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Sergey Vlasov]

On Sun, 11 Mar 2001 18:53:41 +0400 (SAMT)
Vlad Harchev <hvv@hippo.ru> wrote:

> On Sun, 11 Mar 2001, Sergey Vlasov wrote:
> 
>  Hi, 
> 
> > On Sun, 11 Mar 2001 17:06:21 +0400 (SAMT)
> > Vlad Harchev <hvv@hippo.ru> wrote:
> > 
> > > On Sat, 3 Mar 2001, Aleksey Novodvorsky wrote:
> > > 
> > >  Hi, 
> > > 
> > > > Vlad Harchev wrote:
> > > > 
> > > > > On Sat, 3 Mar 2001, Aleksey Novodvorsky wrote:
> > > > >
> > > > > > Господа, новая версия gtk+ страдает серьезными глюками. Я буду
> > > признаетелен за сообщения об их проявлениях.
> > > > > > Чиню.
> > > > >
> > > > >  А что за глюки, можно поподробнее? Наверно с вводом русского в
> > > GtkEntry?
> > > > 
> > > > Глюки в gdk.
> > > 
> > > > Первая глюка -- функция sanitize_ctext из gdkselection.  Она, судя
> по
> > > > тексту, правильно работает со стандартными charsets (iso), но ее
> > > авторы не
> > > > прочитали про нестандартные, а потому в заголовках окон появляются
> > > %koi8.  
> > > > Смысл этого sanitize_ctext состоит, насколько я понимаю, в
> обеспечении
> > > > независимости от X.
> > > 
> > >  А вот первая глюка проявляется только на XFree-4.x? Просто люди,
> > > пробовавшие
> > > этот новый gtk говорят что в XFree-3.x все с заголовками окон
> нормально.
> > > 
> > >  Ну и некоторые говорят, что stuphead работает и не валится при
> > > перемещении по
> > > тексту с новым gtk.
> > 
> 
> > Комбинацию gtk+-1.2.9 + XFree-4.x я еще не пробовал, но вот icewm <
> 1.0.6
> > с XFree-4.0.2 дает мусор с koi8-r в заголовках и с gtk+ 1.2.8. А на
> 3.3.6
> > все нормально. (Это все было на 7.0 RE + Appendix + самосборный
> 4.0.2).
> 
>  А с любым другим WM (и с версиями icewm > 1.0.5) на XF-4.0.2  (ну и
> gtk-1.2.9 и gtk-1.2.8) проблемы с заголовками окон есть? А то может
> проблема
> с заголовками - это проблема с icewm а не gtk?

Заголовки исправились после перехода на icewm 1.0.6 (1.0.5 не пробовал). Есть подозрение, что причина - появившаяся в этой версии локализация (в том числе русская). В KDE 2.0 таких проблем с заголовками вообще не было. Похоже, что GTK тут вообще не при чем - просто icewm неправильно разбирал изменившиеся в XF-4 коды (или просто надо было setlocale сделать). С другими WM не пробовал, завтра к вечеру, может быть, доберусь до этой машины, посмотрю.

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Vlad Harchev]

On Sun, 11 Mar 2001, Sergey Vlasov wrote:

> On Sun, 11 Mar 2001 18:53:41 +0400 (SAMT)
> Vlad Harchev <hvv@hippo.ru> wrote:
> 
> > 
> >  А с любым другим WM (и с версиями icewm > 1.0.5) на XF-4.0.2  (ну и
> > gtk-1.2.9 и gtk-1.2.8) проблемы с заголовками окон есть? А то может
> > проблема
> > с заголовками - это проблема с icewm а не gtk?
> 
> Заголовки исправились после перехода на icewm 1.0.6 (1.0.5 не пробовал).
> Есть подозрение, что причина - появившаяся в этой версии локализация (в
> том числе русская). В KDE 2.0 таких проблем с заголовками вообще не было.
> Похоже, что GTK тут вообще не при чем - просто icewm неправильно разбирал
> изменившиеся в XF-4 коды (или просто надо было setlocale сделать). С
> другими WM не пробовал, завтра к вечеру, может быть, доберусь до этой
> машины, посмотрю.

 Не забудьте пожалуйста послать сюда результаты - до gnome-1.4  осталось
совсем немного - еще есть возможность исправить..

 Best regards,
  -Vlad

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Sergey Vlasov]

On Sun, 11 Mar 2001 17:10:49 +0300
Sergey Vlasov <vsu@mivlgu.murom.ru> wrote:

> On Sun, 11 Mar 2001 17:06:21 +0400 (SAMT)
> Vlad Harchev <hvv@hippo.ru> wrote:
> 
> > On Sat, 3 Mar 2001, Aleksey Novodvorsky wrote:
> > 
> >  Hi, 
> > 
> > > Vlad Harchev wrote:
> > > 
> > > > On Sat, 3 Mar 2001, Aleksey Novodvorsky wrote:
> > > >
> > > > > Господа, новая версия gtk+ страдает серьезными глюками. Я буду
> > признаетелен за сообщения об их проявлениях.
> > > > > Чиню.
> > > >
> > > >  А что за глюки, можно поподробнее? Наверно с вводом русского в
> > GtkEntry?
> > > 
> > > Глюки в gdk.
> > 
> > > Первая глюка -- функция sanitize_ctext из gdkselection.  Она, судя
> по
> > > тексту, правильно работает со стандартными charsets (iso), но ее
> > авторы не
> > > прочитали про нестандартные, а потому в заголовках окон появляются
> > %koi8.  
> > > Смысл этого sanitize_ctext состоит, насколько я понимаю, в
> обеспечении
> > > независимости от X.
> > 
> >  А вот первая глюка проявляется только на XFree-4.x? Просто люди,
> > пробовавшие
> > этот новый gtk говорят что в XFree-3.x все с заголовками окон
> нормально.
> > 
> >  Ну и некоторые говорят, что stuphead работает и не валится при
> > перемещении по
> > тексту с новым gtk.
> 
> Комбинацию gtk+-1.2.9 + XFree-4.x я еще не пробовал, но вот icewm <
> 1.0.6 с XFree-4.0.2 дает мусор с koi8-r в заголовках и с gtk+ 1.2.8. А
> на 3.3.6 все нормально. (Это все было на 7.0 RE + Appendix + самосборный
> 4.0.2).
> 
> stuphead я сейчас выкинул, а вот sylpheed вместе с gtk+-1.2.9
> --with-native-locale валился действительно. Одно место я нашел:
> 
> http://bugzilla.gnome.org/show_bug.cgi?id=51644
> 
> Но там еще есть ошибки, так что я --with-native-locale убрал, и
> sylpheed-0.4.62cvs4 (из Sisyphus, покореженный на предмет сборки старым
> rpm) работает, и не падает (им, собственно, и пишу :-). Но опять же с
> XFree 3.3.6.

Продолжаем исследование. У меня не совсем Sisyphus - glibc пока 2.1.3 с Appendix, XFree 3.3.6, но rpm, perl, bash, tar, bzip2, fileutils свежие, так что пакеты из новых src.rpm собираются. Итак, результаты:

1. "Wide characters" для mbstowcs (glibc) и для Xwc* - это не одно и то же! По крайней мере, сейчас в gdb проверил - в 1.2.9-ipd4mdk gdk_draw_text_wc передает в XwcDrawString текст в Unicode (но с родным порядком байтов) - именно так работает glibc (2.1.3). Но на экране рисуется, похоже, младший байт этого значения в кодировке koi8-r. В версии 1.2.8 проблем нет - там все преобразования идут через Xmb/Xwc*, а в 1.2.9 при их смешивании получается ерунда. Возможно, это проблема старой glibc (пока не обновил, тем более, говорят, процесс сложный, а описания я не нашел; тащить инсталлятор нет возможности). Или же виноват старый Xlib 3.3.6.

2. Баг (http://bugzilla.gnome.org/show_bug.cgi?id=51644) пришлось исправлять; опять же, возможно, старая glibc, но это просто граничный случай (нулевая длина), вроде бы влиять не должно.

Пока все, продолжим наши извращения...

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Sergey Vlasov]

Да, совсем забыл, в gtk+-1.2.9-ipl4mdk баг у меня ловится обычным testgtk - в GtkEntry не работает русский (вместо русских букв, похоже, рисует младший байт юникода). 1.2.8, естественно, работает (gtkrc был от него, сейчас поправленный - то же самое). Причем баг именно в libgdk (при создании с помощью LD_LIBRARY_PATH смеси из 1.2.8 и 1.2.9 именно при использовании libgdk от 1.2.9 вылезает мусор).

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Alexander Bokovoy]

On Sun, Mar 11, 2001 at 08:43:18PM +0300, Sergey Vlasov wrote:
> > Но там еще есть ошибки, так что я --with-native-locale убрал, и
> > sylpheed-0.4.62cvs4 (из Sisyphus, покореженный на предмет сборки старым
> > rpm) работает, и не падает (им, собственно, и пишу :-). Но опять же с
> > XFree 3.3.6.
> 
> Продолжаем исследование. У меня не совсем Sisyphus - glibc пока 2.1.3
> с Appendix, XFree 3.3.6, но rpm, perl, bash, tar, bzip2, fileutils
> свежие, так что пакеты из новых src.rpm собираются. Итак, результаты:
> 1. "Wide characters" для mbstowcs (glibc) и для Xwc* - это не одно и
> то же! По крайней мере, сейчас в gdb проверил - в 1.2.9-ipd4mdk
> gdk_draw_text_wc передает в XwcDrawString текст в Unicode (но с родным
> порядком байтов) - именно так работает glibc (2.1.3). Но на экране
> рисуется, похоже, младший байт этого значения в кодировке koi8-r. В
> версии 1.2.8 проблем нет - там все преобразования идут через Xmb/Xwc*, а
> в 1.2.9 при их смешивании получается ерунда. Возможно, это проблема
> старой glibc (пока не обновил, тем более, говорят, процесс сложный, а
> описания я не нашел; тащить инсталлятор нет возможности). Или же виноват
> старый Xlib 3.3.6.
В новой glibc (2.2.2) порядок следования байт в Wide characters зависит
от ендианности машины, в частности, на PC -- LE.

-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project   | www.midgard-project.org |    Aurora R&D team 
Minsk Linux Users Group |    www.minsk-lug.net    |  www.aurora-linux.com  
    ALT Linux Team      |    www.alt-linux.org    | Architecte Open Source
-- Remembering is for those who have forgotten.
		-- Chinese proverb

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Alexander Bokovoy]

On Mon, Mar 12, 2001 at 05:56:06AM +0300, aen wrote:
> Vlad Harchev wrote:
> 
> > On Sat, 3 Mar 2001, Aleksey Novodvorsky wrote:
> >
> >
> >  А вот первая глюка проявляется только на XFree-4.x? Просто люди, пробовавшие
> > этот новый gtk говорят что в XFree-3.x все с заголовками окон нормально.
> 
> Пожалуйста, не надо ссылаться на "людей".  Вы сами можете посмотреть в текст и убедиться, что написанное там не
> учитывает особенностей формирования esc-sequences для нестандартных кодировок, к коим отностяся KOI8-R(U) и CP1251.
> Авторам gtk+, правда, просто негде было об этом прочитать. Придется, видимо, учить русский :-)
> >  Ну и некоторые говорят, что stuphead работает и не валится при перемещении по
> > тексту с новым gtk.
> 
> Влад, "некоторые"  -- это  уже слишком.  Да и при чем здесь stuphead?
:-) О некоторых либо всё, либо ничего :-)
Алексей, на нем (Stuphead) и проверялось -- с XFree86 4.0.2 оригинальным
и gtk+ 1.2.9 оригинальным. Скорее всего, влияющие в данном случае
изменения в XFree86 были внесены уже в CVS после выхода 4.0.2.

-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project   | www.midgard-project.org |    Aurora R&D team 
Minsk Linux Users Group |    www.minsk-lug.net    |  www.aurora-linux.com  
    ALT Linux Team      |    www.alt-linux.org    | Architecte Open Source
-- Remembering is for those who have forgotten.
		-- Chinese proverb

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Sergey Vlasov]

On Sun, 11 Mar 2001 20:53:50 +0200
Alexander Bokovoy <ab@avilink.net> wrote:

> On Sun, Mar 11, 2001 at 08:43:18PM +0300, Sergey Vlasov wrote:
> > > Но там еще есть ошибки, так что я --with-native-locale убрал, и
> > > sylpheed-0.4.62cvs4 (из Sisyphus, покореженный на предмет сборки
> старым
> > > rpm) работает, и не падает (им, собственно, и пишу :-). Но опять же
> с
> > > XFree 3.3.6.
> > 
> > Продолжаем исследование. У меня не совсем Sisyphus - glibc пока 2.1.3
> > с Appendix, XFree 3.3.6, но rpm, perl, bash, tar, bzip2, fileutils
> > свежие, так что пакеты из новых src.rpm собираются. Итак, результаты:
> > 1. "Wide characters" для mbstowcs (glibc) и для Xwc* - это не одно и
> > то же! По крайней мере, сейчас в gdb проверил - в 1.2.9-ipd4mdk
> > gdk_draw_text_wc передает в XwcDrawString текст в Unicode (но с родным
> > порядком байтов) - именно так работает glibc (2.1.3). Но на экране
> > рисуется, похоже, младший байт этого значения в кодировке koi8-r. В
> > версии 1.2.8 проблем нет - там все преобразования идут через Xmb/Xwc*,
> а
> > в 1.2.9 при их смешивании получается ерунда. Возможно, это проблема
> > старой glibc (пока не обновил, тем более, говорят, процесс сложный, а
> > описания я не нашел; тащить инсталлятор нет возможности). Или же
> виноват
> > старый Xlib 3.3.6.
> В новой glibc (2.2.2) порядок следования байт в Wide characters зависит
> от ендианности машины, в частности, на PC -- LE.

Так у меня не 2.2.2, а 2.1.3, и тоже LE (по крайней мере в тестовой программке в массиве из wchar_t после mbstowcs() вижу нормальные значения ISO10646/Unicode, а не с переставленными байтами). Видимо, это как раз и есть кодировка "INTERNAL", использующаяся в gconv. А вот iconv при запросе ISO10646 вроде бы должен выдавать BE независимо от машины.

Итак, получается, что wchar_t в glibc - это ISO10646 с родным для машины порядком байт, и в glibc 2.1.3, и в 2.2.2. Тогда возникает вопрос, как рассматривают wchar_t функции Xwc* - тоже как ISO10646 или по-своему? Во всяком случае, у меня на 3.3.6 XwcDrawString получает на вход юникод и рисует вместо него, похоже, просто младший байт. Может быть, в 4.x это исправлено? Завтра придется смотреть на разных машинах и сравнивать.

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Alexander Bokovoy]

On Sun, Mar 11, 2001 at 10:21:36PM +0300, Sergey Vlasov wrote:
> On Sun, 11 Mar 2001 20:53:50 +0200
> Alexander Bokovoy <ab@avilink.net> wrote:
> 
> > On Sun, Mar 11, 2001 at 08:43:18PM +0300, Sergey Vlasov wrote:
> > > > Но там еще есть ошибки, так что я --with-native-locale убрал, и
> > > > sylpheed-0.4.62cvs4 (из Sisyphus, покореженный на предмет сборки
> > старым
> > > > rpm) работает, и не падает (им, собственно, и пишу :-). Но опять же
> > с
> > > > XFree 3.3.6.
> > > 
> > > Продолжаем исследование. У меня не совсем Sisyphus - glibc пока 2.1.3
> > > с Appendix, XFree 3.3.6, но rpm, perl, bash, tar, bzip2, fileutils
> > > свежие, так что пакеты из новых src.rpm собираются. Итак, результаты:
> > > 1. "Wide characters" для mbstowcs (glibc) и для Xwc* - это не одно и
> > > то же! По крайней мере, сейчас в gdb проверил - в 1.2.9-ipd4mdk
> > > gdk_draw_text_wc передает в XwcDrawString текст в Unicode (но с родным
> > > порядком байтов) - именно так работает glibc (2.1.3). Но на экране
> > > рисуется, похоже, младший байт этого значения в кодировке koi8-r. В
> > > версии 1.2.8 проблем нет - там все преобразования идут через Xmb/Xwc*,
> > а
> > > в 1.2.9 при их смешивании получается ерунда. Возможно, это проблема
> > > старой glibc (пока не обновил, тем более, говорят, процесс сложный, а
> > > описания я не нашел; тащить инсталлятор нет возможности). Или же
> > виноват
> > > старый Xlib 3.3.6.
> > В новой glibc (2.2.2) порядок следования байт в Wide characters зависит
> > от ендианности машины, в частности, на PC -- LE.
> 
> Так у меня не 2.2.2, а 2.1.3, и тоже LE (по крайней мере в тестовой
> программке в массиве из wchar_t после mbstowcs() вижу нормальные
> значения ISO10646/Unicode, а не с переставленными байтами). Видимо, это
> как раз и есть кодировка "INTERNAL", использующаяся в gconv. А вот iconv
> при запросе ISO10646 вроде бы должен выдавать BE независимо от машины.
Я не рекомендую пользоваться именем кодировки UNICODE в iconv -- оно не
портабельное. А вот UCS2-LE/BE -- портабельные. Собственно, поэтому многие
пользуются UTF-8. Это лирическое отступление, а если серьезно -- в glibc такого
имени (ISO10646) для кодировки нет, там только UNICODE, но он выдает
с привязкой к порядку байт на машине. INTERNAL, кстати, означает UCS2-LE
на PC.

> Итак, получается, что wchar_t в glibc - это ISO10646 с родным для машины
> порядком байт, и в glibc 2.1.3, и в 2.2.2. Тогда возникает вопрос, как
> рассматривают wchar_t функции Xwc* - тоже как ISO10646 или по-своему? Во
> всяком случае, у меня на 3.3.6 XwcDrawString получает на вход юникод и
> рисует вместо него, похоже, просто младший байт. Может быть, в 4.x это
> исправлено? Завтра придется смотреть на разных машинах и сравнивать.
Насколько я знаю, именно в 4-тых сериях и исправлено.

-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project   | www.midgard-project.org |    Aurora R&D team 
Minsk Linux Users Group |    www.minsk-lug.net    |  www.aurora-linux.com  
    ALT Linux Team      |    www.alt-linux.org    | Architecte Open Source
-- Out of sight is out of mind.
		-- Arthur Clough

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Alexander Bokovoy]

On Mon, Mar 12, 2001 at 06:45:08AM +0300, aen wrote:
> Alexander Bokovoy wrote:
> 
> >
> > >
> > > Влад, "некоторые"  -- это  уже слишком.  Да и при чем здесь stuphead?
> > :-) О некоторых либо всё, либо ничего :-)
> > Алексей, на нем (Stuphead) и проверялось -- с XFree86 4.0.2 оригинальным
> > и gtk+ 1.2.9 оригинальным. Скорее всего, влияющие в данном случае
> > изменения в XFree86 были внесены уже в CVS после выхода 4.0.2.
> 
> Бага с отображением %koi8 в заголовках проверялась мною  на
> оригинальном 4.0.2, -- она была.  Равно как и падение
> sylpheed.
Падение sylpheed я видел сам, а вот stuphead в ситуации "оригинальный
XFree86 + оригинальный gtk+ 1.2.9" не падал от передвижения курсора
при наборе русского текста.
-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project   | www.midgard-project.org |    Aurora R&D team 
Minsk Linux Users Group |    www.minsk-lug.net    |  www.aurora-linux.com  
    ALT Linux Team      |    www.alt-linux.org    | Architecte Open Source
-- Love your enemies: they'll go crazy trying to figure out what you're up to.

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Sergey Vlasov]

On Sun, 11 Mar 2001 21:28:51 +0200
Alexander Bokovoy <ab@avilink.net> wrote:

> On Sun, Mar 11, 2001 at 10:21:36PM +0300, Sergey Vlasov wrote:
> > On Sun, 11 Mar 2001 20:53:50 +0200
> > Alexander Bokovoy <ab@avilink.net> wrote:
> > 
> > > On Sun, Mar 11, 2001 at 08:43:18PM +0300, Sergey Vlasov wrote:
> > > > > Но там еще есть ошибки, так что я --with-native-locale убрал, и
> > > > > sylpheed-0.4.62cvs4 (из Sisyphus, покореженный на предмет сборки
> > > старым
> > > > > rpm) работает, и не падает (им, собственно, и пишу :-). Но опять
> же
> > > с
> > > > > XFree 3.3.6.
> > > > 
> > > > Продолжаем исследование. У меня не совсем Sisyphus - glibc пока
> 2.1.3
> > > > с Appendix, XFree 3.3.6, но rpm, perl, bash, tar, bzip2, fileutils
> > > > свежие, так что пакеты из новых src.rpm собираются. Итак,
> результаты:
> > > > 1. "Wide characters" для mbstowcs (glibc) и для Xwc* - это не одно
> и
> > > > то же! По крайней мере, сейчас в gdb проверил - в 1.2.9-ipd4mdk
> > > > gdk_draw_text_wc передает в XwcDrawString текст в Unicode (но с
> родным
> > > > порядком байтов) - именно так работает glibc (2.1.3). Но на экране
> > > > рисуется, похоже, младший байт этого значения в кодировке koi8-r.
> В
> > > > версии 1.2.8 проблем нет - там все преобразования идут через
> Xmb/Xwc*,
> > > а
> > > > в 1.2.9 при их смешивании получается ерунда. Возможно, это
> проблема
> > > > старой glibc (пока не обновил, тем более, говорят, процесс
> сложный, а
> > > > описания я не нашел; тащить инсталлятор нет возможности). Или же
> > > виноват
> > > > старый Xlib 3.3.6.
> > > В новой glibc (2.2.2) порядок следования байт в Wide characters
> зависит
> > > от ендианности машины, в частности, на PC -- LE.
> > 
> > Так у меня не 2.2.2, а 2.1.3, и тоже LE (по крайней мере в тестовой
> > программке в массиве из wchar_t после mbstowcs() вижу нормальные
> > значения ISO10646/Unicode, а не с переставленными байтами). Видимо,
> это
> > как раз и есть кодировка "INTERNAL", использующаяся в gconv. А вот
> iconv
> > при запросе ISO10646 вроде бы должен выдавать BE независимо от машины.
> Я не рекомендую пользоваться именем кодировки UNICODE в iconv -- оно не
> портабельное. А вот UCS2-LE/BE -- портабельные. Собственно, поэтому
> многие
> пользуются UTF-8. Это лирическое отступление, а если серьезно -- в glibc
> такого
> имени (ISO10646) для кодировки нет, там только UNICODE, но он выдает
> с привязкой к порядку байт на машине. INTERNAL, кстати, означает UCS2-LE
> на PC.

Оппс, имел в виду UCS4 - там именно BE. А по поводу INTERNAL в libc.info (glibc iconv Implementation) написано, что это почти UCS4, но с родным порядком байт (и действительно, sizeof(wchar_t) == 4). Как я понимаю, именно INTERNAL и используется для wchar_t.

> > Итак, получается, что wchar_t в glibc - это ISO10646 с родным для
> машины
> > порядком байт, и в glibc 2.1.3, и в 2.2.2. Тогда возникает вопрос, как
> > рассматривают wchar_t функции Xwc* - тоже как ISO10646 или по-своему?
> Во
> > всяком случае, у меня на 3.3.6 XwcDrawString получает на вход юникод и
> > рисует вместо него, похоже, просто младший байт. Может быть, в 4.x это
> > исправлено? Завтра придется смотреть на разных машинах и сравнивать.
> Насколько я знаю, именно в 4-тых сериях и исправлено.

Тогда дальнейшее исследование придется отложить до завтра.

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Alexander Bokovoy]

On Sun, Mar 11, 2001 at 11:08:54PM +0300, Sergey Vlasov wrote:
> > на PC.
> 
> Оппс, имел в виду UCS4 - там именно BE. А по поводу INTERNAL в
> libc.info (glibc iconv Implementation) написано, что это почти UCS4, но
> с родным порядком байт (и действительно, sizeof(wchar_t) == 4). Как я
> понимаю, именно INTERNAL и используется для wchar_t.
В XFree86 используется 16-битные последовательности для символов, но при
этом происходит конверсия (xc/lib/X11/lcUTF8.c):
/* Part I: Conversion routines CompoundText/CharSet <--> Unicode/UTF-8.
 *
 * Note that this code works in any locale. We store Unicode values in
 * `ucs4_t' variables, but don't pass them to the user.
 *
 * This code has to support all character sets that are used for CompoundText,
 * nothing more, nothing less. See the table in lcCT.c.
 * Since the conversion _to_ CompoundText is likely to need the tables for all
 * character sets at once, we don't use dynamic loading (of tables or shared
 * libraries through iconv()). Use a fixed set of tables instead.
 *
 * We use statically computed tables, not dynamically allocated arrays,
 * because it's more memory efficient: Different processes using the same
 * libX11 shared library share the "text" and read-only "data" sections.
*/
typedef unsigned int ucs4_t;

То есть, используется тот формат, который приемлем для системы, что
совпадает с wchar_t из glibc. Но все это -- в XFree86 4.0.2

-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project   | www.midgard-project.org |    Aurora R&D team 
Minsk Linux Users Group |    www.minsk-lug.net    |  www.aurora-linux.com  
    ALT Linux Team      |    www.alt-linux.org    | Architecte Open Source
-- I bought some used paint. It was in the shape of a house.
		-- Steven Wright

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Alexander Bokovoy]

On Mon, Mar 12, 2001 at 07:07:00AM +0300, aen wrote:
> Alexander Bokovoy wrote:
> 
> > On Mon, Mar 12, 2001 at 06:45:08AM +0300, aen wrote:
> > > Alexander Bokovoy wrote:
> > >
> > > >
> > > > >
> > > > > Влад, "некоторые"  -- это  уже слишком.  Да и при чем здесь stuphead?
> > > > :-) О некоторых либо всё, либо ничего :-)
> > > > Алексей, на нем (Stuphead) и проверялось -- с XFree86 4.0.2 оригинальным
> > > > и gtk+ 1.2.9 оригинальным. Скорее всего, влияющие в данном случае
> > > > изменения в XFree86 были внесены уже в CVS после выхода 4.0.2.
> > >
> > > Бага с отображением %koi8 в заголовках проверялась мною  на
> > > оригинальном 4.0.2, -- она была.  Равно как и падение
> > > sylpheed.
> > Падение sylpheed я видел сам, а вот stuphead в ситуации "оригинальный
> > XFree86 + оригинальный gtk+ 1.2.9" не падал от передвижения курсора
> > при наборе русского текста.
> 
> В любои случае, я пока не вижу  причин пересобирать gtk+-1.2.9 из Sisyphus. С ним
> работает все и всюду.
ОК. Завтра будет возможность сделать очередное обновление, тогда проверю.

-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project   | www.midgard-project.org |    Aurora R&D team 
Minsk Linux Users Group |    www.minsk-lug.net    |  www.aurora-linux.com  
    ALT Linux Team      |    www.alt-linux.org    | Architecte Open Source
-- "Love may fail, but courtesy will previal."
-- A Kurt Vonnegut fan

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Alexander Bokovoy]

On Mon, Mar 12, 2001 at 08:46:39AM +0300, aen wrote:
> Alexander Bokovoy wrote:
> > > > > Бага с отображением %koi8 в заголовках проверялась мною  на
> > > > > оригинальном 4.0.2, -- она была.  Равно как и падение
> > > > > sylpheed.
> > > > Падение sylpheed я видел сам, а вот stuphead в ситуации "оригинальный
> > > > XFree86 + оригинальный gtk+ 1.2.9" не падал от передвижения курсора
> > > > при наборе русского текста.
> > >
> > > В любои случае, я пока не вижу  причин пересобирать gtk+-1.2.9 из Sisyphus. С ним
> > > работает все и всюду.
> > ОК. Завтра будет возможность сделать очередное обновление, тогда проверю.
> 
> Лучше -- послезатра. В связи с переездом, мы не обновлялись с 7 марта, хотя собрано
> немало.
Ок. Похоже, что в связи с выходом PHP 4.0.5RC1 сегодня ночью, пакеты для него
(теперь уже официальные) будут тоже только завтра.
-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project   | www.midgard-project.org |    Aurora R&D team 
Minsk Linux Users Group |    www.minsk-lug.net    |  www.aurora-linux.com  
    ALT Linux Team      |    www.alt-linux.org    | Architecte Open Source
-- The things that interest people most are usually none of their business.

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[aen]

Vlad Harchev wrote:

> On Sat, 3 Mar 2001, Aleksey Novodvorsky wrote:
>
>
>  А вот первая глюка проявляется только на XFree-4.x? Просто люди, пробовавшие
> этот новый gtk говорят что в XFree-3.x все с заголовками окон нормально.

Пожалуйста, не надо ссылаться на "людей".  Вы сами можете посмотреть в текст и убедиться, что написанное там не
учитывает особенностей формирования esc-sequences для нестандартных кодировок, к коим отностяся KOI8-R(U) и CP1251.
Авторам gtk+, правда, просто негде было об этом прочитать. Придется, видимо, учить русский :-)

>
>
>  Ну и некоторые говорят, что stuphead работает и не валится при перемещении по
> тексту с новым gtk.

Влад, "некоторые"  -- это  уже слишком.  Да и при чем здесь stuphead?

Rgrds, AEN

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[aen]

Alexander Bokovoy wrote:

>
> >
> > Влад, "некоторые"  -- это  уже слишком.  Да и при чем здесь stuphead?
> :-) О некоторых либо всё, либо ничего :-)
> Алексей, на нем (Stuphead) и проверялось -- с XFree86 4.0.2 оригинальным
> и gtk+ 1.2.9 оригинальным. Скорее всего, влияющие в данном случае
> изменения в XFree86 были внесены уже в CVS после выхода 4.0.2.

Бага с отображением %koi8 в заголовках проверялась мною  на оригинальном 4.0.2, -- она была.  Равно как и падение
sylpheed.
Rgrds, AEN

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[aen]

Alexander Bokovoy wrote:

> On Mon, Mar 12, 2001 at 06:45:08AM +0300, aen wrote:
> > Alexander Bokovoy wrote:
> >
> > >
> > > >
> > > > Влад, "некоторые"  -- это  уже слишком.  Да и при чем здесь stuphead?
> > > :-) О некоторых либо всё, либо ничего :-)
> > > Алексей, на нем (Stuphead) и проверялось -- с XFree86 4.0.2 оригинальным
> > > и gtk+ 1.2.9 оригинальным. Скорее всего, влияющие в данном случае
> > > изменения в XFree86 были внесены уже в CVS после выхода 4.0.2.
> >
> > Бага с отображением %koi8 в заголовках проверялась мною  на
> > оригинальном 4.0.2, -- она была.  Равно как и падение
> > sylpheed.
> Падение sylpheed я видел сам, а вот stuphead в ситуации "оригинальный
> XFree86 + оригинальный gtk+ 1.2.9" не падал от передвижения курсора
> при наборе русского текста.

В любои случае, я пока не вижу  причин пересобирать gtk+-1.2.9 из Sisyphus. С ним
работает все и всюду.

Rgrds, AEN

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[aen]

Alexander Bokovoy wrote:

> On Mon, Mar 12, 2001 at 07:07:00AM +0300, aen wrote:
> > Alexander Bokovoy wrote:
> >
> > > On Mon, Mar 12, 2001 at 06:45:08AM +0300, aen wrote:
> > > > Alexander Bokovoy wrote:
> > > >
> > > > >
> > > > > >
> > > > > > Влад, "некоторые"  -- это  уже слишком.  Да и при чем здесь stuphead?
> > > > > :-) О некоторых либо всё, либо ничего :-)
> > > > > Алексей, на нем (Stuphead) и проверялось -- с XFree86 4.0.2 оригинальным
> > > > > и gtk+ 1.2.9 оригинальным. Скорее всего, влияющие в данном случае
> > > > > изменения в XFree86 были внесены уже в CVS после выхода 4.0.2.
> > > >
> > > > Бага с отображением %koi8 в заголовках проверялась мною  на
> > > > оригинальном 4.0.2, -- она была.  Равно как и падение
> > > > sylpheed.
> > > Падение sylpheed я видел сам, а вот stuphead в ситуации "оригинальный
> > > XFree86 + оригинальный gtk+ 1.2.9" не падал от передвижения курсора
> > > при наборе русского текста.
> >
> > В любои случае, я пока не вижу  причин пересобирать gtk+-1.2.9 из Sisyphus. С ним
> > работает все и всюду.
> ОК. Завтра будет возможность сделать очередное обновление, тогда проверю.

Лучше -- послезатра. В связи с переездом, мы не обновлялись с 7 марта, хотя собрано
немало.

Rgrds, AEN

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Vlad Harchev]

On Mon, 12 Mar 2001, aen wrote:

 Hi, 

> Alexander Bokovoy wrote:
> 
> >
> > >
> > > Влад, "некоторые"  -- это  уже слишком.  Да и при чем здесь stuphead?
> > :-) О некоторых либо всё, либо ничего :-)
> > Алексей, на нем (Stuphead) и проверялось -- с XFree86 4.0.2 оригинальным
> > и gtk+ 1.2.9 оригинальным. Скорее всего, влияющие в данном случае
> > изменения в XFree86 были внесены уже в CVS после выхода 4.0.2.
> 
> Бага с отображением %koi8 в заголовках проверялась мною  на оригинальном 4.0.2, -- она была.  Равно как и падение
> sylpheed.

 Алексей, а с какими менеджерами окон Вы наблюдали эту проблему?
Есть ли  WM'ы на которых этой проблемы не существовало? Вылечивалась
ли она откатом на 1.2.8? (Я как помню, типы данных LIST и TEXT имеют разные
форматы - какой-то один из них имеет в качестве префикса имя кодировки, а
другой - нет, вот может gtk стал юзать другой тип данных для заголовков окон
- вместо LIST TEXT или наоборот?)

 gtk-1.2.10 выйдет - посему есть повод для аргументированных и продуманных
жалоб.

 Best regards,
  -Vlad

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Sergey Vlasov]

On Sun, 11 Mar 2001 23:37:05 +0200
Alexander Bokovoy <ab@avilink.net> wrote:

> В XFree86 используется 16-битные последовательности для символов, но при
> этом происходит конверсия (xc/lib/X11/lcUTF8.c):
> /* Part I: Conversion routines CompoundText/CharSet <--> Unicode/UTF-8.
>  *
>  * Note that this code works in any locale. We store Unicode values in
>  * `ucs4_t' variables, but don't pass them to the user.
>  *
>  * This code has to support all character sets that are used for CompoundText,
>  * nothing more, nothing less. See the table in lcCT.c.
>  * Since the conversion _to_ CompoundText is likely to need the tables for all
>  * character sets at once, we don't use dynamic loading (of tables or shared
>  * libraries through iconv()). Use a fixed set of tables instead.
>  *
>  * We use statically computed tables, not dynamically allocated arrays,
>  * because it's more memory efficient: Different processes using the same
>  * libX11 shared library share the "text" and read-only "data" sections.
> */
> typedef unsigned int ucs4_t;

Все, глюк пойман. xc/lib/X11/lcUTF8.c в 3.3.6 отсутствует, но не в этом дело. В xc/lib/X11/lcGenConv.c и lcGeneric.c в структуре XLCdGenericPart есть такое интересное поле - use_stdc_env. Если там стоит True - используются функции из libc (из семейства mbtowc), False - собственная кодировка.

А поле устанавливается по содержимому /usr/X11R6/lib/X11/locale/koi8-r/XLC_LOCALE (или другого, в зависимости от LC_CTYPE). Так вот, в XFree 4.0.2 в этом файле стоит строка:

use_stdc_env		True

А в 3.3.6 ее нет, поэтому используется wc_encoding_mask, wc_shift_bits и другие странные способы кодирования (честно говоря, я в них не разбирался, но достаточно того, что не юникод).

Сейчас попробовал на 3.3.6 запустить testgtk из 1.2.9 - GtkEntry не работает, как я и писал, выводит вместо русских букв младший байт юникода. Добавил в /usr/X11R6/lib/X11/locale/koi8-r/XLC_LOCALE строчку "use_stdc_env True" - русские буквы появились.

Вывод - для перехода на gtk-1.2.9 требуется одно из двух:

1) Отказаться от --with-native-locale (в этом случае gdk_mbstowcs будет использовать XmbTextListToTextProperty и XwcTextPropertyToTextList, и результат этого в любом случае будет пригоден для XwcDrawString).

2) Патчить XFree 3.3.6 на предмет внесения во все файлы XLC_LOCALE строки "use_stdc_env True" по образцу XFree 4. К каким глюкам это может привести - неизвестно.

Понятно, что вариант "выбросить XFree 3.3.6 вообще" не пройдет - в XFree 4.0.2 есть не все драйверы.

Я так понимаю, что у всех тестирующих уже стоит XFree 4.0.2, вот этого фокуса никто и не замечал. Или в Sisyphus 3.3.6 все-таки уже попатчен таким образом?

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Sergey Vlasov]

On Tue, 13 Mar 2001 04:43:26 +0300
Aleksey Novodvorsky <aen@logic.ru> wrote:

> On Mon, 12 Mar 2001 20:31:06 +0300
> Sergey Vlasov <vsu@mivlgu.murom.ru> wrote:
> 
> 
> > 
> > Все, глюк пойман. xc/lib/X11/lcUTF8.c в 3.3.6 отсутствует, но не в этом дело. В xc/lib/X11/lcGenConv.c и lcGeneric.c в структуре XLCdGenericPart есть такое интересное поле - use_stdc_env. Если там стоит True - используются функции из libc (из семейства mbtowc), False - собственная кодировка.
> > 
> 
> Отлично!
> 
> 
> > 
> > 1) Отказаться от --with-native-locale (в этом случае gdk_mbstowcs будет использовать XmbTextListToTextProperty и XwcTextPropertyToTextList, и результат этого в любом случае будет пригоден для XwcDrawString).
> > 
> > 2) Патчить XFree 3.3.6 на предмет внесения во все файлы XLC_LOCALE строки "use_stdc_env True" по образцу XFree 4. К каким глюкам это может привести - неизвестно.
> 
> Это не приведет к глюкам. В Sisyphus от 3.3.6 -- только серверы, работающие с Xlib  от 4.0.2. XLC_LOCALE -- тоже от 4.0.2

То есть Xlib всегда 4.0.2? Тогда вообще ничего патчить не надо, понятно, почему никто, кроме меня, на глюк с GtkEntry не ругается. Как я понимаю, XFontSet и Xwc* кодировка используются только на клиентской стороне, так что проблем действительно быть не должно.

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Vlad Harchev]

On Tue, 13 Mar 2001, Aleksey Novodvorsky wrote:

> On Mon, 12 Mar 2001 19:34:17 +0400 (SAMT)
> Vlad Harchev <hvv@hippo.ru> wrote:
> 
> > On Mon, 12 Mar 2001, aen wrote:
> 
> > > 
> > > Бага с отображением %koi8 в заголовках проверялась мною  на оригинальном 4.0.2, -- она была.  Равно как и падение
> > > sylpheed.
> > 
> >  Алексей, а с какими менеджерами окон Вы наблюдали эту проблему?
> В GNOME/Sawfish.
> > Есть ли  WM'ы на которых этой проблемы не существовало?

 Все-таки, Вы пробовали с какими-нить другими менеджерами окон кроме sawfish
под XF-4.0.2? Каковы результаты?

> 
> > Вылечивалась
> > ли она откатом на 1.2.8?
> Да, конечно.
> 
> Еще раз: в тексте все видно невооруженным взглядом. Дело в том, что
> esc-последовательности для нестандартных кодировок могут содержать
> символы, которые будут отфильтрованы sanize_ctext. Эта функция написана
> просто без учета существования таких esc-последовательностей. И дело
> совсем не в том, что и где проявляется или не проявляется.  Очевидно
> неверный код не должен существовать.

 Как-нить придется глянуть код :)
 
> > (Я как помню, типы данных LIST и TEXT имеют разные
> > форматы - какой-то один из них имеет в качестве префикса имя кодировки, а
> > другой - нет, вот может gtk стал юзать другой тип данных для заголовков окон
> > - вместо LIST TEXT или наоборот?)
> > 
> >  gtk-1.2.10 выйдет - посему есть повод для аргументированных и продуманных
> > жалоб.
> 
> 
> Жалобы -- не по моей части.

 Я имел ввиду багрепорты, сорри. Вот их то по хорошему Вы должны слать
пачками, желательно в сопровождении патчей :)

 Best regards,
  -Vlad

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Aleksey Novodvorsky]

On Mon, 12 Mar 2001 19:34:17 +0400 (SAMT)
Vlad Harchev <hvv@hippo.ru> wrote:

> On Mon, 12 Mar 2001, aen wrote:

> > 
> > Бага с отображением %koi8 в заголовках проверялась мною  на оригинальном 4.0.2, -- она была.  Равно как и падение
> > sylpheed.
> 
>  Алексей, а с какими менеджерами окон Вы наблюдали эту проблему?
В GNOME/Sawfish.
> Есть ли  WM'ы на которых этой проблемы не существовало?


> Вылечивалась
> ли она откатом на 1.2.8?
Да, конечно.

Еще раз: в тексте все видно невооруженным взглядом. Дело в том, что esc-последовательности для нестандартных кодировок могут содержать символы, которые будут отфильтрованы sanize_ctext. Эта функция написана просто без учета существования таких esc-последовательностей. И дело совсем не в том, что и где проявляется или не проявляется.  Очевидно неверный код не должен существовать.

> (Я как помню, типы данных LIST и TEXT имеют разные
> форматы - какой-то один из них имеет в качестве префикса имя кодировки, а
> другой - нет, вот может gtk стал юзать другой тип данных для заголовков окон
> - вместо LIST TEXT или наоборот?)
> 
>  gtk-1.2.10 выйдет - посему есть повод для аргументированных и продуманных
> жалоб.


Жалобы -- не по моей части.


Rgrds, AEN

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Aleksey Novodvorsky]

On Mon, 12 Mar 2001 20:31:06 +0300
Sergey Vlasov <vsu@mivlgu.murom.ru> wrote:


> 
> Все, глюк пойман. xc/lib/X11/lcUTF8.c в 3.3.6 отсутствует, но не в этом дело. В xc/lib/X11/lcGenConv.c и lcGeneric.c в структуре XLCdGenericPart есть такое интересное поле - use_stdc_env. Если там стоит True - используются функции из libc (из семейства mbtowc), False - собственная кодировка.
> 

Отлично!


> 
> 1) Отказаться от --with-native-locale (в этом случае gdk_mbstowcs будет использовать XmbTextListToTextProperty и XwcTextPropertyToTextList, и результат этого в любом случае будет пригоден для XwcDrawString).
> 
> 2) Патчить XFree 3.3.6 на предмет внесения во все файлы XLC_LOCALE строки "use_stdc_env True" по образцу XFree 4. К каким глюкам это может привести - неизвестно.

Это не приведет к глюкам. В Sisyphus от 3.3.6 -- только серверы, работающие с Xlib  от 4.0.2. XLC_LOCALE -- тоже от 4.0.2

Rgrds, AEN

[sisyphus] Re: gtk+-1.2.9

[Sergey S. Skulachenko]

On Mon, 12 Mar 2001 22:52:51 +0400 (SAMT)
Vlad Harchev <hvv@hippo.ru> wrote:

>  Я имел ввиду багрепорты, сорри. Вот их то по хорошему Вы должны слать
> пачками, желательно в сопровождении патчей :)
Зачем? gtk+-1.2.10-aen.i586.rpm, и все дела.
С уважением,
С.С.Скулаченко

Re: [sisyphus] Re: gtk+-1.2.9

[Vlad Harchev]

On Tue, 13 Mar 2001, Sergey S. Skulachenko wrote:

> On Mon, 12 Mar 2001 22:52:51 +0400 (SAMT)
> Vlad Harchev <hvv@hippo.ru> wrote:
> 
> >  Я имел ввиду багрепорты, сорри. Вот их то по хорошему Вы должны слать
> > пачками, желательно в сопровождении патчей :)
> Зачем? gtk+-1.2.10-aen.i586.rpm, и все дела.

 А те, кто вынужден использовать что-нить отличное от Сизифа или устанавливать
пакеты которые явно зависят от других пакетов gtk, например
	gtk+-1.2.10-ximian.*.rpm
 - что делать им?

 По-любому надо хотя бы сказать о встреченной ошибке разработчикам (ведь
упоминание о проблемах gtk-1.2.9 появилось в этом списке практически случайно
- этого ведь могло и не произойти).. Такой подход еще приемлем для каких-либо
утититок которые уже никем не поддерживаются - но для таких ключевых пакетов
которые использует несколько сотен программ дистрибьютивов - следует хотя бы
сообщать ошибки IMO.

> С уважением,
> С.С.Скулаченко
> 
> _______________________________________________
> Sisyphus mailing list
> Sisyphus@linuxteam.iplabs.ru
> http://linuxteam.iplabs.ru/mailman/listinfo/sisyphus
> 

 Best regards,
  -Vlad

Re: [sisyphus] Re: gtk+-1.2.9

[Alexander Bokovoy]

On Tue, Mar 13, 2001 at 11:59:09AM +0400, Vlad Harchev wrote:
> On Tue, 13 Mar 2001, Sergey S. Skulachenko wrote:
> 
> > On Mon, 12 Mar 2001 22:52:51 +0400 (SAMT)
> > Vlad Harchev <hvv@hippo.ru> wrote:
> > 
> > >  Я имел ввиду багрепорты, сорри. Вот их то по хорошему Вы должны слать
> > > пачками, желательно в сопровождении патчей :)
> > Зачем? gtk+-1.2.10-aen.i586.rpm, и все дела.
> 
>  А те, кто вынужден использовать что-нить отличное от Сизифа или устанавливать
> пакеты которые явно зависят от других пакетов gtk, например
> 	gtk+-1.2.10-ximian.*.rpm
>  - что делать им?
> 
>  По-любому надо хотя бы сказать о встреченной ошибке разработчикам (ведь
> упоминание о проблемах gtk-1.2.9 появилось в этом списке практически случайно
> - этого ведь могло и не произойти).. Такой подход еще приемлем для каких-либо
> утититок которые уже никем не поддерживаются - но для таких ключевых пакетов
> которые использует несколько сотен программ дистрибьютивов - следует хотя бы
> сообщать ошибки IMO.
Влад, все это сообщается. Но -- как только будет хоть минутка свободного
времени для того, чтобы посетить страницу системы контроля качества того
или иного проекта. Что весьма проблематично в данный момент, поскольку
все силы брошены на завершение работы над Mandrake RE Spring 2001.

Проблема серьезнее, чем просто сообщение о найденных ошибках. Ведь в
данном случае ошибка возникла из-за недостатка документации на
конкретное функциональное расширение XFree86, а также из-за неуемного
желания разработчиков gtk бежать впереди паровоза и избавляться от
зависимостей от X11 для поддержки встроенных систем уже в ветке 1.x. И
это при том, что ветку 1.x и так собирались закрывать  (а избавление от
зависимостей от X11 я бы не назвал "мелким исправлением").

-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project   | www.midgard-project.org |    Aurora R&D team 
Minsk Linux Users Group |    www.minsk-lug.net    |  www.aurora-linux.com  
    ALT Linux Team      |    www.alt-linux.org    | Architecte Open Source
-- When we talk of tomorrow, the gods laugh.

Re: [sisyphus] Re: gtk+-1.2.9

[Vlad Harchev]

On Tue, 13 Mar 2001, Sergey S. Skulachenko wrote:

> On Mon, 12 Mar 2001 22:52:51 +0400 (SAMT)
> Vlad Harchev <hvv@hippo.ru> wrote:
> 
> >  Я имел ввиду багрепорты, сорри. Вот их то по хорошему Вы должны слать
> > пачками, желательно в сопровождении патчей :)
> Зачем? gtk+-1.2.10-aen.i586.rpm, и все дела.

 И кстати если он будет собираться с --with-native-locale у configure,
полученая библиотека не будет работать с use_std_env ...


 Best regards,
  -Vlad

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Vlad Harchev]

On Sun, 11 Mar 2001, Alexander Bokovoy wrote:

 Hi, 

> On Mon, Mar 12, 2001 at 05:56:06AM +0300, aen wrote:
> > Vlad Harchev wrote:
> > 
> > > On Sat, 3 Mar 2001, Aleksey Novodvorsky wrote:
> > >
> > >
> > >  А вот первая глюка проявляется только на XFree-4.x? Просто люди, пробовавшие
> > > этот новый gtk говорят что в XFree-3.x все с заголовками окон нормально.
> > 
> > Пожалуйста, не надо ссылаться на "людей".  Вы сами можете посмотреть в текст и убедиться, что написанное там не
> > учитывает особенностей формирования esc-sequences для нестандартных кодировок, к коим отностяся KOI8-R(U) и CP1251.
> > Авторам gtk+, правда, просто негде было об этом прочитать. Придется, видимо, учить русский :-)
> > >  Ну и некоторые говорят, что stuphead работает и не валится при перемещении по
> > > тексту с новым gtk.
> > 
> > Влад, "некоторые"  -- это  уже слишком.  Да и при чем здесь stuphead?
> :-) О некоторых либо всё, либо ничего :-)
> Алексей, на нем (Stuphead) и проверялось -- с XFree86 4.0.2 оригинальным
> и gtk+ 1.2.9 оригинальным. Скорее всего, влияющие в данном случае
> изменения в XFree86 были внесены уже в CVS после выхода 4.0.2.

 А что-нить еще с от оригинального gtk-1.2.9 падало или только
stuphead/sylpheed? Никто статистики не собрал? И еще - где падало в
_gdk_font_wc_to_glyphs? Или в функциях выделяющих/освобождающих память?
Хотелось бы bt. (у меня stuphead + XF-4.0.2 нету).

Если в функциях по работе с памятью - может просто эти почтовые агенты портят
память (списки malloc) и просто что-то изменилось в логике gtk?


 Насчет sanitize_ctext - где можно найти доки на нее (или кто их может
написать :)? Являются ли патчи от IPLabs к gtk-1.2.9 идеологически корректными
или это просто хаки? (я их не смотрел). Может кто мне послать ASAP патчи в
из gtk+-1.2.9-*.src.rpm от Сизифа? Знают ли разработчики gtk конкретно про эти
патчи или хотя бы конкретно об этой проблеме?


 Best regards,
  -Vlad

Re: [sisyphus] Re: gtk+-1.2.9

[Vlad Harchev]

On Tue, 13 Mar 2001, Vlad Harchev wrote:

> On Tue, 13 Mar 2001, Sergey S. Skulachenko wrote:
> 
> > On Mon, 12 Mar 2001 22:52:51 +0400 (SAMT)
> > Vlad Harchev <hvv@hippo.ru> wrote:
> > 
> > >  Я имел ввиду багрепорты, сорри. Вот их то по хорошему Вы должны слать
> > > пачками, желательно в сопровождении патчей :)
> > Зачем? gtk+-1.2.10-aen.i586.rpm, и все дела.
> 
>  И кстати если он будет собираться с --with-native-locale у configure,
> полученая библиотека не будет работать с use_std_env ...

 сорри, не докончил:
          .         .       .      .         с use_std_env False в XLC_LOCALE

 И gtk+-1.2.9-*.rpm в Сизифе собирается с --with-native-locale (как я понял из
сообщений в этом списке)...


 Best regards,
  -Vlad

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Aleksey Novodvorsky]

On Mon, 12 Mar 2001 22:52:51 +0400 (SAMT)
Vlad Harchev <hvv@hippo.ru> wrote:

> 
>  Как-нить придется глянуть код :)

А до тех пор не стоит обсуждать этот вопрос с теми, кто этот код видел и правил. 

Rgrds, Алексей

Re: [sisyphus] Re: gtk+-1.2.9

[Aleksey Novodvorsky]

On Tue, 13 Mar 2001 11:59:09 +0400 (SAMT)
Vlad Harchev <hvv@hippo.ru> wrote:

> On Tue, 13 Mar 2001, Sergey S. Skulachenko wrote:
> 
> > On Mon, 12 Mar 2001 22:52:51 +0400 (SAMT)
> > Vlad Harchev <hvv@hippo.ru> wrote:
> > 
> > >  Я имел ввиду багрепорты, сорри. Вот их то по хорошему Вы должны слать
> > > пачками, желательно в сопровождении патчей :)
> > Зачем? gtk+-1.2.10-aen.i586.rpm, и все дела.
> 
>  А те, кто вынужден использовать что-нить отличное от Сизифа или устанавливать
> пакеты которые явно зависят от других пакетов gtk, например
> 	gtk+-1.2.10-ximian.*.rpm
>  - что делать им?
> 
>  По-любому надо хотя бы сказать о встреченной ошибке разработчикам (ведь
> упоминание о проблемах gtk-1.2.9 появилось в этом списке практически случайно
> - этого ведь могло и не произойти)..

Это не могло не произойти. О всех ошибках такого плана мы всегда сразу же сообщаем разрабочикам по тем или иным каналам. Но вот  "пробиванием" патчей, как правило, не занимаемся.
В результате, практически все наши патчи включаются, но это происходит не сразу.

Rgrds, AEN

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Vlad Harchev]

On Wed, 14 Mar 2001, Aleksey Novodvorsky wrote:

> On Tue, 13 Mar 2001 20:17:47 +0400 (SAMT)
> Vlad Harchev <hvv@hippo.ru> wrote:
> 
> >
> > 
> >  А что-нить еще с от оригинального gtk-1.2.9 падало или только
> > stuphead/sylpheed? Никто статистики не собрал? И еще - где падало в
> > _gdk_font_wc_to_glyphs? Или в функциях выделяющих/освобождающих память?
> > Хотелось бы bt. (у меня stuphead + XF-4.0.2 нету).
> 
> Я проведу эксперименты позже. Сейчас я работаю со своим gtk-1.2.9

 ОК.
 
> > 
> > Если в функциях по работе с памятью - может просто эти почтовые агенты портят
> > память (списки malloc) и просто что-то изменилось в логике gtk?
> Возможно.

 У меня с gtk-1.2.9 лично ничего не падало (я stuphead/sylpheed не имею и
посему не пробовал с ними).
 
> > 
> > 
> >  Насчет sanitize_ctext - где можно найти доки на нее (или кто их может
> > написать :)?
> 
> Доки поищите на www.tsu.ru/~pascal. 

 ОК, спасибо за ссылку. Я расскажу разработчикам gtk о проблеме и укажу им
контактную информацию Ивана.

> > Являются ли патчи от IPLabs к gtk-1.2.9 идеологически корректными
> > или это просто хаки? (я их не смотрел). 
> Патча два. Один дополняет sanitize_ctext, созраняя символы, которые могут повяиться в нестандартных esc-sequences. Он был бы корректный, если бы не ошибка в старых XFree, где эти последовательности часто писались от фонаря, а потому сохраняется больше символов, чем на самом деле нужно.
> 
> Второй патч просто откатывает патч с _gdk_fint_wc_to_glyphs. Это плохо, но
> проблемы, из-за которых возникла необходимость в этой функции, в RE не
> возникают. Будет время -- поищу хорошее решение.

 Об описании причины появления _gdk_fint_wc_to_glyphs написано в 
http://www.hippo.ru/~hvv/gtk в комментарии к одному из моих патчей.

> >Может кто мне послать ASAP патчи в
> > из gtk+-1.2.9-*.src.rpm от Сизифа? Знают ли разработчики gtk конкретно про эти
> > патчи или хотя бы конкретно об этой проблеме?
> 
> Ok, сейчас  пошлю первый патч. Второй очевиден.

 Получил, спасибо большое за патч.
 
> Rgdrs, AEN

 Best regards,
  -Vlad

Re: [sisyphus] Re: gtk+-1.2.9

[Vlad Harchev]

On Wed, 14 Mar 2001, Aleksey Novodvorsky wrote:

> On Tue, 13 Mar 2001 20:22:45 +0400 (SAMT)
> Vlad Harchev <hvv@hippo.ru> wrote:
> 
> > On Tue, 13 Mar 2001, Vlad Harchev wrote:
> > 
> > > On Tue, 13 Mar 2001, Sergey S. Skulachenko wrote:
> > > 
> > > > On Mon, 12 Mar 2001 22:52:51 +0400 (SAMT)
> > > > Vlad Harchev <hvv@hippo.ru> wrote:
> > > > 
> > > > >  Я имел ввиду багрепорты, сорри. Вот их то по
> > хорошему Вы должны слать
> > > > > пачками, желательно в сопровождении патчей :)
> > > > Зачем? gtk+-1.2.10-aen.i586.rpm, и все дела.
> > > 
> > >  И кстати если он будет собираться с
> > --with-native-locale у configure,
> > > полученая библиотека не будет работать с use_std_env ...
> > 
> >  сорри, не докончил:
> >           .         .       .      .         с use_std_env
> > False в XLC_LOCALE
> > 
> >  И gtk+-1.2.9-*.rpm в Сизифе собирается с
> > --with-native-locale (как я понял из
> > сообщений в этом списке)...
> 
> Да, но я пока не вижу, чем это плохо. Зато некоторое
> ускорение работы -- хорошо. Если Вы убедите меня в противном
> -- соберу без этого ключа, -- проблемы здесь нет.

 Коль у Вас есть полный контроль над содержимым XLC_LOCALE ваших пользователей
и что там гарантировано есть use_std_env, то --with-native-locale имеет смысл
и возможно даже полезно (из-за ускорения работы). В частности, люди,
вытаскивающие пакеты из сизифа на свои машины с use_std_env = False будут
недоумевать почему у них gtk не работает...

 Так кто читает XLC_LOCALE и интерпретирует use_std_env - Xlib и/или Хсервер?
 Я это к тому, если X-сервер тоже читает - то XVNC который базируется на
XFree-3.1.1 - может пострадать если в XFree-3.1.1 не было поддержки
use_std_env - просто нельзя будет работать с gtk-шным софтом через XVnc (если 
gtk собран с --with-native-locale).

 А насчет другого патча - для sanize_ctext  - вы сказали что это он оставляет
некоторые ненужные символы в заголовке, что будет проявляться на старых XFree.
Хотя этому патчу как я понимаю альтернативы нет.. И еще - что такое старые
XFree - это какие версии?

 Кстати, кто-нить имел проблемы с русским в заголовках при использовании
патченного gtk-1.2.9 из Сизифа со старыми XFree?

> Rgrds, AEN

 Best regards,
  -Vlad

Re: [sisyphus] Re: gtk+-1.2.9

[Vlad Harchev]

On Wed, 14 Mar 2001, Aleksey Novodvorsky wrote:

> On Tue, 13 Mar 2001 22:58:24 +0400 (SAMT)
> Vlad Harchev <hvv@hippo.ru> wrote:
> 
> > 
> >  Так кто читает XLC_LOCALE и интерпретирует use_std_env -
> > Xlib и/или Хсервер?
> 
> Думаю, что только Xlib, но вопорос интересный.

 Вообще X-server тоже должен знать, в какой кодировке ему приходят текстовые
данные - вот посему и вопрос - хотя тогда получится, что с машины на которой
use_std_env =0 нельзя будет работать с русским с Х-сервером на другой машине у
которого  use_std_env =1 если так...
 
> >  Я это к тому, если X-сервер тоже читает - то XVNC который
> > базируется на
> > XFree-3.1.1 - может пострадать если в XFree-3.1.1 не было
> > поддержки
> > use_std_env - просто нельзя будет работать с gtk-шным
> > софтом через XVnc (если 
> > gtk собран с --with-native-locale).
> > 
> >  А насчет другого патча - для sanize_ctext  - вы сказали
> > что это он оставляет
> > некоторые ненужные символы в заголовке, что будет
> > проявляться на старых XFree.
> 
> Не вполне так. Я вообще полагаю, что чистка в sanize_ctext
> избыточна. Для \r она понятна, а для вот для символов >=128
> -- похоже, для перестраховки. Что касается старых XFree то
> они просто не дают написать полностью корректный патч,
> который оставляет ровно то, что нужно. Дело в том, что в
> esc-последовательности  для нестандартных charset
> присутствует такой символ, как \200+<длина названия charset>
> . Но так как до Ивана об этом никто не знал (:-) кроме
> автора текста, который это не документировал), то Чернов
> (началось с него) назначил для koi8-r esc-sequence почти от
> фонаря. А дальше были другие, в том числе и Ваш покорный
> слуга с патчем для koi8-u :-/

 В смысле, вместо явного указания имени кодировки просто использовался
какой-то ассоциированный с ней код (один символ какой-то)? Да уж...

> > Хотя этому патчу как я понимаю альтернативы нет.. И еще -
> > что такое старые
> > XFree - это какие версии?
> 
> Иван выкинул явное опредление  esc-sequence для
> нестандартных кодировок в 4.0.2, заменив на алгоритмическое.

 А причем здесь Иван и XFree если содержимое CTEXT вроде формируется только
тулкитами/надстройками на XLib и только ими интерпретируется? Или в XLib есть
helper functions (которыми никто не обязан пользоваться), которые и были
подправлены Иваном?
 
> > 
> >  Кстати, кто-нить имел проблемы с русским в заголовках при
> > использовании
> > патченного gtk-1.2.9 из Сизифа со старыми XFree?
> Со старым XFree -- не отмечено. А вот со старым Xlib --
> боюсь, что и не пробовал.

 А на всех ли строках можно будет увидеть этот эффект на старых XFree или есть
какие-то особенные комбинации?  Я завтра попробую с Вашим патчем - хотелось бы
знать как надо искать проблемы чтобы ее гарантировано заметить..

> Rgrds, AEN

 Best regards,
  -Vlad

Re: [sisyphus] Re: gtk+-1.2.9

[Sergey Vlasov]

On Wed, 14 Mar 2001 06:51:14 +0300
Aleksey Novodvorsky <aen@logic.ru> wrote:

> On Tue, 13 Mar 2001 22:58:24 +0400 (SAMT)
> Vlad Harchev <hvv@hippo.ru> wrote:
> 
> > 
> >  Так кто читает XLC_LOCALE и интерпретирует use_std_env -
> > Xlib и/или Хсервер?
> 
> Думаю, что только Xlib, но вопорос интересный.

По крайней мере в моем бинарнике XF86_SVGA от 3.3.6 строки XLC_LOCALE или use_stdc_env вообще нет. Так что не читает. Да и зачем это ему - на уровне X-протокола вообще нет понятия FontSet и wide character - только STRING8 и STRING16 с индексами символов в шрифте.

Re: [sisyphus] Re: gtk+-1.2.9

[Alexander Bokovoy]

On Tue, Mar 13, 2001 at 11:58:02PM +0400, Vlad Harchev wrote:
> On Wed, 14 Mar 2001, Aleksey Novodvorsky wrote:
> > присутствует такой символ, как \200+<длина названия charset>
> > . Но так как до Ивана об этом никто не знал (:-) кроме
> > автора текста, который это не документировал), то Чернов
> > (началось с него) назначил для koi8-r esc-sequence почти от
> > фонаря. А дальше были другие, в том числе и Ваш покорный
> > слуга с патчем для koi8-u :-/
> 
>  В смысле, вместо явного указания имени кодировки просто использовался
> какой-то ассоциированный с ней код (один символ какой-то)? Да уж...
Нет, просто перед именем кодировки записывается байт с длиной имени
кодировки + \200.


-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project   | www.midgard-project.org |    Aurora R&D team 
Minsk Linux Users Group |    www.minsk-lug.net    |  www.aurora-linux.com  
    ALT Linux Team      |    www.alt-linux.org    | Architecte Open Source
-- The way some people find fault, you'd think there was some kind of reward.

Re: [sisyphus] Re: gtk+-1.2.9

[Aleksey Novodvorsky]

On Tue, 13 Mar 2001 19:56:53 +0400 (SAMT)
Vlad Harchev <hvv@hippo.ru> wrote:

> On Tue, 13 Mar 2001, Sergey S. Skulachenko wrote:
> 
> > On Mon, 12 Mar 2001 22:52:51 +0400 (SAMT)
> > Vlad Harchev <hvv@hippo.ru> wrote:
> > 
> > >  Я имел ввиду багрепорты, сорри. Вот их то по хорошему Вы должны слать
> > > пачками, желательно в сопровождении патчей :)
> > Зачем? gtk+-1.2.10-aen.i586.rpm, и все дела.
> 
>  И кстати если он будет собираться с --with-native-locale у configure,
> полученая библиотека не будет работать с use_std_env ...
> 
Бинарные rpm собираются для конкретного дистрибутива, в лучшем случае -- группы дистрибутивов. Это плохо, но здесь сейчас ничего не поделаешь.

Функция sanize_ctext -- типичный пример хака.   Лучше было бы ее вообще выкинуть и я это не сделал только потому, что она может сохраниться и даже укрепиться в последующих версиях. Авторы gtk+,  вместо работы над XFree86, решили общую проблему своей затычкой, к тому же некорректной. Возможно, у них просто не хватило сил и времени на дискуссии. У меня этого времени тоже нет, но мой патч более корректен, хотя и вынужден учитывать ошибку в esc-последовательностях из XFree86 < 4.0.2 (исправлена Иваном Паскалем).

Rgrds, AEN

Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Aleksey Novodvorsky]

On Tue, 13 Mar 2001 20:17:47 +0400 (SAMT)
Vlad Harchev <hvv@hippo.ru> wrote:

>
> 
>  А что-нить еще с от оригинального gtk-1.2.9 падало или только
> stuphead/sylpheed? Никто статистики не собрал? И еще - где падало в
> _gdk_font_wc_to_glyphs? Или в функциях выделяющих/освобождающих память?
> Хотелось бы bt. (у меня stuphead + XF-4.0.2 нету).

Я проведу эксперименты позже. Сейчас я работаю со своим gtk-1.2.9

> 
> Если в функциях по работе с памятью - может просто эти почтовые агенты портят
> память (списки malloc) и просто что-то изменилось в логике gtk?
Возможно.
> 
> 
>  Насчет sanitize_ctext - где можно найти доки на нее (или кто их может
> написать :)?

Доки поищите на www.tsu.ru/~pascal. 

> Являются ли патчи от IPLabs к gtk-1.2.9 идеологически корректными
> или это просто хаки? (я их не смотрел). 
Патча два. Один дополняет sanitize_ctext, созраняя символы, которые могут повяиться в нестандартных esc-sequences. Он был бы корректный, если бы не ошибка в старых XFree, где эти последовательности часто писались от фонаря, а потому сохраняется больше символов, чем на самом деле нужно.

Второй патч просто откатывает патч с _gdk_fint_wc_to_glyphs. Это плохо, но проблемы, из-за которых возникла необходимость в этой функции, в RE не возникают. Будет время -- поищу хорошее решение.

>Может кто мне послать ASAP патчи в
> из gtk+-1.2.9-*.src.rpm от Сизифа? Знают ли разработчики gtk конкретно про эти
> патчи или хотя бы конкретно об этой проблеме?

Ok, сейчас  пошлю первый патч. Второй очевиден.

Rgdrs, AEN

Re: [sisyphus] Re: gtk+-1.2.9

[Aleksey Novodvorsky]

On Tue, 13 Mar 2001 20:22:45 +0400 (SAMT)
Vlad Harchev <hvv@hippo.ru> wrote:

> On Tue, 13 Mar 2001, Vlad Harchev wrote:
> 
> > On Tue, 13 Mar 2001, Sergey S. Skulachenko wrote:
> > 
> > > On Mon, 12 Mar 2001 22:52:51 +0400 (SAMT)
> > > Vlad Harchev <hvv@hippo.ru> wrote:
> > > 
> > > >  Я имел ввиду багрепорты, сорри. Вот их то по
> хорошему Вы должны слать
> > > > пачками, желательно в сопровождении патчей :)
> > > Зачем? gtk+-1.2.10-aen.i586.rpm, и все дела.
> > 
> >  И кстати если он будет собираться с
> --with-native-locale у configure,
> > полученая библиотека не будет работать с use_std_env ...
> 
>  сорри, не докончил:
>           .         .       .      .         с use_std_env
> False в XLC_LOCALE
> 
>  И gtk+-1.2.9-*.rpm в Сизифе собирается с
> --with-native-locale (как я понял из
> сообщений в этом списке)...

Да, но я пока не вижу, чем это плохо. Зато некоторое
ускорение работы -- хорошо. Если Вы убедите меня в противном
-- соберу без этого ключа, -- проблемы здесь нет.

Rgrds, AEN

Re: [sisyphus] Re: gtk+-1.2.9

[Aleksey Novodvorsky]

On Tue, 13 Mar 2001 22:58:24 +0400 (SAMT)
Vlad Harchev <hvv@hippo.ru> wrote:

> 
>  Так кто читает XLC_LOCALE и интерпретирует use_std_env -
> Xlib и/или Хсервер?

Думаю, что только Xlib, но вопорос интересный.

>  Я это к тому, если X-сервер тоже читает - то XVNC который
> базируется на
> XFree-3.1.1 - может пострадать если в XFree-3.1.1 не было
> поддержки
> use_std_env - просто нельзя будет работать с gtk-шным
> софтом через XVnc (если 
> gtk собран с --with-native-locale).
> 
>  А насчет другого патча - для sanize_ctext  - вы сказали
> что это он оставляет
> некоторые ненужные символы в заголовке, что будет
> проявляться на старых XFree.

Не вполне так. Я вообще полагаю, что чистка в sanize_ctext
избыточна. Для \r она понятна, а для вот для символов >=128
-- похоже, для перестраховки. Что касается старых XFree то
они просто не дают написать полностью корректный патч,
который оставляет ровно то, что нужно. Дело в том, что в
esc-последовательности  для нестандартных charset
присутствует такой символ, как \200+<длина названия charset>
. Но так как до Ивана об этом никто не знал (:-) кроме
автора текста, который это не документировал), то Чернов
(началось с него) назначил для koi8-r esc-sequence почти от
фонаря. А дальше были другие, в том числе и Ваш покорный
слуга с патчем для koi8-u :-/

> Хотя этому патчу как я понимаю альтернативы нет.. И еще -
> что такое старые
> XFree - это какие версии?

Иван выкинул явное опредление  esc-sequence для
нестандартных кодировок в 4.0.2, заменив на алгоритмическое.

> 
>  Кстати, кто-нить имел проблемы с русским в заголовках при
> использовании
> патченного gtk-1.2.9 из Сизифа со старыми XFree?
Со старым XFree -- не отмечено. А вот со старым Xlib --
боюсь, что и не пробовал.

Rgrds, AEN

Re: [sisyphus] Re: gtk+-1.2.9

[Sergey Vlasov]

On Tue, 13 Mar 2001 22:58:24 +0400 (SAMT)
Vlad Harchev <hvv@hippo.ru> wrote:

> On Wed, 14 Mar 2001, Aleksey Novodvorsky wrote:
> 
> > On Tue, 13 Mar 2001 20:22:45 +0400 (SAMT)
> > Vlad Harchev <hvv@hippo.ru> wrote:
> > 
> > > On Tue, 13 Mar 2001, Vlad Harchev wrote:
> > > 
> > > > On Tue, 13 Mar 2001, Sergey S. Skulachenko wrote:
> > > > 
> > > > > On Mon, 12 Mar 2001 22:52:51 +0400 (SAMT)
> > > > > Vlad Harchev <hvv@hippo.ru> wrote:
> > > > > 
> > > > > >  Я имел ввиду багрепорты, сорри. Вот их то по
> > > хорошему Вы должны слать
> > > > > > пачками, желательно в сопровождении патчей :)
> > > > > Зачем? gtk+-1.2.10-aen.i586.rpm, и все дела.
> > > > 
> > > >  И кстати если он будет собираться с
> > > --with-native-locale у configure,
> > > > полученая библиотека не будет работать с use_std_env ...
> > > 
> > >  сорри, не докончил:
> > >           .         .       .      .         с use_std_env
> > > False в XLC_LOCALE
> > > 
> > >  И gtk+-1.2.9-*.rpm в Сизифе собирается с
> > > --with-native-locale (как я понял из
> > > сообщений в этом списке)...
> > 
> > Да, но я пока не вижу, чем это плохо. Зато некоторое
> > ускорение работы -- хорошо. Если Вы убедите меня в противном
> > -- соберу без этого ключа, -- проблемы здесь нет.
> 
>  Коль у Вас есть полный контроль над содержимым XLC_LOCALE ваших
> пользователей
> и что там гарантировано есть use_std_env, то --with-native-locale имеет
> смысл
> и возможно даже полезно (из-за ускорения работы). В частности, люди,
> вытаскивающие пакеты из сизифа на свои машины с use_std_env = False
> будут
> недоумевать почему у них gtk не работает...
> 
>  Так кто читает XLC_LOCALE и интерпретирует use_std_env - Xlib и/или
> Хсервер?
>  Я это к тому, если X-сервер тоже читает - то XVNC который базируется на
> XFree-3.1.1 - может пострадать если в XFree-3.1.1 не было поддержки
> use_std_env - просто нельзя будет работать с gtk-шным софтом через XVnc
> (если 
> gtk собран с --with-native-locale).

Что точно не работает - это смесь клиентов с Xlib 4.0.2 и 3.3.6 на сервере 3.3.6. Сейчас попробовал - русских заголовков окон с 4.0.2 не видно вообще (WM на 3.3.6), текст не копируется. А gtk везде 1.2.8.