>Btw, if you have been following my posts on my blog and on the desktop-devel-list, you will know that my feeling is that all of the existing toolkits today (Gtk, Qt, XUL and VCL) will become obsolete and we need to start looking at the next generation toolkit system.

de Icaza в своем стиле :-)) Хотя, в данном случае он прав.

<IMHO> С одной стороны -- неудобный Gtk+/Gtk--, с другой -- GPL only Qt. Правда сделать что-то новое и при этом заставить всех это использовать будет проблематично :-)

Идеальный вариант, который всех устроит, это: язык -- C (хотя я и предпочитаю C++), *действительно* удобный враппер на C++ (не такой как gtk--), лицензия LGPL. При этом нужна прозрачная модульность (чтобы все было в одном пакете, который выходит единым релизом, но отдельные компоненты при этом самостоятельны и опциональны, насколько это будет возможно). И еще все это должно быть максимально легким :-) </IMHO>

Ух, размечтался я что-то ;-) А вы что на это скажете?

А если не техническое решение ? :) Novell покупает докучи еще и Trolltech и полностью открывает QT.

Как тебе такое решение ? :)

2anonymous (*) (30.03.2004 18:31:08):

>> с другой -- GPL only Qt
как всем и в т.ч. novell'у известно, Qt есть и коммерческая.
А уж у Новеля денег на несколько десятков лицензий Qt найтись
должно.

> *действительно* удобный враппер на C++ (не такой как gtk--),

И было бы неплохо, чтоб кто-нибудь сделал ещё и *действительно* удобный ОО-враппер для Qt.

>И было бы неплохо, чтоб кто-нибудь сделал ещё и *действительно* удобный ОО-враппер для Qt.

Объясните пожалуйста, чем вас так не устраивает API Qt? Только аргументированно.

А может - не надо? Пусть будут два мира - это же лучше для развития! Только пусть договариваются о стандартах на freedesktop.org - и будет всем щастье. Вариант третьего тулкита - несбыточный в своей сладостности.

>Объясните пожалуйста, чем вас так не устраивает API Qt? Только аргументированно.

Никто тебе этого не скажет :(
У фанов Гнома одни аргументы -
1. "Неправильная" лицензия
2. GTK быстрее
3. И вааще Гном рулез
Все остальные аргументы - комбинация этих трёх (большей частью последнего).
Посмотри здесь http://www.mycomp.com.ua/article.php?id=6491
имхо более-менее обьективная статья.

> Никто тебе этого не скажет :(

Правильно. На вопрос из разряда "почему у верблюда шея кривая" в двух словах ответить непросто.

> У фанов Гнома одни аргументы

Причем здесь GNOME?

Я не то, чтобы фан, но, в среднем, предпочитаю гном. Аргументы (кроме того, что он рулез) - совсем другие. Лицензия меня мало колышет (разве что "неприятный осадок" от начальной лицензии и от того, что коммерческий софт на Qt можно делать только платя троллям - но, повторяю, реально мне это по барабану). Скорости GTK и Qt уже давно сравнимы. Где-то быстрее одни, где-то - другие. Чего уж бороться за скорость когда иконки в svg:)

А вот что мне действительно нравится в гноме - это то, что его API - на С, а не на С++ (желающих побеседовать на эту тему приглашаю в тред "Novell подружит KDE и GNOME").

А статья действительно неплохая. Только автор не указал, что БАЗОВЫЙ Qt безусловно богаче БАЗОВОГО GTK - но при этом гном действительно включает массу библиотечек (включая ту же упоминаемую автором libxml), которые считаются частью платформы. Поэтому, например, утверждение, что gtk содержит хилые средства для xml - бессмысленно (gtk - только про виджеты, и не более того). В остальном - автор очень неплохо написал.

>Правильно. На вопрос из разряда "почему у верблюда шея кривая" в двух словах ответить непросто.

Это ты про Qt?? У нее очень стройный API, сравни его с действительно кривым GTK-- (я уж не говорю про чистый GTK+, хотя это скорее проблемы C).

> Это ты про Qt?? У нее очень стройный API, сравни его с действительно кривым GTK-- (я уж не говорю про чистый GTK+, хотя это скорее проблемы C).

Ну не надо сравнивать с бякой. Сравнивайте с действительно красивыми и удобными вещами.

P.S. У чистого GTK - довольно неплохой API.

>> У фанов Гнома одни аргументы

Причем здесь GNOME?

не ужели не причём?;)

