Планы по выпуску GTK+ версии 3

> Первое же вспомнившееся - Agnitum Outpost Firewall первой версии

О совместимости ядерного API/ABI речи не идет. Да и аутпост сам по себе убогая кривая поделка, даже (и особенно) по сравнению с winipfw, да даже по сравнению со штатным виндовым файрволом, аутпост просто кривая поделка (+1 к профессионализму МС).

>GObject и прочие конструкции очень легко привязываются к интерпретируемым языкам

И нах, прошу прощения, это в интерпретируемых языках, которые по определению скриптовые?

>В местах ООП например.

Есть Си - есть стандарты Си, заимствования из других языков сделают его уродливым комбайном и жалкой подобией С++

>правда тут уже корректнее сказать библиотеку Си, а не сам Си, но язык - это не только синтаксис

Настоящий ООП без костылей невозможно реализовать ввиде библиотеки, как и настоящую многопоточность, костыли не нужны

> "Правильный" тулкит должен легко биндиться на другие языки, чего за тулкитами, завязанными на С++, не наблюдается.

Ничего не имею против Qt, но +1.

> и множество исследований должно быть проведено до релиза

Может быть проще было на английском и оставить? :)

> QtOctave собирался с qt4.2 сейчас работает с 4.4, что не так?

А с Qt3.1 -> Qt3.3 слабо повторить? :-)

Вот пример: в Лиспе ООП тоже в какой-то степени костыль, ибо оно идентично набору костылей к схеме (в Common Lisp оно конечно входит в стандарт, но все равно синтаксис лиспа состоит только из скобок и указания имени ф-ии после каждой из них). Однако в Лиспе самое лучшее ООП.

Разработчики GTK тоже "прицепили" ООП к языку с малом кол-вом синтаксических правил. Но получили хорошую, мощную вещь.

А на С++ писать GUI нереально. ООП там слишком примитивное для этого. Именно поэтому Trolltech пришлось отойти ото всех стандартов и нагородить костылей к C++. Но эти костыли ужасны, ибо являются препроцессором самого языка, т.е. Qt не только не считается со стандартом на библиотеки C++, она и сам С++ "выкинула". Аналогично и с Borland.

> Во-вторых, они ждут Vala и потом переведут постепенно GTK на него

Ссылку на источник сей информации не дашь, мой анонимный брат?

> А с Qt3.1 -> Qt3.3 слабо повторить? :-)

Да, ибо лень искать qt3.1 ради столь сомнительных удовольствий.

>Подкладывает compat'ы в систему создатель дистрибутива...

да, и поэтому проблем с этим давно нет

>Это забота, по большей части, программиста, использующего конкретные функции и link'ера (можно собрать статически), и дистрибьютора этих библиотек в системе (M$)

MFC зачастую себя по разному ведет в статическом и динамическом виде. Рано или поздно нить совместимости и с тем и с тем теряется. При этом дефолтовый MFC проект генерируется с динамической линковкой, и исторически почти все проекты завязаны на нее, так как пионеры нагенерировали мастером, а потом все заросло типичным С++ ным мхом. В Windows-центричном приперитарном мире эти проблемы решать не любят - работает ну и хрен с ним.

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

> Qt не только не считается со стандартом на библиотеки C++, она и сам С++ "выкинула". Аналогично и с Borland

Тетраглюкан не принимали? Симптомы похожие, ибо троллтех с языком ничего не делали, лишь прикрутили препроцессор (ага гытека пошли намного дальше со своим Vala), вы можете всю работу препроцессора написать сами вручную. А багланд написали свой вариант компилятора который вносит новые конструкции в язык, разницу видите? (если нет, то промывание желудочков мозга и перечитывание поста)

> Может быть проще было на английском и оставить? :)

Просто не хотелось ломать мозг посреди рабочего дня.

Упс, я что-то сказал про рабочий день? :)

>нагородить костылей к C++

Это про сигналы и слоты, что ли?

>А на С++ писать GUI нереально

Только пишут, почему-то, больше на С++, чем на С.

