Предлагаю провести тесты Qt4 vs. GTK+

> Если мне нужно срочно спроектировать сложный интерфейс, я возьму, запущу QtDesigner и сконструирую его. Я уже втянут? :)

Да, втянут. Потому что _не сможешь_ использовать этот гуй с другой графической библиотекой.

> Не увлекайтесь самовнушением, это ведёт к аутизму.

имхо уже поздно давать такие советы...

> Да, втянут. Потому что _не сможешь_ использовать этот гуй с другой графической библиотекой.

O_o А с какой графической библиотекой я смогу использовать формочки Glade или делфи или дотнетовские иксемели?

Или XUL или _всё_что_угодно

>> Да, втянут. Потому что _не сможешь_ использовать этот гуй с другой графической библиотекой.

> А с какой графической библиотекой я смогу использовать формочки Glade или делфи или дотнетовские иксемели?

Вот-вот. Vendor lock-in в полный рост!

> Вот-вот. Vendor lock-in в полный рост!

Так ведь для того, собственно и нужны графические библиотеки, чтобы строить GUI. А XML-формы - это всего лишь инструмент, которым я, кстати, вообще не пользуюсь, мне удобней руками набросать слои, виджеты...

>Да. Ещё осознайте, что других графических либ на основе glib нет. Тем
>самым получим, что гтк и глиб всё же связаны и сильно влияют друг на
>друга.

Предлагаете написать ? :)

> glib это не комбайн :)
>Не увлекайтесь самовнушением, это ведёт к аутизму.

Ну и где там комбайновость ? Glib это базовая библиотека работы с обьектами. Собственно может быть использована другим языком/проектом.
Кстати даже была использована пару раз. Как минимум в mc.

PS
Но в чем то вы правы, спорить не стану. Просто я считаю что то в чем вы правы это недоработка авторов. И авторы Gtk тоже так считают, в основном.(ИМХО)

>> Вот-вот. Vendor lock-in в полный рост!

> Так ведь для того, собственно и нужны графические библиотеки, чтобы строить GUI.

Да, нужны для того, чтобы строить гуи. Но гуестроительство сейчас ведётся везде одинаково: те же идеи в geometry manager-ах, одинаковые виджеты... А вот формат хранения у всех -- разный, дабы затруднить переход к конкурентам.

>Да, втянут. Потому что _не сможешь_ использовать этот гуй с другой графической библиотекой.

Если уж будет так нужно, то сделаю интерфейс и для другой графической библиотеки.

Слушай, а если ты сделаешь интерфейс на глэйде, то сможешь использовать этот гуй с другой граф. библиотекой? :)))

> имхо уже поздно давать такие советы...

Человеку не читающему сообщения оппонентов обвинять кого то в аутизме совершенно не стоит. :)

>> Да. Ещё осознайте, что других графических либ на основе glib нет. Тем
самым получим, что гтк и глиб всё же связаны и сильно влияют друг на
друга.

> Предлагаете написать ? :)

Нет. Но опыт подсказывае, что возникнут трудности из-за заточенности одного под другое.

>> glib это не комбайн :)
>> Не увлекайтесь самовнушением, это ведёт к аутизму.

> Ну и где там комбайновость ? Glib это базовая библиотека работы с обьектами. Собственно может быть использована другим языком/проектом.
Кстати даже была использована пару раз. Как минимум в mc.

Вот именно, другим языком! Если в C нет рефлексии, замыканий, классов и прочего, что предоставляет Glib, так не надо на него это навешивать! Используйте тот язык, где всё это есть.

Конечно, кто-нибудь скажет, что "в те времена не было таких языков". Тут есть два варианта ответа:
1) А почему не написали, раз все необходимые функции были известны?
2) Tcl существует с 1988 года

Кстати, mc ж вроже на slang написан?

>O_o А с какой графической библиотекой я смогу использовать формочки
>Glade или делфи или дотнетовские иксемели?

Вообще говоря глайдовские xml можно использовать и не только с gtk, хотя это малоизвестно. Пробегали где то подобыне ссылки.

