|
| 1.2, Аноним (-), 18:54, 21/09/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +6 +/– |
Ура, товарищи! Это очень хорошая новость. На сегодня это, пожалуй, лучший тулкит для рисования пользовательского интерфейса!
| | |
| |
| 2.4, Sunder (ok), 18:58, 21/09/2010 [^] [^^] [^^^] [ответить]
| +5 +/– |
 Скорее лучший тулкит для написания кроссплатформенных приложений на C++ :)
| | |
|
| |
| |
| |
| 4.13, User294 (ok), 20:17, 21/09/2010 [^] [^^] [^^^] [ответить]
| –3 +/– |
 >Ниасилятор-любитель autocrap?
Autocrap по крайней мере по минимуму является шеллскриптом. Который нуждается для своего запуска аж в шелл-интерпретере, не более. Который более-менее везде есть как правило. А cmake надо для начала сам компилить в случае если не повезло. Очень хотелось, ага. Два раза аж. Не говоря о том что тесты свойств платформы и детект библ и прочая в cmake довольно кривые и глючные. Автокрап за годы его юзания допилили и он более-менее сносно работает более-менее везде, на разных конфигах (да, блин, мир не кончается на вашем сраном i386 писюшнике с более-менее распостраненной операционкой и компилером). Поэтому его можно просто взять и поюзать, с минимумом шансов найти приключения на свой зад. А вот как cmake работает, особенно в случае когда условия чуть отличаются от идеала - полная Ж. Оно зачастую при обрушении даже не может внятно пискнуть - а чего собственно не хватило/сломалось. Знаете, когда я билдую программу - я вовсе не хочу в детективные расследования играть. По идее система автоконфигурежки+билдования и должна меня отфутболить если у меня чего-то не хватило или там еще не так. Иначе на кой хрен она вообще нужна? С детективными расследованиями я могу и руками компилеру команды вхреначить, наконец! Поэтому лично мне CMake не слишком нравится. Гемора с ним много.
| | |
| |
| 5.15, аноним (?), 20:37, 21/09/2010 [^] [^^] [^^^] [ответить]
| +5 +/– | |
> Autocrap по крайней мере по минимуму является шеллскриптом. Который нуждается для своего запуска аж в шелл-интерпретере, не более. Который более-менее везде есть как правило. А cmake надо для начала сам компилить в случае если не повезло.
Для Qt надо компилить qmake, вообще-то. А "аргумент" ваш тут уже неоднократно обсуждали - и что толку что нужен только шелл, когда возьмите несколько десятков пакетов с конфигурями (а на средней системе их несколько сотен), и эти конфигури будут и занимать на порядок больше, и выполняться в сумме дольше, чем сборка cmake. Не говорю уже о затратах времени maintainer'ов на патчинг этих конфигурей под свой дистрибутив, и о том, что autocrap-это такой феерический п**ц что очень часто приходится патчить configure.in/Makefile.am, и тогда понадобится вся помойка автотулзов, m4, либтулов и прочего.
> Не говоря о том что тесты свойств платформы и детект библ и прочая в cmake довольно кривые и глючные.
Я на FreeBSD никаких проблем с ним не встречал - CMake это единственное что способно собрать там софт вообще без патчей и даже без указания каких-либо аргументов (а для configure как минимкм CPPFLAGS/LDFLAGS обязательны всегда).
Дальше отвечать не на что - бредятина от человека толком не знающего ни cmake ни autotools, без примеров и аргументов. Либо ниосиляторство, либо анальная обида из-за того, что cmake не gnu.
| | |
| |
| 6.24, аноним (?), 23:14, 21/09/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>CMake это единственное что способно собрать там софт вообще без патчей
сейчас договоримся, что патчи - это нифига не функционал/заплатка/этк, а фича ауто...что там пушут местные?
| | |
| 6.38, Noor (ok), 11:49, 22/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
 >Для Qt надо компилить qmake, вообще-то.
Ага, для простых приложений. А если надо собрать еще и несколько библиотек? А если надо сделать так, что бы эти библиотеки собирались только тогда, когда их нет в системе? И еще куча условий...
| | |
|
| 5.18, Stax (ok), 21:39, 21/09/2010 [^] [^^] [^^^] [ответить]
| +6 +/– |
 Ага, а теперь возьмите винду, поставьте туда шелл (ну цигвин тот же или еще что) и попробуйте запустить результат autocrap. Что, взлетело?