Не в обиду GTK будет сказано, но выглядит как обычная доработка C-style под ООП язык. Почему бы сразу не заюзать ООП, хоть на том же C++. Там уже есть "способ для доступа к полям класса"/"нормальные методы доступа (в виде функций)", "закрытые члены класса"/"поля-указатели "priv" на структуры, содержащие закрытые данные, должны быть скрыты".

Я не против C-style ООП, но, IMHO, он оправдан где-нибудь в ядре, в hard-soft realtime и т.д. где нужен полный контроль над системой. Нахрена для калькулятора использовать эти костыли к ООП?

P.S. geek уже отмечал - в чем крутизна KDE4 по сравнению с KDE3, прорывов никаких нет. По его мнению GTK1->GTK2 (соответственно GNOME1->GNOME2 вот он прорыв). А тут, вообще, GTK2_5 в лучшем случае.

Про Borland компилятор знаю естестенно, просто не стал о нем писать много (сейчас ведь не об этом?).

Vala - это другой язык. Прошу называть C++Qt отдельным языком QTLanguage, а не расхваливать C++, который ни на что не годен в рассматриваемой области.

>>А на С++ писать GUI нереально

>Только пишут, почему-то, больше на С++, чем на С.

Пишут на QTLanguage.

> Прошу заметить, о функциональности ни слова. Сплошная возня с собственными костылями.

Я тоже заметил. Ни одного упоминания о новых фичах или улучшениях старых. Какой смысл тогда менять мажорную версию, если это будет по сути всего лишь причёсанный гтк2.х? Куте хоть и поломали API, зато создали качественно новый тулкит, который на голову превосходит предыдущую ветку. А тут - просто смешно.

Опаньки!!! Так вроде ж самый "уважаемый" здесь специалист по DE,OOP и всему остальному говорил что "оно не нужно"...

Мои поздравления! Ждем ГНОМЕ-3 :-)))

А если кто-то (не TrollTech, не Borland, ...) пишут на С++, а не на др. языках, им прикидывающихся, то это вообще пипец уродливый код будет.

Все это можно было заменить одним пунктом:

- Move to C++

:D

>Наверное, таким образом разработчики пытаются избежать кошмара миграции, который можно видеть на примере библиотеки Qt.

Хаххаха, даже не смешно. ))

А вы др. новости на ЛОРе читали? Там раньше говорилось, что в gtk3 могут даже физику включить.

>Пишут на QTLanguage.

С такой точки зрения, у кутистов вообще костылей нет (часть языка ;)), а ГТК - сплошное костылестроение и прикручивание другой парадигмы к языку, для этого не очень подходящему.

> С точки зрения эндюзера - мне очень нравится совместимость версий GTK, поскольку в результате та же VMWare не нуждается в ежемесячном апдейте.

А ВмВаря разве не статически собрана, равно как и Акробат?

> Наверное, таким образом разработчики пытаются избежать кошмара миграции, который можно видеть на примере библиотеки Qt.

и где автор увидел кошмар???

кому надо было срочно перепрыгнуть, могут использовать Qt3Support

А остальные неспеша переписывают на чистом Qt4, в т.ч и kde4

>"Правильный" тулкит должен легко биндиться на другие языки, чего за тулкитами, завязанными на С++, не наблюдается.

Тулкиты на С++ отлично связываются с языками, которые поддерживают ООП минимум на том уровне, какой необходим тулкиту, т.е. если какой-то язык связать с тулкитом нельзя - это лишь значит, что этот язык не поддерживает ООП в необходимой мере для использования тулкита. И это уже явные ограничения языка, а не тулкит "неправильный". Избавляйтесь от идеологических цепей.

>Vala - это другой язык. Прошу называть C++Qt отдельным языком QTLanguage, а не расхваливать C++, который ни на что не годен в рассматриваемой области.

Чойто вы мыслеблудием промышляете, только что обвиняли тролльтехов в костылеобразовании, теперича узрев мощь сосновых подпорок валы, переключились на c++.

> А на С++ писать GUI нереально. ООП там слишком примитивное для этого.

Посмотри на AWT/Swing (прости господи). Там чистый ООП и никаких костылей, по крайней мере снаружи. Небольшой плюсик дают только анонимные и inner классы.

wxWidgets, gtkmm, они уродливы или свой изык придумали?

Просто Вы говорили, что С++ - хорошо. Я говорю - что там костыли.