Так как в отличие от всего остального glade это только описания gui и все.

>> Да, втянут. Потому что _не сможешь_ использовать этот гуй с другой графической библиотекой.

> Если уж будет так нужно, то сделаю интерфейс и для другой графической библиотеки.

А кто оплатит затраченное время?

> Слушай, а если ты сделаешь интерфейс на глэйде, то сможешь использовать этот гуй с другой граф. библиотекой? :)))

Нет. В том-то и проблема.

>Вот именно, другим языком! Если в C нет рефлексии, замыканий, классов и
>прочего, что предоставляет Glib, так не надо на него это навешивать!
>Используйте тот язык, где всё это есть.

Вы не правы. Это как раз логично - если чего то нет в языке, реализовывать это через библиотеку. Особенно, если это нужно.

Кстати - вообще говоря в 80-е начале 90-х была целая куча языков которые описывались как C+обьекты. Многие (может даже почти все) возникали из специфической задачи - нужен был язык для написания GUI среды. Так например возник Objective C. Многие из них были расширением компилятора/препроцессора. И C++ был одним из них (хотя и не был придуман для конкретной GUI среды).

glib + C ИМХО это повторения того же пути под влиянием тех же сил. (см Vala)

>А кто оплатит затраченное время?

Я не вижу проблемы. Если нужно кроссплатформенное коммерческое решение корпоративного уровня, то just use java и получай деньги - нет проблем. Если разрабатываешь прикладную программу для простых юзеров в роли энтузиаста, то проектируй GUI для какого-то одного тулкита, либо для обоих популярных (гтк и кут).

> Да, нужны для того, чтобы строить гуи. Но гуестроительство сейчас ведётся везде одинаково: те же идеи в geometry manager-ах, одинаковые виджеты... А вот формат хранения у всех -- разный, дабы затруднить переход к конкурентам.

Ну я бы не сказал, что это единственная причина. У разных тулкитов разные менеджеры компоновки (а в некоторых они вообще отсутствую), разная иерархия виджетов и т.д. Кстати я недавно видел транслятор XUL -> Qt :)

>Многие из них были расширением компилятора/препроцессора. И C++ был одним из них (хотя и не был придуман для конкретной GUI среды).

С++ вообще был разработан не для проектирования GUI. GUI - побочный т.с. эффект.

>Конечно, кто-нибудь скажет, что "в те времена не было таких языков".
>Тут есть два варианта ответа:
>1) А почему не написали, раз все необходимые функции были известны?


>2) Tcl существует с 1988 года

Tcl это к питону.

> Кстати, mc ж вроже на slang написан?

И что ? Иногда именно хочется обьектов в С, что-же тут непонятного. Просто вам кажется это странным а мне - нет.

Изнакчально на ncurses, потом переделан на slang, одновременно были порты на tk и на его базе был создан gmc - gnome midnight commander.

>> А кто оплатит затраченное время?

> Я не вижу проблемы.

Значит у тебя много свободного времени(если ты энтузиаст) или у твоего начальника мнго денег(если проприетарный кодер(далеко не вся проприетарщина пишется на жавке)).

> С++ вообще был разработан не для проектирования GUI.

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

>> 2) Tcl существует с 1988 года

> Tcl это к питону.

Зачем? Чтоб от него делать биндинги к gtk(и ведь сделали, вот не жалко людям времени) ? В то время как у tcl имеется своя, наиболее удобная(ну естественно, имхо) гуевая библиотека tk.

>> Кстати, mc ж вроже на slang написан?

> И что ? Иногда именно хочется обьектов в С, что-же тут непонятного. Просто вам кажется это странным а мне - нет.

Мне кажется странным тратить время, силы и допускать места, вызывающие ошибки в то время, когда можно обойтись без этого. И только.

>далеко не вся проприетарщина пишется на жавке

Безусловно. Но java в данной конкретной описанной мною ситуации - оптимальное решение в плане соотношения время/затраты.

>Значит у тебя много свободного времени