autocrap'у помимо нужна туева хуча зависимостей: всякие grep/sed/awk/cp/mv/touch/etc, куча мелких posix утилит, куча больших posix утилит - при некоторм изменении обстоятельств вам придется пускать autoreconf/aclocal/иже с ними, значит вам нужны: perl, m4, и далее по списку. Все эти утилиты должны нормально работать, не вносить своих глюков (что далеко не всегда реально даже на unix-системах). autocrap это просто такая веревка для связывания большой кучи костылей начиная от make'а и шелла и заканчивая перлом и огромной куче прог, без которых вся эта система не работает.
Для сборки cmake-проекта вам нужен.. только cmake. (Ну, и компилятор/линковщик наверное). Почувствуйте разницу.
| | |
| |
| 6.21, аноним (?), 22:22, 21/09/2010 [^] [^^] [^^^] [ответить]
| +1 +/– | |
make еще. Но в целом вы правы.
И да, кстати, cmake генерирует makefile гарантированно совместимые и с GNU и c BSD make. autocrap почти никогда. Так что +gmake. А cmake кроме мейкфайлов умеет проекты под кучу DE, что также незаменимо. И при желании генератор можно подо что угодно написать - на то он и cross platform. autocrap такому не научится никогда, потому что костыль на костыле.
| | |
| 6.32, Аноним (-), 05:43, 22/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
зачем вы мечете бисер перед свиньями (распинаетесь перед усером и прочими удодами)?
| | |
|
| 5.36, Вова (?), 10:49, 22/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
>А вот как
>cmake работает, особенно в случае когда условия чуть отличаются от идеала
>- полная Ж. Оно зачастую при обрушении даже не может внятно
>пискнуть - а чего собственно не хватило/сломалось. Знаете, когда я билдую
>программу - я вовсе не хочу в детективные расследования играть. По
>идее система автоконфигурежки+билдования и должна меня отфутболить если у меня чего-то
>не хватило или там еще не так. Иначе на кой хрен
>она вообще нужна? С детективными расследованиями я могу и руками компилеру
>команды вхреначить, наконец! Поэтому лично мне CMake не слишком нравится. Гемора
>с ним много.
то же самое мог бы написать. Вообще если бы не желание собираться в отдельной от сорцов директории я бы использовал просто гнушный мейк, по подобию сборки андроида.
| | |
|
| 4.22, Вова (?), 22:32, 21/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
в qt нет автотулс (1)
И шелл-скрипт быстрее и лучше чем компиляция нужной версии симейка (2)
| | |
| |
| 5.29, аноним (?), 02:30, 22/09/2010 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> И шелл-скрипт быстрее и лучше чем компиляция нужной версии симейка
Нет.
| | |
| |
| 6.37, Вова (?), 10:51, 22/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
>> И шелл-скрипт быстрее и лучше чем компиляция нужной версии симейка
>
>Нет.
умно.
| | |
|
|
|
|
| 2.11, Sunder (ok), 19:37, 21/09/2010 [^] [^^] [^^^] [ответить]
| +/– | |
Имеется в виду среда разработки QtCreator с поддержкой CMake или сборка с помощью CMake самой Qt ?
Первое я ещё понять могу, хотя изучив формат pro файло и qmake понял что и так всё отлично собирается на всех платформах.
А зачем второе, никак не ясно :)
| | |
| |
| 3.16, аноним (?), 20:38, 21/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Первое я ещё понять могу, хотя изучив формат pro файло и qmake
>понял что и так всё отлично собирается на всех платформах.
>А зачем второе, никак не ясно :)
Затем что пора менять штатный qmake на гораздо более функциональный cmake.
| | |
| |
| 4.23, Sunder (ok), 22:48, 21/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
Зачем менять хорошо работающую систему, интегрированную с Qt, если она и так выполняет всё что от неё требуется ? Правильно, незачем.
| | |
| |
| 5.30, аноним (?), 02:30, 22/09/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
>Зачем менять хорошо работающую систему, интегрированную с Qt, если она и так
>выполняет всё что от неё требуется ? Правильно, незачем.
Зачем было KDE переводить на CMake, когда были мегабайты "работающего" autocrap? Правильно, незачем.
| | |
| |
| 6.42, _Bulgarin (ok), 01:13, 23/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
 >Зачем было KDE переводить на CMake, когда были мегабайты "работающего" autocrap? >Правильно, незачем.