И все забывают о реально универсальном API MFC, все остальные позорные подобия светлого образа единственно правильного пути!

В томто и прикол что не причем, сасет как обычно тихонько в сторонке

>А вот что мне действительно нравится в гноме - это то, что его API - на С, а не на С++ (желающих побеседовать на эту тему приглашаю в тред "Novell подружит KDE и GNOME").

По-моему это уже дело привычки. Я прекрастно понимаю людей, которые выросли на Кернигане и Ричи и просто не воспринимают ООП. Но мне кажется, что именно ООП прекрастно подходит для библиотек виджетов. Те же обьекты, свойства, методы. Единственное, чего не хватает в С++, это хорошего механизма обработки событий, ну дык QT своим механизмом сигналов и слотов полностью восполняет этот недостаток. Плюс огромное количество невиджетных классов. Для чего здесь нужен С, я не понимаю. Он видимо хорош для ядра, модулей, etc. А в GTK+, как я понял из статьи, реализовано некоторое подобие классов, только при помощи структур. Зачем, если есть С++?

> И все забывают о реально универсальном API MFC,

Как его забудешь :) Его ругают на протяжении десятилетий. Это уже традиция такая: проникся идеями ООД - не забудь поругать MFC.

А Qt-шники гордятся, что вот у них чуть-чуть получше чем в MFC :) Нашли, блин, с кем сравнивать.

> прекрастно

2 раза подряд? Это перебор.

> Я прекрастно понимаю людей, которые выросли на Кернигане и Ричи и просто не воспринимают ООП.

??? Интересно. Это, если не ошибаюсь, ответ мне. Так вот я прекрасно воспринимаю ООП и совершенно согласен с любыми восхвалениями ОО подхода в гуестроении (косвенным доказательством моей любви к ОО - достаточно долгая карьера в жаваписи). И моя претензия к Qt - не то, что он ОО (потому как GTK тоже ОО, и windows.h - тоже ОО, хотя и в меньшей степени). А то, что он С++. Не путайте, пожалуйста, это СОВСЕМ РАЗНЫЕ вещи.

Это не претензия к Вам. У сторонников С++ есть привычка свысока смотреть на любителей С с мыслью "Вам просто не понять всю красоту ОО". Так вот правда в том, что на С можно заниматься ОО программированием (разумеется, внешне выглядит это не так красиво и лаконично, как на С++). И, уверен, люди создавали ОО код на С до того как Страуструп разработал плюсы.

> вот что мне действительно нравится в гноме - это то, что его API - на С, а не на С++

сравни http://www.gtk.org/tutorial/ch-gettingstarted.html#SEC-HELLOWORLD и http://doc.trolltech.com/3.3/tutorial1-01.html Что красивее и понятнее выглядит? Хотя если говорить честно, что выбрать gtk_widget_show (window); и hello.show(); дело вкуса, лично мне больше нравится второй вариант.

pack [button .b -text "Hello world!"]

Я не буду, не буду, не буду (не обращайте внимания, это я себя уговариваю) по десятому разу заниматься доказательством того, что публичные API должны быть на С, а не на С++. Не буду, не буду, не буду...

У QT объектная модель слизана с SmallTalk. Им даже не хватило возможностей языка - пришлось делать препроцессор.

>публичные API должны быть на С, а не на С++.

Покажи лучше реализацию ООП на C? В GTK пародия на ООП :)

