P.S. -Что сказать то хотел? -Да ничего не хотел, чужое отношения к этому хотел послушать. Можно даже подискутировать.

Надо было это не в P.S. а в Q&A писать. И так с каждым постом/новостью на ЛОРе отныне =)

Понимаю твою радость. Мы уже 1 проект начали на него перетаскивать.

Интересно было бы послушать об успехах и неуспехах.

>6. Никакого С++.

Зато жабаскрипт.

> Зато жабаскрипт.
Словно что-то плохое.

Еще к плюсам QML можно отнести простоту расширения его собственными компонентами, в том числе и реализованными на C++.

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

Да пока в состоянии прототипа. :)
Немного негибко с графикой, но это или еще тупим или просто глаза замылены.

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

НУ и попутно вопрос - может кто кинется примером QML приложения, код там заценить, посмотреть его вживую, прежде чем начать изучать.

И чем этот недо-JavaScript лучше PyQt4?

если я клепаю интерефейс мышью в QCreator и юзаю все аля ui->treeView,
мне трудно будет перенести приложение на сабж?

Плохое, ибо нужно ещё и это слаботипизированное чудище тащить :}

>И чем этот недо-JavaScript лучше PyQt4?

PyQt4 ЕМНИП то де самое, что и просто Qt, но на пистоне, а кумл что-то типа трехмерной ерунды и каких-то там перделок. В общем, разница между ними как между велосипедом и самолетом.

Стоит ли оно лишних зависимостей? Хотя если это позволит перетыкать морды без перекомпиляции…

> кумл что-то типа трехмерной

трехмерной

Кастую 4.2

Спасибо.

> И чем этот недо-JavaScript лучше PyQt4?

Тем, что он декларативный?

Не, ну я мог чего попутать.

Та ну один черт с перделками же.

Гуй придется заново делать. Никаких конвертеров нет, насколько я знаю. Было вроде что-то вроде Gimp -> QML, но это вряд ли тебе поможет.

К сожалению с питоном (а соответственно и с PyQt) не знаком.

Да, позволит. На лету, правда, еще не пробовал, но при перезапуске все срабатывает. Это тоже заметный плюсь технологии для создания приложений, поддерживающих т.н. «скины».

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

Вообще зависит от того, почему был выбран способ построения интерфейсов на UI. Если для избавления от сложности С++ кода - тогда да, поможет.
Если просто неудобно интерфейсы описывать и нужен именно WYSIWYG, тогда не поможет.

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

Ну, я как раз о перезапуске. В принципе, даже может быть удобным. Стоит, пожалуй, поковыряться.

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

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

На здоровье:

Тормозит при загрузке пропорционально размеру QML-кода, который загружается целиком со всеми зависимостями. Если объём кода вырос до сотен килобайт (что вполне нормально для среднего проекта), то GUI-процесс зависнет на несколько секунд при старте. Если это какой-нибудь мелкий плазмоид, то инициализация JavaScript-движка и разбор QML может, мягко говоря, раздражать подвисаниями при открытии.

Жрёт как не в себя и фрагментирует память как дуршлаг. При сложных сценах огромный оверхед на биндинги между элементами.

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

Отсутствие лейоутов как таковых (привет, каменный век), всё приходится хардкодить руками. Row, Column и склеивание элементов друг за другом жалкое подобие функционала на основе QLayout.

Повсеместная векторная графика, превращающаяся в дикие тормоза при более-менее нагруженном интерфейсе, развёрнутом на большой полный экран 1920x1200.

Интеграция с интерфейсом, основанным на QWidget слабенькая. В частности, QML-код не реагирует на потерю фокуса, хочется верить, что это просто ошибки, которые в ближайшее время исправят.

Ну и, конечно же, отсутствие множества стандартных всеми любимых элементов, таких как банальное поле ввода, которые хочется модифицировать под свои нужды. Практически на любой чих приходится или а) наследовать уже готовый контрол, чтобы его доработать (при этом увеличение QML-кода неуклонно ведёт к тормозам и откусыванию памяти), или б) форкать контрол на C++ из private-классов Qt, негативные последствия чего, я думаю, рассказывать не нужно.

Вобщем, QML — хорошая штука, но применять его стоит дозированно и исключительно там, где это нужно. Фанатизм а-ля «переписать всё на QML» может привести к печальным результатам.

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

Сделай мне копипаст в элементе text... Или сделай мне хождение по ссылкам в элементе textedit. Сделай мне отображение в виде дерева, сделай мне таблицу а не grin. На самом деле, вот таких мелочей там пока хватает. Ждем Qt Quick 1.2

Неправда.. он именно 3х мерный

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

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

> Отсутствие лейоутов как таковых (привет, каменный век), всё приходится хардкодить руками.

Ужас, почему мы, как дураки, используем вложенность элементов с анчерами?

>Тормозит и жрет
Очень жаль, надеюсь в будушем поправят. Что-то слышал о том, что туда какой-то новый движек для JS собирались прикрутить. Это уже с ним или без него?

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

Отсутствие лейоутов как таковых (привет, каменный век), всё приходится хардкодить руками. Row, Column и склеивание элементов друг за другом жалкое подобие функционала на основе QLayout.

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

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

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

