GTK+ 2.24.0

>> производительности

Производительности чего?

добавлю ещё про сортировку по алфавиту, которая тоже страдает в случае такой упоротой кодировки как koi8-r

>Лучше бы диалог открытия файлов переписали.
Традиционно - что в нем не так?

>Я уже почти 10 лет в кои-8, так что не надо тут ругаться! Стабильность - она и в Африке стабильность. Пока что-то работает, и работает хорошо - зачем ломать?
+1. В двуязычной системе уникод в целом нафиг не нужен. В одноязычной тем более.

> Традиционно - что в нем не так?

Снять выделение нельзя.

>Что мне в данный момент не нравится в GTK+ 3, так это отсутствие туториалов. Пишут, что вот-вот релиз выйдет, а как свой виджет написать непонятно. Роюсь в исходникак gnome, где они портированием занимаются.
В туториале на сайте гтк+ описано как сделать виджет.
В книжке про ГТК, которая за бабло, тоже описано.
В статье на бимерском сайте - тоже было.

Хотя, стиль изложения оставляет желать... :(

Действительно, в качестве кодировки для общения с «внешним миром», UTF-8 - практически идеальный выбор (в том числе и из-за совместимости с ASCII).

Если использовать её в качестве внутреннего формата представления данных, то преимущества превращаются в недостатки - в частности, очень мешает переменная ширина символа - т.е. по объему занимаемой памяти даже нельзя сказать, сколько символов в строке. С UTF-16 / UTF-32 этой проблемы нет - все операции имеют такую же сложность, как если бы символы занимали один байт.

Идея простая: в проге быстро вычисляем строки, а utf только на выводе (ну и на вводе). Это удобно. Да-да, четырёхбайтовые символы дольше обрабатывать, чем однобайтовые. Также можно сказать про четырёхбайтовые числа (или, упоси Господи, восьмибайтовые).

> http://packages.debian.org/lenny/libqt4-assistant

И не обращай внимания, что по другому тулкит называется.

Ага, теперь понял :) Ну, будем искать/ждать. Правда, когда появится, будет уже не так нужно, так как шишки будут уже набиты на себе.

Зачем ASCII-совместимость?

Затем, чтобы юникодовое ПО хоть как-то работало на 8-битных локалях или с другим древним ПО, которое о юникоде ничего не знает.

>Ага, теперь понял :) Ну, будем искать/ждать. Правда, когда появится, будет уже не так нужно, так как шишки будут уже набиты на себе.

А может сразу правильный тулкит?)

Зашел-то, ясное дело, потроллить :)

А насчет производительности да, неправ я был: в 32-битной системе по идее, разницы в сравнении 8-ми, 16-ти или 32-х битных чисел быть не должно. А в 64-битной еще и long туда добавится...

>Затем, чтобы юникодовое ПО хоть как-то работало на 8-битных локалях

А где это еще 8-битные локали?

или с другим древним ПО, которое о юникоде ничего не знает.

Ну вот, из-за совместимости с х**ней продолжать лепить х**ню. Как всегда.

С UTF-16 / UTF-32 этой проблемы нет - все операции имеют такую же сложность, как если бы символы занимали один байт.

utf-16 точно так же, как и utf-8, не является кодировкой с символом фиксированной длины.

Довольно удобно для всяких стандартных протоколов и форматов. Например, в том же xml - нафига по 4 байта на каждую букву тега? (я не рассматриваю извращенцев с нелатинскими тегами)
Опять же, без нужды не нужно все тексты с программами утолщать вчетверо:) В общем, есть некое кол-во практических бенефитов. А недостаток только один - переменный размер символа.

Ах да, поддержка 8-битности полезна для работы со старым железом типа терминалов и пр.

> В туториале на сайте гтк+ описано как сделать виджет.

В книжке про ГТК, которая за бабло, тоже описано.
В статье на бимерском сайте - тоже было.

Для GTK+ 2, а тут на носу выход GTK+ 3.

А еще CGI писать. У нас на всех серверах кои8-р. И, естественно, никто не собирается менять кодировку, чтобы потом получить геморрой в виде конвертирования всех документов с кои8 в юникод :)

> А может сразу правильный тулкит?)