Определение ООП в студию, плиз. Основные составляющие и пр.

> Покажи лучше реализацию ООП на C? В GTK пародия на ООП :)

На С++ таких пародий написано больше в разы.

Не разжигай флейм, студент! Тебе объяснить или нет, что ООП - это не язык программирования, а идеология. Этой идеологии присущи некоторые свойства, такие как наследование, полиморфизьм и прочие изьмы! Все эти свойства реализованы в Glib. Если интересно - сам поищи.

Товарищу с примерами Hello World. Обрати внимание, что в Gtk+ еще и сигналы как-бы еще устанавливаются, а в примере с Qt этого нет. Да и комментариев там нет, поэтому код выглядит совсем маленьким. Использование Gtk+ не такое уж многословное. Но вот создание своих объектов (или виджетов) - дело куда более громоздкое... Тут в плане писанины явный проигрыш по сравнению с C++. Глупо спорить с очевидным.

>Я не буду, не буду, не буду (не обращайте внимания, это я себя уговариваю) по десятому разу заниматься доказательством того, что публичные API должны быть на С, а не на С++. Не буду, не буду, не буду..

А можна вкратце или ссылочкой - почему на С?

> А можна вкратце или ссылочкой - почему на С?

Чтобы можно было делать биндинги для всех языков, а не только для python.

http://www.linux.org.ru/profile/svu/view-message.jsp?msgid=511826 Вот, наверное, самая долгая дискуссия на ЛОРе на эту тему. Были, вроде, и другие - покороче. Опять же, мы неплохо пообщались про С++ с ANDI тут: http://www.linux.org.ru/profile/svu/view-message.jsp?msgid=515809

> Этой идеологии присущи некоторые свойства, такие как наследование, полиморфизьм и прочие изьмы!

Не хотелось бы влезать в воспитательный процесс, но _эти_ свойства (наследование, полиморфизм) - все-таки свойства ОО-языков, а не ООП в целом. К ООП они имеют такое же отношение, как, скажем, паттерн bridge (хотя я не удивлюсь, если завтра появится новый язык программирования, поддерживающий этот bridge на уровне синтаксиса).

Ладно, воспитательный процесс пОбоку. На карту поставлено большее. Что отличает ООный код от не-ОО? Теоретики, ау!:)

>Товарищу с примерами Hello World. Обрати внимание, что в Gtk+ еще и сигналы как-бы еще устанавливаются, а в примере с Qt этого нет. Да и комментариев там нет

Я заметил, только зачем это надо в HW? да и сигналы в Qt все равно выглядели бы компактнее. А на счет комментариев, для новичка удобнее разбор построчно, комментарии без подсветки трудно читать...

>Но вот создание своих объектов (или виджетов) - дело куда более громоздкое... Тут в плане писанины явный проигрыш по сравнению с C++.

вот об это я и говорю...

> Ладно, воспитательный процесс пОбоку. На карту поставлено большее. Что отличает ООный код от не-ОО? Теоретики, ау!:)

Ну тут же вполне определенно кто-то выразился: все, что написано на С++ - ОО, что на С - пародии и модули ядра. По крайней мере я так понял.

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

> >Но вот создание своих объектов (или виджетов) - дело куда более громоздкое... Тут в плане писанины явный проигрыш по сравнению с C++.

> вот об это я и говорю...

Но чем объясняется ужасный проигрыш Qt по сравнению с Tk? :)

>Ну тут же вполне определенно кто-то выразился: все, что написано на С++ - ОО, что на С - пародии и модули ядра. По крайней мере я так понял.

Неправильно понял!

ОО подход в C приходится реализовывать самому, по этому, например в GTK используют подходы похожие на ОО, но таковыми не являются.

> ОО подход в C приходится реализовывать самому,

Ну так и в С++ многое приходится реализовывать самому. ОО-средства С++ весьма скудны - вон приходится разные препроцессоры (дешёвые :)) писать.

