LINUX.ORG.RU

qml vs qwidgets

 ,


1

3

а в чем прикол qml и quick в сравнении с widgets?

там же, вроде, помесь css и ручного управления положением контролов, не?

// ман не читал

Ответ на: комментарий от umren

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

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

CrossFire ★★★★★ ()

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

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

CrossFire ★★★★★ ()
Последнее исправление: CrossFire (всего исправлений: 1)

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

KblCb ★★★★★ ()

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

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

Kakadu ()
Ответ на: комментарий от Kakadu

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

CrossFire ★★★★★ ()

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

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

anonymous ()
Ответ на: комментарий от CrossFire

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

anonymous ()

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

Deleted ()

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

equeim ★★ ()
Ответ на: комментарий от frozenix

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

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

CrossFire ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

alex_custov ★★★★★ ()
Ответ на: комментарий от CrossFire

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

frozenix ★★★ ()
Ответ на: комментарий от alex_custov

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

frozenix ★★★ ()
Ответ на: комментарий от frozenix

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

CrossFire ★★★★★ ()
Ответ на: комментарий от alex_custov

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

anonymous ()
Ответ на: комментарий от frozenix

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

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

alex_custov ★★★★★ ()

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

anonymous ()
Ответ на: комментарий от alex_custov

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

frozenix ★★★ ()
Ответ на: комментарий от anonymous

Делал treeView на qml

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

alex_custov ★★★★★ ()
Ответ на: комментарий от frozenix

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

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

alex_custov ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

CrossFire ★★★★★ ()
Последнее исправление: CrossFire (всего исправлений: 1)
Ответ на: комментарий от alex_custov

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

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

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

anonymous ()
Ответ на: комментарий от CrossFire

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

alex_custov ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

CrossFire ★★★★★ ()
Ответ на: комментарий от alex_custov

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

frozenix ★★★ ()
Ответ на: комментарий от alex_custov

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

anonymous ()
Ответ на: комментарий от CrossFire

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

CrossFire ★★★★★ ()
Ответ на: комментарий от CrossFire

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

anonymous ()
Ответ на: комментарий от anonymous

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

CrossFire ★★★★★ ()
Ответ на: комментарий от CrossFire

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

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

anonymous ()
Ответ на: комментарий от CrossFire

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

CrossFire ★★★★★ ()
Ответ на: комментарий от CrossFire

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

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

Dendy ★★★★★ ()

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

anonymous ()

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

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

RiseOfDeath ★★★★ ()
Ответ на: комментарий от RiseOfDeath

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

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

alex_custov ★★★★★ ()
Ответ на: комментарий от alex_custov

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

RiseOfDeath ★★★★ ()
Ответ на: комментарий от anonymous

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

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

kaffeine ()
Ответ на: комментарий от kaffeine

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

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

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

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.