Свободного времени у меня не так уж и много. Просто берешь и разрабатываешь GUI с использование милого сердцу тулкита. Если софтина получится стоящая, то пользоваться будут и кдешники, и гномеры, и др... Кроме фанатиков, конечно. Но на них вообще НИКОГДА ориентироваться не стоит.

>> Tcl это к питону
>Зачем? Чтоб от него делать биндинги к gtk(и ведь сделали, вот не жалко

Я к тому что к TCL надо подходить с меркой питона а C или C++.

>людям времени) ? В то время как у tcl имеется своя, наиболее удобная(ну
>естественно, имхо) гуевая библиотека tk.

Не понимаю что вы хотели тогда этим сказать. Поясните пожалуйста.

Вот как раз Питон/Tk связка очень популярна была в свое время. Как и вообще связка динамический_язык/Tk. Что не мешает сейчас использовать и связку Tcl/Gtk хотя это наверное никому не нужно.
Понимаете, одно дело когда язык работает только как часть платформы Tk/Tcl , и другое дело когда он растет над собой и используется независимо от своей изначальной среды.

>Мне кажется странным тратить время, силы и допускать места,
> вызывающие ошибки в то время, когда можно обойтись без этого.
> И только.

Потому что для некоторых задач это очень разумно. Одна из них - написание библиотеки(или ядра чего либо) с требованием языковой нейтральности. Так как задача под которую пишется библиотека(ядро) может быть удобна для решения ее в поле ООП.
И самое главное, кстати, что такой подход гораздо гибче. Даже линкуясь с glib вы можете во многом менять логику вашей объектной модели, как раз то что позволяют делать гибкие языки но не позволяет делать C++ и иже с ними. C++ не панацея. Это сейчас скорее ужас, он атски сложен - сколько там страниц в стандарте ? А как это поддерживается на уровне компиляторы других фирм/другие аппаратные платформ ? По общению с профессионалами я составил мнение что C++ это для тех кто "хочет" с этим боротся. А раз там надо боротся - то с таким же успехом можно боротся с C+glib. Так как C + glib это в общем просто. Так как glib это обычная C библиотека с высочайшем уровнем портабельности, практически с таким же как и сам С.

>> людям времени) ? В то время как у tcl имеется своя, наиболее удобная(ну естественно, имхо) гуевая библиотека tk.

> Не понимаю что вы хотели тогда этим сказать. Поясните пожалуйста.

Выкокоуровневая библиотека, без синтаксического мусора, с замыканиями/рефлексией и т.д. И всё "искаропки". Что ещё можно желать?

> Понимаете, одно дело когда язык работает только как часть платформы Tk/Tcl , и другое дело когда он растет над собой и используется независимо от своей изначальной среды.

Не понимаю. tcl(да и tk) легко, опять же искоробочно, интегрируются с подпрограммами на C, а следовательно, любом другом компилируемом языке.

>Мне кажется странным тратить время, силы и допускать места, > вызывающие ошибки в то время, когда можно обойтись без этого. > И только.

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

То есть gtk писался только для того, чтобы потом к нему прикрутить gtk++ и python? А вот сейчас ещё и моню прикрутили. А всё почему? Потому что _сложно_ писать на голых сях.

И кстати, платформенная библиотека для графики уже есть. Xlib. И зачем на неё настраивать прослойку на C, мне совершенно непонятно.

> Даже линкуясь с glib вы можете во многом менять логику вашей объектной модели, как раз то что позволяют делать гибкие языки но не позволяет делать C++ и иже с ними. Так как glib это обычная C библиотека с высочайшем уровнем портабельности, практически с таким же как и сам С.

Непортабельная она. Хотя бы потому, что Glib::ustring нельзя взаимозаменять с std::wstring.

Я лично пробовал использовать glib-based библиотеку(libxml++) в проекте на c++. Плевался, плевался, да и перешёл на Xerces.

> Чтоб от него делать биндинги к gtk(и ведь сделали, вот не жалко людям
> времени) ?