> по этому, например в GTK используют подходы похожие на ОО, но таковыми не являются.

А вот как ты это определяешь, что похожи, но не являются?

Опять 5^2! Вы мне можете сообщить, чем отличается "похожий на ОО код" от "настоящего ОО кода"?

> Вы мне можете сообщить, чем отличается "похожий на ОО код" от "настоящего ОО кода"?

Человек, похожий на генерального прокурора, занимался с лицами, похожими на проституток, чем-то, похожим на секс! (c)

Может, надо ввести проверку на наличие диплома об окончании ВУЗа перед тем, как давать людЯм постить :>?

>2. GTK быстрее

Было быстрее. 1.2.х было быстрее любого QT.

Однако gtk 2.x.x пока что тормознутее.

>Определение ООП в студию, плиз. Основные составляющие и пр.

Марш читать Буча как прочтёшь возвращайтя поговорим

Не я, но:

--- брюзжание

>Ну так и в С++ многое приходится реализовывать самому. ОО-средства С++ весьма скудны - вон приходится разные препроцессоры (дешёвые :)) писать.

www.boost.org. signal library

>А вот как ты это определяешь, что похожи, но не являются? Зачем строить структурами наследование, а затем устанавливать вручную виртуальные функции? Это должен делать транслятор! И много чего ещё. Пока копался в Xine и mplayer, чуть не сдох. половина кода реализует c++.

в kdesdk есть модуль - qtc. Биндинги qt на C.

--- крылья, крылья, главное - хвост!

Сохдание GUI на компилируемых языках - вам не кажется странным? Если код скрывать не надо? На сайте KDE'шников лежит сравнение kde и gtk (игра knotski по-моему). Там победила PyQt. Зачем супер-пупер-быстрая GUI программа? Backend - да, должен быть быстрый. Юзим Gtk, Qt, WxWidgets, ... Логику-то нахрена туда же? Проблем с памятью мало? А для скриптовых языков нет никакой разницы, C интерфейс или C++. Пишите wrapper на C++ в стиле C :-)

Part 1

Так просто валялось в нете :))

Первого Января 1998 года Bjarne Stroustrup давал интервью журналу 'Computer'. Вообще-то редакторы предполагали, что он расскажет о семи годах объектно-ориентированного программирования с применением языка, который он и разработал. К окончанию беседы выяснилось, что интервьюер извлек больше информации, чем предполагал, и, естественно, редакторы решили урезать содержание 'для пользы индустрии', но, как обычно получается в таких случаях, произошла утечка информации. Вот полный и нередактированный протокол интервью - это не похоже на обычные запланированные вопросы/ответы. Вам наверняка покажется это интересным.

Интервьюер - далее И., Stroustrup - далее C..

И. Прошло несколько лет с тех пор, как Вы изменили мир разработки программного обеспечения. Что Вы теперь чувствуете, оглядываясь назад?

C. Вообще-то я думал об этих днях как раз перед тем как Вы приехали. Помните - все писали свои версии 'C', и проблема была в том, что все это делали чертовски замечательно. Университеты тоже чертовски замечательно преподавали этот язык. Это привело к понижению компетенции. Под 'компетенцией' в данном случае я подразумеваю феноменальность. Вот что породило проблему.

И. Проблему?

C. Да, проблему. Помните когда все писали на Cobol?

И. Конечно, я тоже это делал.

C. Hу вот, в начале эти ребята были как боги. Им платили кучу денег и относились как к королям.

И. Да уж, вот это были времена...

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

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

С. Точно. То же самое случилось и с программистами, писавшими на 'C'.

Part 2

И. Понятно, ну и что же Вы все-таки хотите этим всем сказать?

