Qml или qtgui

QtGui юзать. Не могут они его просто так выкинуть.

У нас тут планируется написать одну серъезную программу

есть новомодный Qml

1. имхо слегка взаимоисключающие вещи - серьёзность и новомодность

2. насколько Вам нужны моднявые «прибамбасы» qml? составьте список чего Вам не хватает в QtGui, обоснуйте для себя необходимость применения этих возможностей

3. дизайнеры, как правило, любят свистелки-перделки прикручивать, а вот корпоративные пользователи использовать - не очень

я боюсь, как бы в будущем(в qt5, например) не загнули qtgui и оставили один Qml.

долго же Вы собираетесь писать ПО :)

PS выкидывание QtGui - это последнее о чём бы я беспокоился в таком проекте

Под QML придется с нуля делать почти все виджеты, во всяком случае пока не доделают Qt Components, которые на данный момент делают для маемо, емнип.
Кроме того придется забыть про то, что программа будет вписываться в окружение, что не есть плохо, если разрабатывается какая-нибудь игрушка, очередной медиаплеер или что-то еще, чему может потребоваться «стильный уникальный дизайн».

Как уже сказали - QtGui останется в Qt навсегда. В QML присутствует заметный оверхед по использованию ресурсов памяти и процессора, кроме того он полностью основан на векторой графике, что в случае сложных форм вылезет тормозами.

сырой, непроизводительный и вообще не предназначен для чего-либо кроме just4fun

У вас верный ход мыслей. К плюсам можно отнести стабильность и простоту кода.

QML сейчас не позиционируется как технология альтернативная QtGui. Т.е. параллелей в этом плане с WinForms и WPF нет. Как уже написали здесь - кучу виджетов придется писать с нуля. Посмотри стандартные демки - там нет ничего сложнее flikr и twitter-клиентов, где из интерфейса одно поле ввода, да кнопка, а весь упор сделан на визуализации пришедших данных с анимацией и эффектами.

> кроме того он полностью основан на векторой графике

А можно пруф?

>> кроме того он полностью основан на векторой графике

А можно пруф?