А в QTLanguage костылей нет. Есть другие проблемы.

wxWidgets уродливы. А gtkmm мало кто юзает (по сравнению с обычным gtk).

> А вы др. новости на ЛОРе читали? Там раньше говорилось, что в gtk3 могут даже физику включить.

Я вот эту прочитал. Если у гтк есть какой-то роадмап со списком новых фич, я бы хотел на него посмотреть.

>Просто Вы говорили, что С++ - хорошо.

У белки провалы в памяти, покажите де такое случилось?

>Я говорю - что там костыли.

Ах, костыли в с++? А костылей в костылях вы не видели? И опятьже память, вроде костыли вы видели в moc, а теперь они перебрались в с++.

хоть и фоотопик, но :)

>MFC зачастую себя по разному ведет в статическом и динамическом виде.

пруфлинк

>Рано или поздно нить совместимости и с тем и с тем теряется.

пруфлинк

>При этом дефолтовый MFC проект генерируется с динамической линковкой, и исторически почти все проекты завязаны на нее, так как пионеры нагенерировали мастером, а потом все заросло типичным С++ ным мхом. В Windows-центричном приперитарном мире эти проблемы решать не любят - работает ну и хрен с ним.

это вообще поток сознания непонятно к чему сказаный :)

>wxWidgets уродливы

Чем?

>А gtkmm мало кто юзает (по сравнению с обычным gtk).

Ну только сами основатели Gimp Tool Kit, да?

xTERM невменяем. Хорош уже тут бред всякий писать! :Е

> кому надо было срочно перепрыгнуть, могут использовать Qt3Support

> А остальные неспеша переписывают на чистом Qt4, в т.ч и kde4

Ключевое слово "переписывают".

qtk - костыль к библиотекам Си.

moc - костыль к синтаксису с++.

Базовые классы Qt - костыль к стандарным либам с++.

Если рассматривать Qt как язык, то вышеперечисленные костыли qt уже не костыли.

Так понятно?

> Базовые классы Qt - костыль к стандарным либам с++.

С учетом того что qt не используют stdlib, ваше замечание становится поразительно смешным.

>Хорош уже тут бред всякий писать

Отсутствие слотов/сигналов в оригинальном с++ вас не смущает?

s/stdlib/stl/ !

>Ключевое слово "переписывают".

Ага, лучше мириться с тормозами и костылями, и продолжать жрать столетний кактус, но ничего не переписывать =)

Отсутствие хвостовой рекурсии в C вас не смущает?

Естественно. Костыль вытеснил стандартные библиотеки полностью!

Это нужно для GUI?

> А ВмВаря разве не статически собрана, равно как и Акробат?

[dalth@viking ~]$ ldd /usr/lib/vmware/bin/vmware
	linux-gate.so.1 =>  (0xffffe000)
	libdl.so.2 => /lib/libdl.so.2 (0x43a84000)
[....]
	libgobject-2.0.so.0 => /lib/libgobject-2.0.so.0 (0x43e55000)
	libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x4469f000)
	libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x446be000)
	libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x44109000)
	libpangoxft-1.0.so.0 => /usr/lib/libpangoxft-1.0.so.0 (0x43129000)
	libpangox-1.0.so.0 => /usr/lib/libpangox-1.0.so.0 (0x4311b000)
	libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x445f6000)
	libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x441d5000)
	libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x441f4000)
[....]

Упс?

> Я вот эту прочитал. Если у гтк есть какой-то роадмап со списком новых фич, я бы хотел на него посмотреть.

А какие фичи там ещё нужны? Ну хорошо, лучшую поддержку тем, всторенный наконец-то канвас, что ещё? И учитывая, что GTK - это не Qt, а что-то вроде qt-gui или как там оно именуется, то есть улучшения в других связанных библиотеках (например, cairo) окажут положительное влияние и на GTK.

>Отсутствие слотов/сигналов в оригинальном с++ вас не смущает?

Их можно реализовать стандартными плюсами , без мок-а

> Ключевое слово "переписывают".

Дело в том, что смена мажорной версии позволяет ломать API с чистой совестью. А вот менять мажорную версию без серьёзных изменений - это маразм в духе офтопика.