Релиз Qt 4.5 и Qt Creator 1.0

> gimp и так вроде разбит здорово: один фильтр - один плагин (программа) ;)

Но пользователь этого не замечает. В этом и весь смысл. Пользователь, если по хорошему, не должен видеть кишков программы и как они между собой взаимодействуют. Пользователю нужен готовый полноценный продукт. А как внутри реализована модульность: плагинами на динамических библиотеках или отдельными программами - это уже на выбор разработчиков как им проще делать.

> Алё, Вы хоть работали программером хоть чуть-чуть? Все большие проекты именно так пишутся. :) Что на C, что на C++.

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

>Да ничего страшного не было б, если б сделали на "няшном С". Подумаешь, макросами заменили бы кой-чо.

История не терпит сослагательного наклонения, пора бы уже это понять

> А можно в Qt Creator подцепить свой компилятор (например arm-linux-gcc) и отлаживаться в целевой системе (с помощью gdb server)? Кто-нибудь знает? А то глючная code::blocks уже достала.

Qt Creator я не пробовал. И то и то точно умеет eclipse+cdt.

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

AutoCAD :)

Насчет фреймворков на C - мне вот интересно почему llvm на C++ написан? Вроде ничего не предвещало, в том числе и главный спонсор.

>Новые фичи, например. Ну и чем меньше кода, тем меньше багов, конечно же.

Не проще ли уже С++ использовать и не велосипедить

Для меня самое важное это LGPL. Далее, обещанный нативный вид Qt приложений в Gnome и отрисовка через GTK+ - вот что важно так же.

>Конкретнее....

Ну тогда и пример нужно брать конкретный. Вот, если бы GIMP писали на Qt, то время, сэкономленное на написании гуя можно было бы потратить на CMYK и 16 бит :)

>Ну, это все так по молодости считают. :)

Чисто теоретически, конечно, но чем больше мест, где можно ошибиться, тем больше и будет ошибок, не так ли ?

Еще новый линкер (gold который) на С++ пишется, и работает, сцуко, в 5 раз быстрее ld, который C-only. Хотя щас набежат плюсофобы и начнут визжать, что быть такого не может в принципе, и что это все "засланные казачки" в команде binutils течении многих лет замедляли ld своими патчами, - подождем этих чудаков =)

кажется в треде остались только плюсофилы и нейтральные

>>Конкретнее....

>Ну тогда и пример нужно брать конкретный. Вот, если бы GIMP писали на Qt, то время, сэкономленное на написании гуя можно было бы потратить на CMYK и 16 бит :)

Ну так напишите... Вы хоть представляете трудоёмкость такого переписывания? ;) Гораздо дешевле поддерживать уже написанное решение... Не верите мне? Верьте фактам - посмотрите на 4-е кеды. Несмотря на то что КДЕ является в принципе весьма неплохой оболочкой (в т.ч. по задумке), амбициозно-революционно настроенные разработчики попытавшись претворить свой замысел в жизнь оттолкнули довольно большое количество пользователей. Не согласны?

>Чисто теоретически, конечно, но чем больше мест, где можно ошибиться, тем больше и будет ошибок, не так ли ?

Не в этом дело...

Напомню Вам вашу фразу:

"Ну и чем меньше кода, тем меньше багов, конечно же."

Так вот - это не так. Чем меньше кода, тем легче отыскать баги, но и то далеко не всегда. :)

>Еще новый линкер (gold который) на С++ пишется, и работает, сцуко, в 5 раз быстрее ld, который C-only.

И что это доказывает?

> это Вы погорячились... чем он так уж лучше std::string? ;)

по крайней мере тем, что работает с юникодом

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

Оттолкнули от _перехода_ с привычного [.*] на kde4 - да, но это временно, т.к. по мере выхода новых версий число пользователей kde4 будет только расти

>И что это доказывает?

Что плюсы могут быть гораздо быстрее Си, в умелых руках

>AutoCAD

Нифига себе мелкие утилиты...

> плюсы могут быть гораздо быстрее Си, в умелых руках

Справедливости ради, если бы ld _переписали_ на Си, он был бы не медленнее gold; и gold поддерживает отнюдь не все форматы, поддерживаемые ld. Так что данный пример ничего про скорость не доказывает.

>>Вот, если бы GIMP писали на Qt