Поясняю. Gtk развивается, туда идут много разработчиков они на нем пишут проги, итп. То есть есть среда где много народу.
Tk/Tcl это место где сейчас сидят жестокие фанаты этой связки. По отдельности у них гораздо больше шансов привлечь "молодежь" чем вместе.
И на сколько я понимаю, фанатов просто Tk сильно больше связок Tcl/Tk. Потому что есть всякие Lisp/Tk и пр.

Надо понимать что для любого человека который думает что ему изучать одно дело когда он пытается копатся в TCl/Tk и видеть что это не популярно и другое дело писать на каком нибудь популяр6ном сейчас Руби, к которому кстати есть и Tk привязки.

На скаолько я понимаю Tcl как то "не попер". То есть в среднем при тех же массово используемых возможностях оказался более сложе/экзотичен.

>делать биндинги к gtk(и ведь сделали, вот не жалко людям времени) ?

Судя по тому, что под gtk биндингов больше, походу, делать их проще, чем биндинги под Qt :)

>То есть gtk писался только для того, чтобы потом к нему прикрутить
>gtk++ и python? А вот сейчас ещё и моню прикрутили. А всё почему?
>Потому что _сложно_ писать на голых сях.

НЕТ. Потому что тут возобладал подход поиска оптимальности в наборе язык-платформа-программер-задача где _заменяемость_ каждого элемента считается благом. В вашем подходе заменяемость каждого элемента считается ненужной.

То есть Gtk писался для людей которые хотят как Gtk/C так и Gtk/C++ так и Gtk/Питон , но так же и Tk/Питон или там Tk/C.
Любой выбор в этой модели считается хорошим а не плохим делом.

Мне иногда удобнее может быть не Gtk/C а просто С, без glib. А иногда C+glib

> Tk/Tcl это место где сейчас сидят жестокие фанаты этой связки. По отдельности у них гораздо больше шансов привлечь "молодежь" чем вместе.

Только вот самый навороченный jabber-клиент почему-то написан на этой фанатской связке. И векторный редактор sK1 -- тоже. И гуй для maxima-ы -- тоже, хотя и есть менее функциональный гуй wxmaxima. И scilab обладает tk-шным гуйком. И, скромно скажу, единственный в мире клиент для ЛОРа тоже написан на tcl/tk ;)

> На скаолько я понимаю Tcl как то "не попер". То есть в среднем при тех же массово используемых возможностях оказался более сложе/экзотичен.

Да, им надо уметь пользоваться. А "не попёр" он благодаря батьке Столлману. Уж очень он раскритиковал проект с bsd-like лицензией.

> Потому что тут возобладал подход поиска оптимальности в наборе язык-платформа-программер-задача где _заменяемость_ каждого элемента считается благом. В вашем подходе заменяемость каждого элемента считается ненужной.

Давайте заменим glib на qtcore. Ой, а почему сразу всё так сложно получается? Нет это заменяемости вне песочницы glib/gtk.

> В вашем подходе заменяемость каждого элемента считается ненужной.

Скажите это авторам tclX.

>Судя по тому, что под gtk биндингов больше, походу, делать их проще,
>чем биндинги под Qt :)

Не просто удобнее. В случае Gtk необходимость биндингов была изначальным требованием с определенного момента. Равенство языков для GTk считалась аксиомой. "Мы пишем тулкит так что им могут воспользоватся максимальное число языков".

В QT все наоборот - был C++ как основной язык. "Мы пишем GUI библиотеку для C++. Точка." Были другие языки третьего сорта на которые всем кроме горстки фанатов (не связанных особо ни с Trolltech ни с основной группой поддерживающей Qt) было плевать.

Не забывайте, это было время тотальной популярности C++ самих по себе.

>> делать биндинги к gtk(и ведь сделали, вот не жалко людям времени) ?

> Судя по тому, что под gtk биндингов больше, походу, делать их проще, чем биндинги под Qt :)

А это совершенно ничего недоказывает. Ковыряться в носу тоже проще, чем программы писать.

