qml vs qwidgets

1 работает вроде как на мобилках, второе нет

1 работает вроде как на мобилках, второе нет

Второе тоже работает, но контролы не предназначены для мобилок, все слишком мелкое.

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

О текущем состоянии Qt Quick можно почитать тут: http://habrahabr.ru/company/istodo/blog/220265/

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

В QtQuick переписали отрисовку контролов, заоптимизировали, и подключили OpenGL к отрисовке. Также простые вещи теперь можно скриптовать, т.е. описать, что если одна кнопка кликабельная, вторая наоборот, можно прямо где кнопки определяются, без всякого С++

Да, изначально оно планировалось для кастомных интерфейсов мобильных устройств. Но контролы для десктопа пилятся, и скоро должен настать коммунизм в этом плане.

В итоге контролы виджетов обычно не имеют нативной для смартфона темы

Увы, контролы квика тоже.

Они над этим работают. У них, насколько я знаю, перед релизом 5.3 это было в приоритете.

Насколько я знаю (где-то диалог был в описании бага), контролы хорошо если будут через год, потому как под ведроид их писать даже не начинали(

QML для того, чтоб не йепстись с окошечками, а описать то, что тебе нужно + возможность подключиться к сигналам (а так же в обратную сторону) из С++'сного ядра. Собссно этим может заниматься дизайнер, например, совершенно не знакомый с втоим внутренним устройством приложения. Главное договориться о тех самых сигналах.

Про контроллы уже сказали, но, думаю, проблема временная.

У ведроида своя система гуйни вполне годная. Накуй туда тащить всякий QML?

QML это такая штука, где тебе придётся все делать самому. Ну или почти все, в последней его реинкарнации.

Половина программы теперь на javascript (собственно интерфейс на qt quick). Соответственно возросло потребление памяти и увеличились тормоза. Есть контролы для десктопа, копирующие вид qtwidgets (пока весьма посредственно. Причем под windows они работают быстрее и лучше, лол). Также интерфейс sailfish / ubuntu touch полностью на qt quick, со своими несовместимыми наборами контролов.

За какое время ты сделаешь прыгающий и вращающийся ${image} на QtWidgets?

За какое время ты сделаешь прыгающий и вращающийся ${image} на QtWidgets?

На самом деле ничего сверхъестественного, другое дело что анимации на виджетах сильно просаживают производительность... https://blog.qt.digia.com/blog/2009/06/09/flippin-widgets-medium-rare-please/

Собссно этим может заниматься дизайнер

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

Не сложно, просто трудоемко. А если все свистит и пукает, то делать это нужно будет довольно часто. Ну и killer feature это анимация частиц. Вроде бы аналогов ей нет в QtWidgets.

через QPropertyAnimation - недолго, думаю за полчаса неспеша. А ты за сколько сделаешь QTreeView на QML?

Даже сделать кнопку в QML без программирования нельзя. Другое дело, что этим может заниматься web front-end developer.

У них просто практически не пересекающиеся области оптимального применения.

Делал treeView на qml. Для настроек, через Loaderы. В принципе, ничего сложного, но TreeModel в qml таки нету.

Даже сделать кнопку в QML без программирования нельзя

в самом простейшем случае и по легенде этой басни программирование будет заключаться в однострочном вызове C++/JS кода, который будет отвечать за логику. То есть дизайнер будет иметь список строк кода, которые он должен вставить как ответ на действия пользователя. Что наврятли бывает в приличного размера проектах.

Как бы сказать... Qml - охренительная штука, позволяющая писать интерфейсы и логику раз в 10 проще, чем на крестах. И гибче. Самая главная фишка - это привязки. Наверное, это чем то похоже на функциональщину.

http://www.codeproject.com/Articles/632795/QML-TreeModel-and-TreeView

Да, через зад, но не так сложно.

Я ж уже говорил про Web Front-End *Developer*. Т.е. подразумеваю, что с JS знаком, умеет читать доки и не полный идиот в плане взаимодействия с компом.

Делал treeView на qml

Функциональность в точности повторяет QTreeView/QTreeWidget, или только отдалённо? Если отдалённо, то не нужно. Вот вариант, который немного близок к оригиналу: http://qt-project.org/forums/viewreply/146845/

Я ж уже говорил про Web Front-End *Developer*

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

Qml - охренительная штука, позволяющая писать интерфейсы и логику раз в 10 проще, чем на крестах.

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

Оно совсем не было аналог QTreeWiew. Суть такова - в формате JSON хранились настройки (древовидно, ясен пень). JSON парсится в QVariantMap, который в JS - обычный Object. Вот это и надо было древовидно отображать.

Насколько помню, там еще зависимость от типа была (типа если bool - чекбокс, число - поле с кнопками вверх-вниз, текст - просто поле)

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

Чушь. В QML есть наследование. К примеру, главный класс - QtObject, его наследник - Item, его наследник - Rectangle, Image и прочие овердохрена.

По сути нихрена не аналог, а специализированная для себя штуковина

ну так это не дерево, а какой-то жесткач. А нужно классическое дерево. Модель - ListModel.

Чушь. В QML есть наследование.

Наследование элементов, реализованных через C++? Вот как мне конкретно свой компонент отнаследовать?

А чем занимается верстальщик? Дизайнеры вообще рисуют и писать не умеют.

Ну вообще-то так и делалось, вся эта хренотень преобразовывалась в ListModel, где листья это ListItem, а узлы тот же ListModel. Но ListModel'ом древовидную модель надавать - извращение и многабукаф. А вот жабоскриптовый Object для этого неплохо подходит.

В плюсах наследуешься от QQuickItem (Ну или QQuickPaintedItem. Хотя я наследую QQuickWindow).

В майне после QApplication пишешь qmlRegisterType<MySpecialComponent>(«MyLib», 1, 0, «MySpecialComponent»);

В кумээльке импортишь import MyLib 1.0 И используешь. Все там можно, и кучей разных способов...

Чушь. В QML есть наследование.
В плюсах наследуешься от QQuickItem

Один я вижу взаимоисключающие параграфы? Я не сомневаюсь, что в плюсах есть наследование. А в QML наследования нет.

Видимо один ты. Чего тут непонятно? Ты пишешь свой класс на плюсах, наследуясь от какого-то базового класса. И импортишь его в QML и используешь. Или может ты множественное наследование или какие другие извраты имел?

Есть у меня графический QML элемент (скажем на основе Rectangle), пусть кнопка. Я хочу отнаследоваться от него и сделать кучу производных элементов, собственно иерархия как в плюсовых виджетах.

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

А дальше типо унаследовал, пишешь: Element { id: blablabla //... }

Собсно, когда ты «делаешь элемент на основе Rectangle» - ты то же самое и делаешь - наследуешь Rectangle (А заодно Item, QtObject, прикрепленные свойства от Positioner и Layout...)

А дальше типо унаследовал, пишешь: Element { id: blablabla //... }

В том-то и дело, что «типа». Если у нас нет доступа ко внутренностям предка, его методы автоматически не прокидываются потомку, то это не наследование в терминологии ООП и виджетов.

А с чего это вдруг нету доступа ко внутренностям предка?

Если у нас нет доступа ко внутренностям предка...

Но оно есть. Значит есть и наследование.

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

по басне это должен быть дизайнер, а не программист

дизайнер или таки designer?

дизайнер

Qml/quick удобен для создания интерфейса «от дизайнера». Виджеты удобны для создания интерфейса «от программиста».

Соответственно в первом случае у прогера будет батхерт (там какие-то колдунства нужны, что бы это все с плюсами связать), а вот в виджетами наоборот «нарисовать» задуманое сложнее.

Qml/quick удобен для создания интерфейса «от дизайнера»

Что бы это значило? Это же копипаста пропаганды от Digia, а вот факты?

Это мое личное мнение, основаное на попытке поглазеть, что за зверь такой QML, я «пропаганду от Digia» не читал.

С того, что его (доступа) нет фактически.
Например, нельзя обратиться к вложенному элементу базового класса по его id.

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

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

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

Протектеда и прайват нет из каропки, но есть хинт. Заводим QtObject { id: internal; property int myHidenInt: 42 } Вот тебе и приватная зона. Есть и ридонли свойства. Если хочется сделать только чтение на какой-то параметр, при выдачи «наружу», то делаем в том же internal свойство, а у корнегового элемента readonly property alias ... на него. Всё просто же.