Пруф здесь: $QTDIR/src/declarative/*. Конкретно GUI-часть QML'я это чистый GraphicsView, из которого наружу вытянуты координаты с плавающей точкой, опции сглаживания, цвет с альфа-каналом, матрица трансформаций. Стоит ли говорить, что на сложных сценах программый рендер векторной графики захлебнётся по сравнению с растровым. Справедливости ради стоит заметить, что такой подход даст преимущества на аппаратно ускоренной графике. При программом рендере грамотное обращение с формой также позволит снизить оверхед, давая рендеру возможность кешировать результат и выключать линейную фильтрацию.

Не знаю не знаю насчет производительности, у меня qml быстрее рисовал сложные штуки, чем стандартный QPainter, юзаемый в QWidget'ах.

Я в курсе, что QML использует Graphics View, а вот то, что последний это векторная графика, для новость. Где про это прочитать?

> у меня qml быстрее рисовал сложные штуки, чем стандартный QPainter, юзаемый в QWidget'ах

Чудес не бывает. Под капотом QML использует тот же QPainter, разница в отсутствии накладных расходов на инициализацию QPaintDevice - в QML всё рисуется на одной поверхности, флагах оптимизации, выключенном по-умолчанию клипе и так далее. Грубо говоря, перекос как в одну, так и вдругую сторону будет сильно заметен при неверном использовании инструмента.

> Я в курсе, что QML использует Graphics View, а вот то, что последний это векторная графика, для новость. Где про это прочитать?

Внимательно прочитайте документацию по базовым классам: QGraphicsItem и QGraphicsScene, включая QGraphicsItem::GraphicsItemChange и QGraphicsItem::GraphicsItemFlag.

>Стоит ли говорить, что на сложных сценах программый рендер векторной графики захлебнётся по сравнению с растровым

А кто заставляет использовать программный рендерер? Более того, какой современный компьютер не имеет аппаратного ускорителя?

> А кто заставляет использовать программный рендерер? Более того, какой современный компьютер не имеет аппаратного ускорителя?

Вот и получается, что программа на QML со временем попросту откажется работать на компьютерах без OpenGL, а это огромная доля рынка. Да и аппаратно ускоренный движок в Артуре всё ещё в экспериментальной стадии с кучей артефактов. Я за рациональное использование растровой и векторной график где они нужны.

Зато openGL рендер в QML таки лучше работает, чем в QWidget'ах

>Вот и получается, что программа на QML со временем попросту откажется работать на компьютерах без OpenGL, а это огромная доля рынка

И что это за доля? Вы о legacy-железе?

>на компьютерах без OpenGL, а это огромная доля рынка

вы про африканцев и Северную Корею?

> И что это за доля? Вы о legacy-железе?

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

Возможно в будущем оно станет менее критичным, но мы пока живём в суровом настоящем (-:

>Компьютеры со старым железом;

Таких, чтобы совсем без аппаратного OpenGL? Их, ИМХО, мало. За последние 5 лет ни одного такого не попадалось. И более того — их количество уменьшается с каждым днем.

маленькие мобильные устройства без графических ускорителей; мобильные устройства, критичные к потребляемым ресурсам и времени батарейки;

Тут сложнее. Но все равно не так и мрачно: все выпускаемые (и тем более готовящиеся к выпуску) в данный момент девайсы, на которых можно запускать Qt-приложения (мы ведь не забыли об исходной теме, верно), имеют аппаратную поддержку хотя бы OpenGL ES 1.1 (и GLES 2.0 тоже совсем не редкость). А учитывая тот факт, что мобильные девайсы сейчас имеет смысл менять уже через год/два — проблема практически исчезает)

компьютеры без драйверов;

Это особый новый фетишь — не ставить драйвера на оборудование? Может тогда еще приведете примером тех, у кого и ОС не установлена? ;)

с драйверами, в которых остутствуют необходимая поддержка шейдеров.

Это которые? открытые дрова радеона/нвидиа? ну, проблемы индейцев - полнофункциональные (пусть и проприетарные) версии драйверов в наличие.

Эх, если бы всё было так здорово - уже давно бы популярные приложения переписали бы на ускоренной графике, благо графический опенсорсных движков хватает. Как вы думаете, почему те же Firefox и OpenOffice используют программный рендер? Как вы думаете, почему программные OpenGL рендеры (Quake1/2, UT1, Irrlicht) начиная с определённого момента исчезли как класс?

рискну предположить, что основный тормоза FF и OO совсем не в рендеринге...

Как вы думаете, почему те же Firefox и OpenOffice используют программный рендер?

Наверное по-этому:

sectoid@nyarly /usr/portage/distfiles $ ls -la | grep OOo
-rw-rw-r--   1 portage portage 214703203 May 26 22:00 OOo_3.2.1_src_core.tar.bz2
sectoid@nyarly /usr/portage/distfiles $ ls -la | grep firefo
-rw-rw-r--   1 portage portage  51423291 Oct 12 20:53 firefox-3.6.11.source.tar.bz2

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

Как вы думаете, почему программные OpenGL рендеры (Quake1/2, UT1, Irrlicht) начиная с определённого момента исчезли как класс?

Не понял вопроса. Конкретизируйте.

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

Хорошо, давайте от обратного. Покажите мне пример популярной десктопной программы с графическим интерфейсом на аппаратно ускоренной графике.

Не понял вопроса. Конкретизируйте.

Суть в том, что API для аппаратно ускоренной графики практически невозможно переделать без последствий на программный рендер, если нужен фаллбек. Причём неважно на каком уровне, используя OpenGL API или более высокоуровневые движки. На определённом этапе разработчик сталкивается с проблемой выбора: или только программный GUI или только аппаратно ускоренный. Та же проблема и с выбором между QML и QWidget & co.

>Покажите мне пример популярной десктопной программы с графическим интерфейсом на аппаратно ускоренной графике.

апертура и другой мак-софт?

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

Aero? ;) А если серьезно — да тот же Chromium, совсем недавно новость была. + Все приложения на Qt, у которых UI построен на QGraphicsWidget.

Суть в том, что API для аппаратно ускоренной графики практически невозможно переделать без последствий на программный рендер, _если нужен фаллбек_.

А вы все еще уверены, что он нужен?

>Aero? ;)

WPF тогда уже

>WPF тогда уже

Кстати да. Сервелат, наверное, тоже.

QrGui

Qml это новый который? С 3д и рюшечками?

> апертура и другой мак-софт?

Ограничены одной платформой.

> А вы все еще уверены, что он нужен?

Да, я абсолютно уверен. Тривиальный случай - LiveCD, как вы предствляете запуск того же браузера, в котором вырезали фаллбек на программную отрисовку? Тянуть на CD все драйвера под всё железо? А если обнаружится проблема с драйвером?

>Тянуть на CD все драйвера под всё железо? А если обнаружится проблема с драйвером?

А сколько этого «всего» железа? Сможете назвать что-то кроме ATI/NVidia/Intel? Sis? S3? (бугага)

> А сколько этого «всего» железа?

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

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

Т.е. все «проблемы» в результате свелись к открытости/закрытости и прочим юр. ограничениям?

>С Nvidia вообще получится весело, ведь их то драйвер проприетарный,

Полнофункциональный драйвер ATI тоже проприетарный.

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

Кстати, NVidia EULA запрещает повторное распространение? Читаю вот оригинал, но не могу однозначно сказать — не силен в юридическом английском.

>Ограничены одной платформой.

кросс-платформенности вы и не просили

> Кстати, NVidia EULA запрещает повторное распространение?

Это вопрос чистоты дистрибутивов и я прекрастно понимаю тех, кто противится разбавлять сборку проприетарными пакетами. Опять же, рассчитывать нужно на суровую действительность.

Если программа коммерческая, т.е. делается под продажу, естественно, что ни о каких qml речи идти не может, так как банально ещё сыро. С Qt в таком случае лучше было бы, наверное, вообще не связываться, так как её очень любят переписывать и не любят исправлять ошибки в старых версиях, но это уже другой разговор.

> апертура и другой мак-софт?

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

ага, ибо без этого сама OS X работать не будет.