>Ну так напишите... Вы хоть представляете трудоёмкость такого переписывания? ;)

Ощутите разницу, я предположил "если бы писали", переписывать я не предлагал, потому с

>Гораздо дешевле поддерживать уже написанное решение..

согласен.

>Так вот - это не так. Чем меньше кода, тем легче отыскать баги, но и то далеко не всегда. :)

Я отталкивался в своем высказывании от того, что "в среднем на 1000 строк кода приходится от 1 до 10 ошибок или уязвимостей", соответственно куда вероятнее что в 2000 строках ошибок будет больше, чем в 1000, хотя это и не обязательно.

>И что? Геморрой, при более или менее профессиональном программировании (большие проекты) - Вам всё равно обеспечен. Просто уровень людей пишущих программы должен быть повыше. :)

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

>> это Вы погорячились... чем он так уж лучше std::string? ;)

>по крайней мере тем, что работает с юникодом

хорошо.... std::wstring? :)

>Так что данный пример ничего про скорость не доказывает.

Вообщем-то да, но тогда

>Справедливости ради, если бы ld _переписали_ на Си, он был бы не медленнее gold; и gold поддерживает отнюдь не все форматы, поддерживаемые ld.

почему ld не переписали на Си? :)

>Оттолкнули от _перехода_ с привычного [.*] на kde4 - да,

а именно вопрос наследования является определяющим для большинства пользователей...

>но это временно,

ну-ну... и сколько это временное уже тянется, посчитаете, или так подсказать?

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

пока голословно

> почему ld не переписали на Си? :)

Потому что при выборе между Си и Си++ только фанатики и ниасиляторы выбирают Си. Очевидно же.

>Нифига себе мелкие утилиты...

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

>Что плюсы могут быть гораздо быстрее Си, в умелых руках

и обратное тоже справедливо, и что?

>Ощутите разницу, я предположил "если бы писали", переписывать я не предлагал, потому с

Хорошо, давайте с этой точки зрения: предположим, что написали GIMP на Qt... и что изменилось бы?

>Я отталкивался в своем высказывании от того, что "в среднем на 1000 строк кода приходится от 1 до 10 ошибок или уязвимостей", соответственно куда вероятнее что в 2000 строках ошибок будет больше, чем в 1000, хотя это и не обязательно.

Это в среднем, а программисты (если конечно не клинические индусы), порой очень творческие личности со всеми вытекающими... :)

>Хорошо, давайте с этой точки зрения: предположим, что написали GIMP на Qt... и что изменилось бы?

То, что на написание GUI было бы потрачено меньше времени и его можно было потратить на пресловутый CMYK.

>Это в среднем, а программисты (если конечно не клинические индусы), порой очень творческие личности со всеми вытекающими... :)

Оно-то так, но в случае GUI никакого особого творчества нет и быть не может.

>а именно вопрос наследования является определяющим для большинства пользователей...

да, сижу на 3.5.10 и не жужжу

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

планирую перейти на kde4 этим летом

>пока голословно

это только до лета =)

>и обратное тоже справедливо, и что?

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

Как раз на днях выложил на никсп обзор Qt Creator из "Open Source" (от Qt-разработчика): http://www.nixp.ru/articles/qt_creator_review

>>Если вы из Украины, то поинтересуйтесь, чему учат программистов в компьютерной академии "ШАГ".

>"Академия" "Шаг" - то ещё говно, да.

+1 нет чтобы в нормальных ВУЗах учиться.

>Для меня самое важное это LGPL. Далее, обещанный нативный вид Qt приложений в Gnome и отрисовка через GTK+ - вот что важно так же.

Отрисовка через GTK+???? Нафиг надо? Взять нетормозной тулкит и сделать отрисовку через GTK+?

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

То что автор шел таким длинным путем а не написал сразу на python+gtk показывает что КГ/АМ.
Так как если автор не болен любовью к низкоуровневым языкам и Оптимизации ГУИ, то достаточно легко понять какие программы уже сейчас можно сразу писать на питоне(руби, похапе, итп) а какие все таки нужно писать на C/C++
Тогда и можно было бы сравнить python+gtk с python+qt что бы сделать какие либо выводы. И в крайнем случае, если уж приложение получилось не достаточно быстрым, переписать мелкие куски на С. Найдя профалером узкие места.

>кажется в треде остались только плюсофилы и нейтральные