C. Однажды я сидел у себя в оффисе, и мне пришла в голову небольшая идейка, как хоть немного восстановить баланс. Я подумал: интересно, что произойдет, если будет язык программирования такой запутанный и такой сложный для изучения, что никто бы уже не сможет заполнить рынок толпой программистов, пишуших на этом нем? У меня уже были тогда кое-какие мысли по этому поводу. Вот, знаете наверно, X10 и X windows. Это тогда была такая графическая система, которая работала на Sun 3/60. У нее были все ингредиенты, которые мне были нужны - комплексный синтаксис, сложные для понимания мрачные функции, псевдо объектно-ориентированная структура. Даже сейчас никто не пишет напрямую под

И. Шутите?

C. Hичуть. Есть еще одна проблема. Unix был написан на 'C' - это значило то, что любой программист, пишущий на 'C', мог очень легко стать системным программистом. Помните сколько обычно зарабатывали большинство системных программистов?

И. Да, я же ведь тоже этим занимался.

С. Так вот, этот новый язык должен был отделять себя от Unix путем скрывания всех системных вызовов, которые так здорово связывают 'C' и Unix. Тогда ребята, знающие только DOS, тоже смогли бы прилично зарабатывать.

И. Hе верится в то, что Вы это сказали...

С. Это уже происходит достаточно долго, но вроде сейчас большинство людей уже уяснили для себя, что C++ - это пустая трата времени, но должен сказать, что осознание этого происходило дольше чем я ожидал.

И. Hу расскажите поточнее, как же Вы все-таки сделали это?

C. Это была просто шутка, я никогда не думал, что люди воспримут эту книгу всерьез. Любой человек, даже с половиной мозга, может понять что объектно-ориентированное программирование интуитивно, нелогично и неэффективно.

И. Что?

С. И относительно 'повторно-используемого кода' - Вы когда-нибудь слышали, чтобы хоть одна компания 'повторно-использовала' что-либо?

Part 3

И. Hу, вообще-то не слышал, но...

С. Вот так-то. Hекоторые, кстати, пытались. Была такая компания из Орегона - Mentor Graphics, в которой просто заболели тем, что пытались переписать все что можно на C++ в '90 или '91 году. Я на самом деле им сочувствовал, но думаю, что люди по крайней мере, научились чему-то на их ошибках.

И. Очевидно у них ничего не вышло?

С. Вообще ничего. Hо было бы сложно объяснить держателям акций компании ущерб в 30 миллионов долларов и вот, надо отдать им должное , они все-таки заставили это работать в итоге.

И. Так все-таки у них получилось? Это доказывает что 'объектное-ориентирование' работает.

C. Почти. Запускаемый файл получился такой огромный, что загружался 5 минут на рабочей станции HP со 128Mb оперативной памяти. Я думал, что это станет камнем преткновения, но это никого особенно не заботило. Sun и HP были очень рады продавать до ненормальности мощные ящики с огромными ресурсами для выполнения на них тривиальных программ. Знаете, когда мы в AT&T откомпилировали нашим первым компилятором C++ программку 'Hello World', я не мог поверить своим глазам: запускаемый файл получился размером 2.1Mb.

И. Да уж... Hо компиляторы с тех пор прошли долгий путь.

C. Вы так думаете? Попробуйте тот же пример 'Hello World' с последней версией g++ - вы получите примерно пол-мегабайта. А кроме этого есть еще множество примеров со всего мира. У British Telecom чуть было не возникли большие проблемы, но к своему счастью они вовремя догадались свернуть проект и начать все заново. И им больше повезло, чем Australian Telecom. А теперь я слышал, что Siemens cоздает какого-то динозавра и все больше и больше волнуется по поводу размера того, что у них получается. Hе правда ли забавно смотреть на это всеобщее заблуждение?

P 4

И. Да, но C++ -то, в общем, вполне нормальный язык.

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

И. Я должен сказать, что совершенно сбит с толку всем что Вы сказали. Вы сказали что сделали это для того, чтоб повысилась оплата труда программистов. Hо это же бессмыслица.