>Только вот самый навороченный jabber-клиент почему-то написан на этой
>фанатской связке. И векторный редактор sK1 -- тоже. И гуй для maxima-ы
>-- тоже, хотя и есть менее функциональный гуй wxmaxima. И scilab
>обладает tk-шным гуйком.

Стоп, стоп, стоп. :) sk1 это форк skencil (бывш sketch) который написан на Tk/Python. Я на него плагины кодил "подсебя(тм)" :)( и кстати очень бы хотел gtk версию :p, которую кстати начали делать много лет назат но сам проект "застыл" что и привело в появлению sk1 в первую очередь) Жаббер клиентов тьма. Они написаны на всех популярных тулкитах и языках. Гуи для максимы писали в те времена когда других популяных динамических языков особо и не было - максима древний
проект. Как и скайлаб.

То есть все что вы привели в пример попадает в графу "по историческим причинам". То что при отсутсвтвии Perl/Python/Ruby/whatever писать проще на TCL сомнения не вызывает - это динамический язык со всеми его привлекательными возможностями. Как раз привлекательными для написания Gui. И в те времена когда начали писать большинство указанного вами Gtk/Qt просто еще вообще не было. Так что в связке Tk/Tcl нечем было заменить ни одну из компонент :)

> И, скромно скажу, единственный в мире клиент
>для ЛОРа тоже написан на tcl/tk ;)

Вы чорный фанат этой связки - так и знал !!!! :)

> Жаббер клиентов тьма. Они написаны на всех популярных тулкитах и языках.

Но tkabber поддерживает больше всех XEP-ов (это не мат, это сокращение такое).

>> И, скромно скажу, единственный в мире клиент для ЛОРа тоже написан на tcl/tk ;)

> Вы чорный фанат этой связки - так и знал !!!! :)

Я белый! :)

> Но tkabber поддерживает больше всех XEP-ов (это не мат, это сокращение
> такое).

Но и пусть :)

Я за большую свободу. Gtk эту большую свободу обеспечивает и идет в этом направлении и дальше. Tk кстати тоже прекрасно линкуется с другими языками, хотя такой задачи не ставилось. Но разработчики видимо были пряморукие.

А вот QT ... :E :) Учитывая что не смотря на то что он на плюсах они еще и moc с собой таскают. Да это то же самое что какую нибудь vala с собой таскать и на ней все писать.

PS

Я хочу сказать что пока, похоже, человечество пошло именно
путем большей мультиязыковости/мультитулкитовости а не "один язык на все"- после C++ и Java. Которая под влиянием .NET пытается развиватся в сторону языковонезависимой платформы с поддержкой динамических языков.

То есть хотя для многих задач и можно использовать Яву(С++) там где сейчас ее не используют, тем не менее почему то этого не происходит.

Кстати если бы tkLOR писался во времена когда был расцвет Tk то на ЛОРе большинство "молодежи" кричала бы "пеши на C++ это для тру пацанов" :)

> Я за большую свободу. Gtk эту большую свободу обеспечивает и идет в этом направлении и дальше.

Мне так не кажется. По-моему, gtk углябляется в себя и решает свои внутренние проблемы.

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

Тогда придумывали языки не для скрейшей выгоды и написания пары шаблонных приложений, а для работы. На современные разработки без слёз смотреть нельзя: убогий точканет, ejb без подзапросов, qt, наплевавший на устройство x window system...

> Я хочу сказать что пока, похоже, человечество пошло именно путем большей мультиязыковости/мультитулкитовости а не "один язык на все"- после C++ и Java. Которая под влиянием .NET пытается развиватся в сторону языковонезависимой платформы с поддержкой динамических языков.

Угу, теперь не "один язык для всего", а "одна VM для всего". И это тоже не радует, потому что завтра эта супер-пупер-VM опять поменяется.

> Кстати если бы tkLOR писался во времена когда был расцвет Tk то на ЛОРе большинство "молодежи" кричала бы "пеши на C++ это для тру пацанов" :)

Да при мне уже кто-то пукнул в лужу, что лучше писать на qt ;) А пару лет назад кеш в формате mbox мне бы предложили заменить на труъ-реляционную базу :)