А вот за этот вброс большое спасибо!

> Ужас, почему мы, как дураки, используем вложенность элементов с анчерами?

Якоря достаточно просты, они позволяют только приклеить один элемент к другому. Вот, к примеру, простая задачка: 3 элемента в ряд, один фиксированной (но заранее неизвестной) ширины, а два других должны делить оставшееся пространство поровну. Как это сделать на QML?

> анчерами
Всегда думал, что читается «анкор», но вообще да, согласен. По-моему, Денди просто не осилил QML'ные «layoutы».

> Что-то слышал о том, что туда какой-то новый движек для JS собирались прикрутить. Это уже с ним или без него?

Всё что я описал проявляется на родном Qt 4.7.1. Новый JS-движёк и JIT были бы очень кстати. Я сказал «очень»? Были бы нереально очень кстати.

как мёдом помазал )

Закопать этот ваш Qt

2. Никаких проблем с выделением памяти.

А где они есть то?

По-моему, Денди просто не осилил QML'ные «layoutы».

Вполне возможно и так. Прямо над вашим комментарием лежит тривиальная задачка, если можно — приведите ваш вариант её реализации на QML.

Кстати, я написал отдельный набор QML-элементов на C++, которые используют под капотом родной движок на QLayout'ах со всем его функционалом. Решение на нём будет выглядеть примерно так:

MyHorizontalLayout {
    spacing: 8

    MyItem {
        fixedWidth: 40
    }

    MyItem {
        horizontalSizePolicy: "expanding"
    }

    MyItem {
        horizontalSizePolicy: "expanding"
    }
}

Вот, к примеру, простая задачка: 3 элемента в ряд, один фиксированной (но заранее неизвестной) ширины, а два других должны делить оставшееся пространство поровну. Как это сделать на QML?

import QtQuick 1.0

Item {
    id: item
    width: 200; height: 200

    Row {
        id: xrow
        property int xwidth: 40

        height: 100
        width: 200

        spacing: 0
        Rectangle { color: "red"; width: (parent.width - parent.xwidth) / 2; height: parent.height }
        Rectangle { color: "green"; width: parent.xwidth; height: parent.height }
        Rectangle { color: "blue"; width: (parent.width - parent.xwidth) / 2; height: parent.height }
    }

    MouseArea {
        anchors.fill: parent
        onClicked: xrow.xwidth = 100
   }
}

Делаю такое в первый раз, разбирался по докам после того, как прочитал твое задание.

Насколько я понял, должно быть что-то типа такого:
1-ый элемент: левый якорь к левому краю родителя, задать ширину
2-ой элемент: левый якорь к первому элементу
3-ий элемент: левый якорь ко второму элементу, правый якорь - к правому краю родителя.

Так не будет рабоать?
Если у кого-нибудь под рукой есть Qt/QML, буду благодарен за проверку в действии.

Никакого С++.

Вот она, киллерфича, остальные по сравнению с ней малы. Wait a minute...

В Qt

Кстати, я написал отдельный набор QML-элементов на C++, которые используют под капотом родной движок на QLayout'ах со всем его функционалом.

Ну вот и здорово же. А я писал обвязку для QNAM, чтобы его можно было напрямую использовать в Qml.

> Делаю такое в первый раз, разбирался по докам после того, как прочитал твое задание.

А теперь сделайте, чтобы место делилось не между 2-мя, а 3-мя или 4-мя элементами. А если нужно будет добавить зазор между ними? А если одно из них будет динамически показываться и прятаться? Тогда размещение превращается в сплошную головную боль с кучей флагов, математики и возможностью выстрелить себе в ногу.

А что насчет этого Qt Components говорят? Кстати, видел тут на qt-apps вполне себе живую реализацию нативных виджетов (точнее нативных стилей) на qml. Очень даже проникся. Можно на QStyle'ах легко и быстро нахренячить любые нативные виджеты. Короче потенциал у технологии очень и очень большой, но пока это скорее игрушка.

> Так не будет рабоать?

Не-а. Напишите сами пример, проверьте, попробуйте минимизировать, чтобы оставить лишь важный функционал. Потом сравните с примером, который запостил я.

> А теперь сделайте, чтобы место делилось не между 2-мя, а 3-мя или 4-мя элементами.
2 меняется на n.

А если нужно будет добавить зазор между ними?

Уже есть spacing же, я его выставил на 0.

А если одно из них будет динамически показываться и прятаться?

Не пробовал, но наверняка есть решение.

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

Ну, понятное дело, что придется реализовывать математику, как ее кто-то реализовал в QLayout.

Вопрос из танка

А что, «обычных» (нативных?) элементов там нет?

> Ну, понятное дело, что придется реализовывать математику, как ее кто-то реализовал в QLayout.

В QLayout это сделано один раз и для всех, в своём коде достаточно задать политику размещения, остальное будет сделано автоматически.
Семейство QLayout'ов — довольно сложная штука. Вы правда думаете, что каждый новый программист сядет и напишет собственную реализацию лейоутов на QML? Этот фантастический сценарий под силу единицам, а речь идёт о реальной ситуации, которая есть какая есть — с якорями и примитивными Row, Column и Grid.