Нда, заклинило на средствах сборки...
| | |
|
|
| 4.25, anonymous (??), 23:37, 21/09/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Затем что пора менять штатный qmake на гораздо более функциональный cmake.
О, Боже... Любая "необычная" (в кавычках --- потому что это всё, что не уложилось в кошерный вариант от авторов CMake) --- и вагон разборок с CMake internals неизбежен. Autotools, впрочем, предоставляют не меньше возможностей для решения проблемы "как наиболее бездарно потратить время на уговаривание сборочных тулзов таки сделать то, про что ты отлично знаешь ЧТО сделать и КАК сделать".
| | |
| |
| 5.31, аноним (?), 02:34, 22/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
Вы пробовали "что-нибудь необычное" на autocrap написать? Попробуйте как-нибудь. Наши требования на cmake получилось реализовать в 8 раз меньшим по объему кодом и гораздо более понятным, я уж не говорю о базовой функциональности cmake, которой в autotools не было и не будет. Начиная хотя бы с ctest и cpack.
| | |
| |
| 6.35, аноним (?), 10:38, 22/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
"что-нибудь необычное" - это когда надо задней правой переднее левое почесать?
нафига писать необычное? пишите обычное. обычное не значит плохое. просто соответствующее стандартам разработки и общим для платформ, и в частности для каждой.
| | |
| 6.39, anonymous (??), 12:42, 22/09/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Вы пробовали "что-нибудь необычное" на autocrap написать?
Да.
> Наши требования на cmake получилось реализовать
> в 8 раз меньшим по объему кодом и гораздо более понятным,
> я уж не говорю о базовой функциональности cmake,
И CMake'ом я тоже занимался.
> которой в autotools не было и не будет.
Обе вещи идеологически довольно близки друг другу. Унифицированность действий неискусного (скажем так) сборщика --- может даже плюс. Но когда я, разработчик, кучу времени (== т.е. много больше, чем собственно решение задачи) трачу на поиск того, как заставить сделать эти тулзы (равно как и CMake) то, что я хочу (== мне нужно) сделать --- то довольно быстро я выкидываю эту назойливую 'автоматизацию'.
Опять же, обе эти системы превносят дублирование базовых механизмов и не уменьшают (а наоборот --- увеличивают) количество требуемой информации. Ср. LD_LIBRARY_PATH/ldd и pkgconfig + libtool + ... .
| | |
|
|
|
|
|
| 1.5, ТТТ (?), 19:00, 21/09/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Ну слава богу а то мне казалось что покупка нокией тролтека похоронит КТ
Ура товарищи!!!!!!!!!
| | |
| |
| 2.12, mine (ok), 19:47, 21/09/2010 [^] [^^] [^^^] [ответить]
| +4 +/– |
 Как это не странно, но Нокия ведет себя совсем иначе нежели Оракл (чтоб он сдох)...
| | |
| |
| 3.14, User294 (ok), 20:24, 21/09/2010 [^] [^^] [^^^] [ответить]
| +6 +/– |
Если нокия похоронит Qt, следующим шагом вероятно похоронится сама нокия. Потому что симбиан, особенно без кутей - ну никак не потянет конкуренцию с адроидами, ифонами и чем там блин еще. Вот что-то типа MeeGo + Qt могло бы стать весьма могучей штукой. Кстати есть такое ощущение что нокиевцы заткнулись и втихаря довольно ударно пиляют, стиснув зубы. Так, глядя на их вакансии...
| | |
| |
| 4.26, Ariel (ok), 00:09, 22/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
 >>динамически создавать пользовательский интерфейс с помощью QML
Зачем???? Все эти языки описания интерфейсов, спец библиотеки на c++, если ещё двадцать лет назад в NeXT осознали, что GUI нужно не писать, но создавать с помощью визуального редактора. Интерфейс полностью отделён от остальной программы и представляет собой файл с сериализованными объектами. В чём они будут храниться - не важно, text или xml или binary. Известный пример - nib.
Неужели, все значения объектов после сборки программы с Qt интерфейсом тупо hardcode in? Или они загружаются из файла с ресурсами?
| | |
| |
| 5.27, X (?), 00:35, 22/09/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Неужели, все значения объектов после сборки программы с Qt интерфейсом тупо hardcode in? Или они загружаются из файла с ресурсами?
На выбор программиста. Вполне возможно второе.
| | |
| 5.28, Anon (?), 01:03, 22/09/2010 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>NeXT осознали, что GUI нужно не писать, но создавать с помощью визуального редактора.
"The Qt Quick Designer is a visual editor for (simple) QML files. We started work on it a looong time ago. In its current state it is unfortunately not yet the Uber-Editor we once imagined, but it is of use for quickly prototyping things. You can for instance take a gimp2qml tool we’re working on to quickly generate .qml files out of GIMP, and then do the final layout in Qt Quick Designer. (Yes, we’re also looking into directly exporting stuff from other tools than GIMP ;) )"
http://qt.gitorious.org/qt-labs/gimp-qmlexporter
| | |
|
| |
| 5.41, Школьник (ok), 21:30, 22/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
 http://habrahabr.ru/blogs/mobiledev/104744/
---
Исполнительный директор Nokia высказал отношение компании к платформе Android
Почему Nokia не выпускает устройства на базе Android? Потому что софт от гугла предоставляет кратковременное решение, которое будет «у руля» очень недолго — сказал исполнительный директор.
---
Если Нокиа перейдет на Андроид, то как она будет выдерживать конкуренцию со всякими китайцами? Хотя этот вопрос остается открытым и без перехода на Андроид.
| | |
|
|
|
|
|