GTK+-2 тормозит жоско. НО! Попробуйте запустить xfce. На удивление, вся отрисовка происходит весьма быстро. Любопытно, как они такого добились?

>Попробуйте запустить xfce. На удивление, вся отрисовка происходит весьма быстро. Любопытно, как они такого добились?

IMHO theme-engine

От него очень сильно зависит скорость.

> Даже линкуясь с glib вы можете во многом менять логику вашей объектной модели, как раз то что позволяют делать гибкие языки но не позволяет делать C++ и иже с ними. C++ не панацея

Ай лолд хардли. Мужик ты когда с++ последний раз видел? В С++ есть очень мощная вещь шаблоны, которая позволяет крутить обьектной моделью как угодно и без лишних телодвижений. С++ - вообще единственый язык который одновременно позволяет писать эффективные программы без потери продуктивности.

ну нах, это говно куте себе еще устанавливать на машину лишь для того, чтоб доказать, что оно - говно

Народ, раскажите плиз для Ъ чем все закончилось?

> А вот QT ... :E :) Учитывая что не смотря на то что он на плюсах они еще и moc с собой таскают. Да это то же самое что какую нибудь vala с собой таскать и на ней все писать.

Тебя так напрягает эта консольная утилитка? ::))

> ну нах, это говно куте себе еще устанавливать на машину лишь для того, чтоб доказать, что оно - говно

Ну вот зачем с тобой общаться? Чтобы очередной раз доказать, что говно у тебя вместо мозга?

> Да при мне уже кто-то пукнул в лужу, что лучше писать на qt ;)

Думаешь работало бы хуже? ::))

> Ай лолд хардли. Мужик ты когда с++ последний раз видел? В С++ есть

Видел, видел шаблоны, не сомневайся. Когда я был таким же горячим пионером как ты и любил плюсы, потому что еще не знал ни о перле, ни о питоне не о многих других языках. Шаблоны тогда казались верхом мудрости. Но я с тех пор вырос, а в плюсы продалжали добавлять всякие крутые фичи. До сих пор это делают. А компиляторы С++ до сих пор пытаются их воплотить.

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

БУГАГА. Очень смешит "без лишних телодвижений" здесь. Особенно после этого интересно искать в таком коде ошибки. Так сказать занятие для настоящих мужчин.

> С++ - вообще единственый язык
>который одновременно позволяет писать эффективные программы без
>потери продуктивности.

БУГАГА. Нет, он не позволяет писать без потери продуктивности. Он позволяет это делать тем кто долго курил мануалы и всякие буки о том как правильно программировать на плюсах ломая себе мозг нагромождением концепций в одной куче - то есть специализированным и высококвалифицированным программерам. И дамаг нанесеный проекту человеком который не находится на высоком уровне, в случае использования всех этих плюсовых фишек,ужасен. C++ _сложный_. И это его _недостаток_. С которым можно мирится в некоторых случаях. когда это оправдано. Для прикладного ПО это не так. Это оправдано для определенных случаев вроде полусистемного-полуприкладнго ПО вроде броузера.

C++ это язык для фанатичной молодежи, btw иногда люди умудряются стареть не взрослея :). Которая не готова поступится юнышеским максимализмом и хочет всего и сразу, а именно "писать эффективные программы без потери продуктивности". На сложность таким юношам плевать - они же "Настоящие мужики(тм)".

Не расписывайся в том что не осилил, кресты сложны в том случае, если писать кривыми руками.

>Народ, раскажите плиз для Ъ чем все закончилось?

Флеймом. :)

О чём спорим-то? А то можа я пару словечков замолвлю.

> Не расписывайся в том что не осилил, кресты сложны в том случае, если писать кривыми руками.

Поддерживаю.

>> Да при мне уже кто-то пукнул в лужу, что лучше писать на qt ;)

> Думаешь работало бы хуже? ::))

А ты напиши, мой четырёхглазый друг( ::)) ), там посмотрим. Заодно и сравним.

> Ваши предложения?

Перепиши qt на gtk, а gtk на qt.