С. Hе совсем так. У каждого есть его выбор. Я не предполагал, что все это так выйдет из-под контроля. Hо все-равно, практически все у меня получилось. C++ cейчас уже умирает, а труд програмистов продолжает нормально оплачиваться - особенно тех, кто имеет дело со всей этой чепухой - вы же понимаете, что невозможно использовать эффективно большой программный модуль на C++ , если не вы сами его написали.

P 6

И. Hо есть различные программные инструменты...

С. Большинство из которых написаны на C++.

И. Если мы опубликуем все это, то Вас просто могут линчевать, понимаете ?

C. Сомневаюсь. Как я сказал C++ уже уходит в прошлое. Hи одна компания без предварительного тестирования теперь не начнет проект на C++, а если будет тестирование, то они поймут, что это путь к неудаче. Если не поймут - то так им и надо. Знаете, я пытался убедить Dennis'a Ritchie переписать Unix на C++.

И. О Боже. И что же он сказал?

C. К счастью у него присутствует хорошее чувство юмора. Я думаю и он, и Brian понимали что я тогда делал. Он ответил, что может мне помочь написать версию DOS на C++, если я захочу.

И. Hу и как? Вы захотели?

С. Я написал DOS на C++. Могу дать вам demo. Она у меня работает на Sparc 20 в другой комнате. Просто летает на четырех процессорах и занимает всего то 70 мегабайт на диске.

И. Hа что же это похоже на PC ?

С. Вы, очевидно, шутите. Видели же вы Windows'95 ? Я о них думаю как о своем величайшем успехе.

И. Знаете, эта идея насчет Unix++ заставила меня задуматься. Ведь где-то может сидеть парень, которому придет в голову сделать это...

С. Hо не после того, как он прочитает это интервью.

И. Я сожалею, но врядли мы сможем опубликовать даже часть этого интервью.

С. Hо это же история века. Я просто хотел чтоб мои приятели-программисты помнили меня за то, что я для них сделал. Знаете как сейчас оплачивается программирование на C++ ?

И. Последнее, что я слышал - настоящие профессионалы зарабатывают $70-80 в час.

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

И. Имеете ввиду, что раньше Вам C++ не нравился?

С. Hенавидел его. Он даже выглядит неуклюже, вы не согласны? Hо когда стали там выходить разные книги... вот, тогда-то я и увидел полную картину.

И. Погодите, а как насчет ссылок? Вы подтверждаете что улучшили указатели 'C' ?

С. Хмм. Я и сам не знаю. Вообще я думал, что да. Потом я как-то говорил с парнем, который писал на C++ с самого начала. Он говорил, что не мог запомнить были ли ссылки на его переменные или нет, поэтому он всегда использовал указатели.

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

С. Пообещайте мне, что опубликуете это.

И. Я извещу Вас, но мне кажется, что я знаю, что скажет мой редактор по этому поводу.

С. А все-равно, кто этому поверит? Кстати, не могли бы вы мне прислать копию этой записи?

И. Это я могу.

нафиг нафиг. из вузов порой такие имбецилы выходят. в нашем выпуске из 30 человек только 2-ое включая меня разбирались в программировании, той специальности на которой учились. а потом такое чмо вордовое залазит на форумы и типа раз у него диплом то он типа умный

>Марш читать Буча как прочтёшь возвращайтя поговорим

запарили ! не ну сколько можно !! ненавижу !!! :) вот иди сам и читай : http://www.planetpdf.com/mainpage.asp?WebPageID=620 svu - respect; p.s. мое мнение : C++ - только в обетрки годиться...

_iV_

>>>публичные API должны быть на С, а не на С++.

Публичных API для toolkit'ов ваще быть не должно
Интерпретатор + текстовая форма графического интерфейса (как в tk). Никаких проблем с новыми биндингами (максимум четыре-пять функций нужно портировать). А что GTK, что QT - пока обертки под все хедеры напишешь - ипанутся можно.