Программирование с Qt : Часть 3. Контейнеры

А в Qt все диалоги нативные.....

У вас ник - как бы комментарий... Шучу. Я так не думаю, просто круто получилось.

Ок, верьте или нет, то у меня дед в Москве, я ему винду когда то ставил. Он фотограф и работает с фотками. Тогда фотошопа у меня не было, я отвык от кряков. Я ему поставил Гимп, Опен офис, мплеер и Гугл Пикасу. В итоге он привык очень быстро. И диалоги не пугали аж ниразу.

Теперь у него нетбук с линпусом. Купил недавно. А там все кривое и он полетел. Что бы не костылить установку ХР на нетбук, я ему туда Убунту 9.04 залил. Человек, кроме более нового интерфейса особо разницы в работе не заметил. Только пикасу не ставил, ибо костыль на Линуксе. Он работает только с фотками, так еме FSpot и GIMP идеально подходят. Никакого плача.

В Java тоже не все нативное. А когда не нативное, то переход между платформами абсолютно безболезненный. Если там на винде бы Clearlooks или Human, то потом в Линуксе с этими темами особо не просвещенные могут даже не заметить «той фундаментальной разницы». Ну гуи системы чуть другое, ну и фиг. Зато проги привычные.

На ХР вышеперечисленные красивее нативных. На семерке и висте можна и их, и имперсонатор винды (WIMP). И то, и то нормально

>> Он фотограф и работает с фотками.

Если он риальнэ фотограф - ему как минимум RAW-конвертор ещё нужен. Под Линуксом их, к сожалению, нет. Есть dcraw (вроде как), но выдаваемые им фотки по сравнению с DPP похожи на говно.

FSpot

Тут вообще ноу комментс, убогое поделие на дотнете.

Кстати, не подскажете, как заставить все gtk-приложения подхватывать родные для меня KDEшные файловые диалоги? А то Qtшные проги, запущенные в gtk-окружении, почему-то подхватывают это убожество, а вот gtkшные, запущенные в kde - не подхватывают. Абыдно, однако!

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

>если захочу свое детище продать что мне скажет нокия?

Ничего не скажет! Вы можете продавать свой продукт использующий Qt, да еще и под любой вам удобной лицензией!

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

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

Это раньше непонятки с лицензией были, щас - всё понятно. И ещё вопрос - почему же они в свои дистры моно пихают, где непоняток риальнэ ЗНАЧИТЕЛЬНО больше?

Какие там у Qt непонятки с лицензией? GPL+LGPL

«Непонятка» была одна — нельзя было использовать Qt в закрытых проектах, но такая проблема есть с любым GPL кодом. На этот счет у Qt была вторая лицензия. Кстати даже сейчас лицензирование у Qt более гибкое чем у GTK. Например я не могу статически линковать gtk или как угодно перехарачить под себя и не поделиться изменениями. А с Qt я могу делать что угодно если куплю лицензию.

> гном более свободен. если захочу свое детище продать что мне скажет нокия?

Если ты следуешь LGPL, то ничего не скажет.

итак, подведем итоги:GTKшники позорно слили

Долго я искал пруфлинк, но так и не нашёл. В общем я где-то читал, что коммерческое использование когда-то KDE было затруднено из-за старой лицензии Qt, логика была типа «раз так, значит и Qt используется в коммерческих целях, придётся вам за него заплатить»

> В общем я где-то читал, что коммерческое использование когда-то KDE было затруднено из-за старой лицензии Qt,

KDE под LGPL всегда был. Qt до версии 2.0 шла под несвободной лицензией (исходники доступны, но изменять их не разрешалось без разрешения TrollTech).

раз так, значит и Qt используется в коммерческих целях, придётся вам за него заплатить

Не было такого никогда. GPL версия Qt накладывала ровное тоже ограничение, что и накладывает ЛЮБАЯ GPL либа. Когда ты её используешь, то ОБЯЗАН лицензировать свой проект под GPL. Никаких ограничений насчет коммерческих целей не было и нет.

> итак, подведем итоги: GTKшники позорно слили

Ушли работать. Отвечать на глупые вопросы типо а почему ГТК не юзает КДЕ диалоги, когда до того обьяснили почему не юзает Windows диалоги? Начинать feature-battle? Фича за фичу? А какой смысл? Одна платформа имеет философию комбайна, потому что за ней мегокорпорация и надо пересадить разработчиков только на нее. Другая имеет философию unix-way. Не имеем сравнения никакого и не можем его иметь. Уже такое было. Человек сказал что кто то юзает libcurl, libpcre, ему сделали замечание что оно не имеет оношение к Gtk. Так блин конечно не имеет.