Для себя, скорее всего. Но для существующего нужно оставаться в форме, готовясь к 3му релизу.

Однако, она есть.

> utf-16 точно так же, как и utf-8, не является кодировкой с символом фиксированной длины.

Ой, да. Думал о UCS2 / UCS4, написал не то. Каюсь.

Сорри, в сравнении, может быть, и нет - не знаю. Но в других операциях могут быть различия.

Ну вот, из-за совместимости с х**ней продолжать лепить х**ню. Как всегда.

А что делать? Куда не посмотри в айти, везде куча легаси из стандартов 80-х. Например, тот же HTTP протокол можно скрестить нормально с юникодом только через utf-8, либо придётся использовать ещё большие хардкорные извращения с base64. И таких, завязанных на ASCII, протоколов очень много, почти всё что сейчас активно используется в интернете.

С другой стороны, в этом нет ничего плохого. Делать текстовый протокол на UTF32 только ради справедливости во всём мире тоже глупо.

Не думаю. Даже копирование в память, по идее, происходит не побайтно, а кусками, в соответствии с разрядностью шины.

Это вторично. Это мелочи. Кстати, а вот если пользователь введет в браузере на вашем сайте в какую-нибудь формочку символ Евро? Поперек борозды вся хрен пойдет?

долго читал и не мог понять, что за новый виджет. вроде уже был и давно.

потом вспомнил, что я на gtkmm, в основном, пишу.

а там он уже давно был.

Ну и пусть себе вводит. На сервер передастся что-то вроде «%20ac», а им преобразуется в «╛» :)

>Этот релиз подводит черту под развитием

Ура, теперь можно начать закапывать!

придёт что-то типа &#x20AC, так же и останется.

Я на своем скрипте и проверял. Получается именно «╛» :)

Король умер... Да здравствует Король!

>Разрабы GTK - молодцы! Вот как надо пилить софт

как-то уж очень неумело они его пилят, если на выходе деревянное угрёбище получается

И у Вас конечно есть доказательства?

Ну и что? Так и надо?

Так вроде символ евро должен быть €, а не ╛. Лажает значит скрипт.

Да. Кому нужен символ евро, пользуются юникодом :)

Аааа! Мы все умрём!?!
GIMP и FF перепишут на GTK3 или на чем-нибудь ещё?

>>Разрабы GTK - молодцы! Вот как надо пилить софт

как-то уж очень неумело они его пилят, если на выходе деревянное угрёбище получается

Потому что третьему гному нужен гроб!

Т.е. в результате вы ограничиваете пользователя, используя кривые 8-битные скрипты.

>Аааа! Мы все умрём!?!

GIMP и FF перепишут на GTK3 или на чем-нибудь ещё?

FF на Qt уже пишут.

Хочу это увидеть )

Нормальный диалог выбора файлов сделали? :)

> Вот не понимаю, почему из glade убрали удобную кодогенерацию? Ведь намного меньше кода писать приходилось бы...

тот убогий код, который генерировался в glade-2, предназначался только для того, чтобы выбросить из зависимостей libglade. когда функционал сторонней либы перенесли непосредственно в gtk, надобность в этом костыле отпала.

>Хочу это увидеть )

Дык было уже в Talks. http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-centr... Только глаза потом новые поставь.

>FF на Qt уже пишут.
Как основной тулкит? Пруф есть? ФФ4 вроде, на GTK2 пока...

>>FF на Qt уже пишут.

Как основной тулкит? Пруф есть? ФФ4 вроде, на GTK2 пока...

Не как основной.

Его утверждение истинно. Firefox действительно пишут на Qt, пока что как форк.

Ну, ФФ пытается Qt интерфейс дополнительным сделать, сколько я его помню. И всё безуспешно. Интересно, на чем будет его основной интерфейс после GTK2 RIP.

Поставить не смогу сразу так. Я на работе, может скрины где завалялись

Gtk 3? Вы просто так говорите как будто после миграции прийдется переписывать более 3% кода )

>Вы просто так говорите как будто после миграции прийдется переписывать более 3% кода )
Для ФФ 3% может, и не будут проблемой, а вот для GIMP... Он итак еле шевелится. Надеюсь, после выхода GTK3 GTK2 можно будет выкинуть также быстро, как Qt3 после выхода Qt4.