Довольно смешно, но каждый должен заниматься своим делом. Юмористы из программеров неважные.

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

имхо если писатть программы правильно: интерфейс отдельно, работа отдельно, то порт на новую библиотеку виджетов будет совсем несложным...

Re:

2 г-н Ключеня: "а в попугаях я гораздо длиннее". Если человеку охота посравнивать виджетсеты, то, насколько я понимаю, языки должны быть, гхм, одного уровня. Хоть бы gtkmm для смеху бы взял :-)

Как справедливо указано в новости - сравнение лищь затронуто,

Скорее всего статья лишь описывает портирования с gtk c на PyQT

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

Есть много критериев по которым это можно сделать - допустим
трудоёмкость, скорость выполнения...

Можеть кому-нибудь это поможет выбрать язык/виджет при
написании очередной программы

Sorry за очепятки

1. "... на протяжении этого исследования я старался оставаться нейтральным, насколько это было возможным... "

Не очень-то похоже.

2. "Один из бывших разработчиков Gtk-- ( привязок C++ для Gtk ) Гуиллаум Лаурент ( Guillaume Laurent ) сейчас с успехом использует Qt/KDE."

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

3. "И напоследок, Qt более развит, чем Gtk. Qt уже не один год обладает теми возможностями, которые были реализованы в последних версиях Gtk: уникод, двумерная графика ( canvas ), XML, потоки и т.д. "

Непонятно зачем сравнивать муху со слоном.. Почему нигде не было упомянуто о gtkmm, gtk2 ? Последние версии gtk это он про 1.4 ? Qt обладает не один год теми же возможностями - это qt3 что ли ? Конкретизировать надо, а не письками меряться.

P.s. Пардон за очепятки :) И самое главное, что забыл автор упомнять - о распространнености qt и gtk, если без первого можно обходиться, то насчет второго я не уверен.
Да и про скорость автор тоже забыл упомянть, хотя не "забыл", а возможно просто не захотел.

Юникод и графика в Qt почти со старта, XML, потоки во 2-й со старта... Без тоже gtk живут и не напрягаются (очень субъективно, насчёт его распространённости)... Что там ещё?

Насчёт "в попугаях длиннее" :-) Если я лично возьмусь сравнивать, :-) т.к. вообще ни ухом не рылом в gtk.... :-) То получится ещё длиннее :-)

Если кто хочет аналогичного типа статью написать, типа "gtk ... - рулёз qt не может этого" - только с реальностями, а не пробелами в знаниях "аЦтоя qt" - милости прошу :-) Только features такой появится, я думаю, в qt 3.1... 3.2... - если вещь стоящая...

> Да и про скорость автор тоже забыл упомянть, хотя не "забыл", а возможно просто не захотел.

А что про скорость говорить? Про нее уже давно сказано...
http://www.kde.org/announcements/k3c-announce.html

А, так статья написана всерьез?

Глядя на сравнения:

числа символов(!) и числа строк в исходниках
использования '_' или стиля "пьяного наборщика"
размера бинарника (при наличии динамической линковки!)

и других столь же серьезных вопросов трудно воспринимать всерьез какое-либо обсуждение "gtk vs qt" на kde-сайте.

Получилася обычный флейм,и я таки в него влез! Потому как раз я тот кто собирается выбрать инструментарий, которым удобно пользоваться под Линух. Рассуждать на эту тему можно много и спорить тоже. Я еще не написал ничего (под Линух!) кроме "нело ворлд" и то на qt. Пока решал свои проблемы перлом, реболом и жабой. Но надо и серьезным вещам приобщаться.

Почитал я доку про ЖТК - в принципе мне понравилось, но реально существующие программы (Гном и др.) огорчают меня своей явной сыростью. При переходе на Лин я был уверен, что буду работать исключительно с Гномом и ЖТК, так как они более ориентированы на десктоп (ИМХО), но обжогся - глюки зависоны и др. Перешел на КДЕ2.2 - не без глюков но работает стабильней и нет проблем с руссификацией.

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

Конечно, элемент "несерьёзности" имеет место быть - а как же иначе, от угрюма даже кони дохнут :-). А то что на сайте КДЕ, так что, вы хотите - чтобы мы собирали там инфу по принципу: "КДЕ-КуТя АЦтой"? :-) тогда доменное имя было-бы notKDE.ru :-) Флейм флеймом, но в любом утверждении есть доля смысла. Возьмите какое-либо приложение КДЕ, и попробуйте сделать аналогичные пассы в сторону gtk - pyGTK -убеждён, сайт gnome.ru с удовольствием опубликует результаты.
ИМХО, разработчик должен иметь возможности горизонтальной миграции, этот перевод - показывает путь, а уж кому и как поступать, на чём писать или просто метель гнать на ЛОРе :-) это его, сугубо личное, дело...
Лично, не очень знаком с gtk, но когда-то пытался поработать с ним - и не шибко был в восторге, теперь - работа с UTF8 для локалей в 2 и 3-4 символа вгоняет в дрожь :D - поэтому даже не смотрится в ту сторону. :-)
А обсуждение Qt vs ... приветствуется, только задумайтесь "что в Qt не так" - находится очень мало и весьма поправимо.

>Без тоже gtk живут и не напрягаются
>(очень субъективно, насчёт его распространённости)...

Пардон, а gimp, xmms, gkrellm, mozilla(первое что в голову приходит) мы уже не пользуемся, про mc который требует glib мы тоже забыли ? Интересно, насколько лучше им альтернативы на qt :)))