Комбайн/unix-way. Оба подхода с недостатками. В одном случае имеем велосипеды, которые явно слабее спец либ. Хотя нормально интегрированы. В другом случае надо искать фичу в библиотеке номер 115. Просмотрев до того все 114 либ. Я лучше это сделаю, когда буду прогу писать, а не для того что бы тут доказать что-то каким-то ребятам. Тем более не доказать, а просто услышать в ответ «Какое это имеет оношение к gtk?»

Мне лично в Qt нравится их главная IDE. Удобно для Qt, вполне удачно для даже не Qt приложений. На гноме нет и не может быть такого, так как нет цельного фреймворка. Есть выбор сотен спец либ. Классический подход, сборка тоже православная - autotools. В итоге все IDE - общего назначения. Просто редакторы с функциями работы с Autotools и другими системами сборки.

Моно - целая платформа, не разбитая на кустки. Результат - монодевелоп вполне цельное IDE. Только с mono известные проблемы. Вот его и сливают. Гном 3 не будут переделывать на эту платформу. И призывают ее лучше не юзать вообще.

> В общем я где-то читал, что коммерческое использование когда-то KDE было затруднено из-за старой лицензии Qt...

А я где-то читал, что у разработчиков KDE и Trolltech была договоренность насчет лицензионной политики.

http://www.kde.org/whatiskde/kdefreeqtfoundation.php

>> раз так, значит и Qt используется в коммерческих целях, придётся вам за него заплатить

Не было такого никогда. GPL версия Qt накладывала ровное тоже ограничение, что и накладывает ЛЮБАЯ GPL либа. Когда ты её используешь, то ОБЯЗАН лицензировать свой проект под GPL. Никаких ограничений насчет коммерческих целей не было и нет.

А как было во времена Qt < 2.0?

еще пара лет и это непортабельное говно мамонта под названием autotools отправится туда же куда и относительно недавно ушел cvs

кстати kde нормально работает и по вендой и это говорит многое

Это было больше 10 лет назад и сейчас уже никто не помнит. А какая тебе разница? И так очевидно, что проприетарщикам нужна более слабая лицензия. Если бы Qt была бы под BSD, то проприетарщики положили бы на gtk.

«Зри в корень» К.Прутков.

Вообще то спор идет от личный предпочтений к DE. К обьективизму тут далеко. Я например могу ровно 5 страниц рассказывать почему Qt лучше g-stack. Потому что это гигантские крутые платформы с функционалом, который вряд ли кто то осилит на 100% и нечего брызгать слюной и орать «ниипет». Вот те 1000 хакеров - молодцы, а вот те 1000 хакеров - лузеры, которые не знают таблицу умножения. Вы в своем уме?

И еще зная Qt, и не зная Gtk, глупо защищать актуальность и нужность своих знаний, закапывая конкурирующий продукт. Относиться нужно с пониманием, а не с религиозной фанатичностью. Ищите сильные, слабые стороны. Если вы коммитер одного из тулкитов, улучшайте слабые стороны. А думать что платформы, на которых построены DE с миллионами строчек кода и почти везде равной поддержкой новых технологий, можна «закапывать» - безразсудство

Ясно. Спасибо за ликбез =)

> Я например могу ровно 5 страниц рассказывать почему Qt лучше g-stack

И кстати почти это и рассказывал. В одном учебном документе я писал, что Qt4 является одной из наиболее совершенных платформ в мире. Гтк я вспомнил фразой «Еще для переносимого построения GUI существует другая платформа. В силу того что на разработку проэкта отведено мало времени, а учасники не обладают опытом работы с этими платформами, то Gtk был отклонен. Причиной поступило то что Gtk требует более подробного изучения и имеет весьма нетривиальные (не похожие на то что до этого вам известно) методы построения GUI, в часности таблиц. На Qt методы будут более привычные и похожие на то, что вы встречали во время разработки для Windows»

> еще пара лет и это непортабельное говно мамонта под названием autotools отправится туда же куда и относительно недавно ушел cvs

Хохохо.

Слить мантру ./configure; make; make install??? Смело, смело. Дерзайте. (Только не говорите такого часто на ЛОРе, хорошо?)

А так реально я пробовал перейти на вещь попроще. Далеко ходить не надо, cmake хорошая альтернатива. Не осилил одну вещь. Как там корректно подключить любую либу. Вот я придумаю что угодно: gnutls, libpurple. Назвал просто так. Как подключить? Там кажется не всегда есть конфиги для любой либы из головы. А если нет, то написано поставить с программой. Выбило из равновесия... Есть пкг-конфиг поддержка, так его во всех платформах можно юзать?