Дык кроме сву плюсофобов вроде не было.

>Отрисовка через GTK+???? Нафиг надо? Взять нетормозной тулкит и сделать отрисовку через GTK+

Не совсем так, рисует сам Qt, но подхватывает GTKшную тему.


Кстати, где можно посмотреть сравнение производительности Qt и GTK, желательно посвежее ?

>Не совсем так, рисует сам Qt, но подхватывает GTKшную тему.

Тогда я не против)

>Кстати, где можно посмотреть сравнение производительности Qt и GTK, желательно посвежее ?

+1 сам хочу поглядеть. Когда-то на ЛОРе проскакивало, но снова найти не смог.

> почему ld не переписали на Си? :)

А зачем это делать прямо сейчас ? Что бы на лоре смогли сравнить gold с ld2.0 ???

gold это такой экспериментальный проект. Которые делают люди с особенным шилом в заднице. Люди с подобным шилом, исследуют те или иные концепции и для этого периписывают ld на лиспе, хаскеле эрланге и с++. когда они эти концепции исследуют, ничего не мешает написать реализацию их алгоритмов и методов на C.

Помните, С точно не подходит для прототипирования того или иного рода.

> gold это такой экспериментальный проект. Которые делают люди с особенным шилом в заднице.

AFAIK, это внутренний линкер Гугла :)

По принципам toolchain построено очень много программ, вообще говоря все что проектировалось в определенный момент времени.
Из значимого -
Patran/Nastran, Ansys и их аналоги, в том числе более мелкие,
тяжелые 3d пакеты типа Maya,
инженерные пакеты типа солидворкс,про-инженер(итп) .

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

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

> AFAIK, это внутренний линкер Гугла :)

Это не противоречит тому что я сказал. У гугла (как и микросфта..) полно проектов типа той же СМингулярити или IronPython. Гугл просто более интеллектуально развитая компания, она их еще и использует :p

Им же ничего не мешает использовать линкер на Схеме, например , правда ? :)

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

Муха-ха-ха-ха
Быдлокодер детектед

Тузик не нужен, адназначна! С этим никто не спорит! Зачем слушать мне каких-то там Битлз и Deep Purple если есть более мощный, гламурный и популярный дима еблан?

Ы-ы-ы
Да уж, давно так не ржал, ы-ы-ы-ы... Монструозный Qt... Моно... Ы-ыы... Кто-нить, пристрелите меня, пока не лопнул ))))))))))))))))))))))))))))))))))))))))))))

>Кто-нить, пристрелите меня, пока не лопнул

Торжественно пристреливаю. Тех, кто ведется на такие провокации даже в моей клинике не лечат.

>Им же ничего не мешает использовать линкер на Схеме, например , правда ? :)

Может быть его отсутствие? Может всё таки они не спроста выбрали с++, деньги считают везде (кроме госконтор), так что не без причин.

По сабжу. ОООЧЕНЬ пропёр QWebView. Ой как его не хватало... Завтра буду разбираться как к нему флешь прикручивать. И заюзаю наконец его в планировщик своего "Ынтерпрайз"-проекта ))). А, и ещё карту наконец то прикручу на нём. А то юзера просят...

> Торжественно пристреливаю. Тех, кто ведется на такие провокации даже в моей клинике не лечат.

Спасибо, поржал ещё ))))))))))))))))))

>Кстати, где можно посмотреть сравнение производительности Qt и GTK, желательно посвежее ?

КуТэ сравнивать не с ГТК а с GTK+Cairo+Pango+... Да и то мало, например с чем сравнвать QGraphicsView и еже с ним - это, между прочим, тоже важный компонент.

>> AFAIK, это внутренний линкер Гугла :)

> Это не противоречит тому что я сказал.

Это противоречит словам "gold это такой экспериментальный проект. Которые делают люди с особенным шилом в заднице".

> Им же ничего не мешает использовать линкер на Схеме, например , правда ? :)

Неправда.

>Хорошо, давайте с этой точки зрения: предположим, что написали GIMP на Qt... и что изменилось бы?

На написание GTK было грохнуто куча ресурсов, если бы их все сосредоточили на ГИМП - имели бы наверняка нечто сильно отличное.

> Может быть его отсутствие?

Отсутсвие ЧЕГО ? Линкера на c++ тоже не было пока они его не написали.