Я не скажу что я ярый фанат GNOME, нет, он мне вообще не нравится, впрочем как и KDE, но gtk я использую, а вот qt у меня просто нет необходимости использовать.
Да, я видел qt'шный designer - вещь довольно приятная.

>А что про скорость говорить? Про нее уже давно сказано...
>http://www.kde.org/announcements/k3c-announce.html
Молодой(?) человек, у Вас с английским всё впорядке ?
Там было только одно предложение, касающееся кое как темы разговора, и то про скорость тем для КДЕ:

"Theme developers should prefer KDE2's native widget theming which yields superior results both in terms of quality and speed."

Сравнений по скорости между GTK и QT там даже и не пахло.
BTW, как я уже упоминал про того самого "разработчика", на его сайте он долго флеймил по этому поводу, в конце он всё-таки пришел к выводу, что GTK C быстрее, чем QT C++.
На довольно небыстрых компьютерах хорошо заметно даже на глаз с какой скоростью открываются приложения qt и gtk.

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

>Глядя на сравнения: >числа строк в исходниках >... >и других столь же серьезных вопросов

Это один из _важных_ факторов, по которым можно сравнивать различные подходы.

>но хотелось бы поглубже и по серъезней

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

>Молодой(?) человек, у Вас с английским всё впорядке ?
>Там было только одно предложение, касающееся кое как темы разговора,
>и то про скорость тем для КДЕ:

However, while GTK themes are displayed faster and more efficiently than even native GTK itself, we do not recommend using this format for creating new themes.

А вот что по этому поводу говорят на сайте Gnome:

http://mail.gnome.org/archives/gnome-devel-list/2000-July/msg00246.html

> BTW, как я уже упоминал про того самого "разработчика", на его сайте он долго флеймил по этому поводу, в конце он всё-таки пришел к выводу, что GTK C быстрее, чем QT C++.
На довольно небыстрых компьютерах хорошо заметно даже на глаз с какой скоростью открываются приложения qt и gtk.

Как жаль, что этого не заметно на быстрых компьютерах :)
Не путайте скорость загрузки со скоростью отрисовки.

>http://mail.gnome.org/archives/gnome-devel-list/2000-July/msg00246.html

"They are trying to say "gtk pixmap engine is slow" in a press-release kind of way..."

И всё-таки тут не говорится про сравнение скорости qt vs gtk :)

>Как жаль, что этого не заметно на быстрых компьютерах :)
>Не путайте скорость загрузки со скоростью отрисовки.

На быстрых компьютерах тоже можно уловить разницу, взять к примеру kmail vs sylpheed-claws, конечно, не самое лучшее сравнение, но если sylpheed-claws открывается просто влет, т.е. невозможно уловить, что он там начинает загружаться, то kmail можно уловить, что она грузится ~0.3-0.7 секунды.
Скорость отрисовки в gtk на _мой_взгляд_ тоже быстрее.

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

Have a nice day.

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

1) Закладку никто и не нашел?

2) 2 asoneofas
Хотелось бы разумной( а не как в гноме) модульности.

>Пардон, а gimp,
Допустим, им не пользуюсь....

>xmms, gkrellm, mozilla(первое что в голову приходит)
Кроме 2-го (не знаю просто такого) - остальные живут и без гтк, кроме того - есть альтернативы

> мы уже не пользуемся, про mc который требует glib мы тоже забыли ?
> Интересно, насколько лучше им альтернативы на qt :)))
При чём тут mc и его альтернативы на qt? Без mc можно жить, а файлоползалок кроме него полно...

>Я не скажу что я ярый фанат GNOME, нет, он мне вообще не нравится,
> впрочем как и KDE, но gtk я использую, а вот qt у меня просто нет
> необходимости использовать.
С этого и надо было начинать :-) Это дело вкуса, и кол-ва платформ, под которые пишите.

>BTW, как я уже упоминал про того самого "разработчика", на его сайте
> он долго флеймил по этому поводу, в конце он всё-таки пришел к
> выводу, что GTK C быстрее, чем QT C++.
Вопрос так и остался более чем спорным, тем более в рамках последних веяний. Насколько помню, спор закончился, типа: "С++ более подвержены неоптимальности компилятора".. Что-то типа того...

> На довольно небыстрых компьютерах хорошо заметно даже на глаз с
> какой скоростью открываются приложения qt и gtk.
С подгруженной qt-mt не заметно. Да и в гноме тоже не особо (про КДЕ - отдельная песня).

Насчёт скорости открытия приложений КДЕ в КДЕ - это вопрос отдельный и уже много раз мусоленный, тем более Qt тут абсолютно непричём...

Насчёт разумной модульности. Народ в рамках кутопии, а также некоторые коллеги для своих целей, "били" библиотеку Qt, для того, чтобы не было монолитного файла разделяемой библиотеки. Насколько это хорошо? Не знаю. Всё равно, в рамках embedded системы пришёл к выводу (сугубо личное мнение) что разбивать помимо того, что исключается директивами конфигурирования - смысла нет. Максимум к чему прибегал - это выделение плагинов.

Тут спорили насчет скорости ... Может комп у меня какойто не такой или руки кривые?? Но конкверор работает быстро и стабильно, чего про наутилус не скажеш. Последний стартует на много медленние, а когда он отрисует мне каталог с несколькими сотнями файлов я так и не дождался. Комп селерон 416, 128мб сраму, тнт2 м64 altlinux junior 2.0 руками ничего не дорабатывал.