pkg-config тоже непортабелен.

Решать также как и с configure. Если автоматом не находится, то ты говоришь configure --with-libblahblah=path

Для cmake соответственно cmake -DLIBBLAHBLAH_HOME=path

Проблем не вижу.

Если мы говорим о Unix, то проблем у pkg-config нет абсолютно никаких. Если мы говорим о особенном Unix - MacOS X, то я не готов вступить в дискуссию, так как не знаком с метотами разработки на этой платформе. Если говорим о Windows, то даже не трогая Cygwin, pkg-config работает в MSYS, что может послужить вполне приличной платформой для компиляции Windows версий приложений, который изначально разрабатывались на Unix.

Единственное отличие, которое я вижу в CMake - возможность генерировать проэкты для не GNU-like компиляторов, например MSVS. Но проэкты в этой среде и так разрабатываются только для Windows и зачастую не предназначены для работы в других системах. Я искал в Cmake более простые команды построения файлов сборки. Я их не нашел, так как они были не совсем консистентны. В этом случае qmake - более совершенный инструмент. По крайней мере я не сталкивался с проблемами, которые не решались в qmake, может они и есть. Мне qmake не всегда подходит, так как в моем понимании подразумевает наличие всей плафтормы Qt и не распространяется отедельно.

По большому счету платформа Win меня не сильно интересует, разве что только компиляции моих Linux приложений, когда это нужно и возможно. Подготавливаю виртуальную машину для сборки. Думаю что в будущем разберусь подробнее и буду кросскомпилировать в Linux с помощью mingw для Linux. Minimalist GNU for Windows for Linux - мило )))

Тем более что вышеописаный процесс нужен крайне редко. Когда я знаю что приложение будет работать в Windows, то иду более надежным, быстрым и простым путем. Пишу его на Java. Все проблемы снимаются одним махом. Потом запускаю с ключами -client -Xbatch. Имеем near native speed, small memory footprint. Главное не запускать с ключами по умолчанию )))

Только с если есть очень обьективные причины писать на С/С++ и надо продемонстрировать работу на Windows, то только тогда нужно проходить вышеописаные шаги.

Был на вокзале, покупал билеты. Там была или DOS или (вдруг) ncurses программа. Компы ужасные. Вспомнил одну игрушку для geek'ов. Она была более как proof of the concept. Вряд ли кто то влил бы денег. Но меня поразило.

Дело в том что Gtk 99% времени работает через GDK. So does Cairo. Никаких больших ожиданий и предсказаний о свойствах экрана Gtk не имеет. Люди сделали Cursed GDK, Cursed Gtk Theme. Фак, оно заработало без иксов и без фреймбуффера!!!

http://zemljanka.sourceforge.net/cursed/screenshots/demo_rozdily.png

Я был поражен. Просто подумал сколько софта можна портануть на терминал. Быстро бы розочарован, так как Cursed Gtk не получил поддержки разрабов и там очень старая версия. Выпущена в 2003. Конечно нельзя было ожидать Cairo в ascii-art ))) и тем более Pango, но концепт поразила. Мораль: не все что закопано надо было закапывать. Хотя бы ради интереса.

cmake генерит файлы сборки под родную среду компиляции на всех платформах, на венде никакой msys и cygwin для этого не используется.

да, в cmake можно сделать так

if (NOT WIN32)
ищем с помощью pkg-config
endif (NOT WIN32)

если не нашли используем пути, заданные руками в настройке

Я искал в Cmake более простые команды построения файлов сборки.

Простые команды для чего? Куда уж проще cmake? Сущность у нас одна, а не зоопарк из autoconf/automake/autoheader/autoblah ......

Существует gnt, на котором написан finch. Все «окна» подозрительно повторяют gtk-версию

>То моё предыдущее приложение специально не процитировали? =)

---> взаимодействие с самой системой <--- это всякие Windows-Unix-итд-специфичные вещи. По моим субъективным ощущениям, при работе с ГТК в этом плане свободы гораздо больше

Лять, что за бред? Кто мне может помешать использовать Windows-Unix-специфичные вещи в программе на Qt и как может быть «больше/меньше свободы»? Подключил инклюд, слинковался - работай. К примеру, я спокойно юзал Unix Sockets, а в виндовом проекте на самой первой работе - виндовые mailslots.

Ты уверен, что хорошо понимаешь, о чём говоришь?

>а когда из винды успели вырезать поддержку POSIX?

Эм.... а ты пробовал юзать тот «POSIX»? %)))

Ya, Это мои субъективные ощущения =)