Лол. Поясню немного, а то что-то школьники-студенты, которые не писали на этом самом QML ничего сложнее калькулятора или примеров с шариками минусуют.По поводу гетеров/сетеров - да, один/два не так сложно, но есть такая штука как ОРМ, которая работает со структурами, в которых бывает по 10-15 полей. В С++ коде просто заполняем поля, скармливаем ОРМу и впуть. Чтоб выдать это в QML мне надо описать эти самые 10-15 гетеров/сетеров. Весело, неправда ли? Конечно, можно описывать не для всех полей, а только тех что надо и получать обьекты-огрызки.
Когда нада передать в QML список обьектов, как я говорил, все еще хуже. Можно отдать QList, но ТОЛЬКО стандартных для QML типов. Свои типы, вроде как рекомендовали оборачивать в Variant(добавля ОЧЕРЕДНУЮ метадату к обьектно), но не тут то было, ведь есть вот это: https://bugreports.qt-project.org/browse/QTBUG-25194 Багу год, между прочим. Но выход есть, а именно другой костыль - QDeclarativeListProperty. Почему костыль? Да потому что взять, наприме один обьект, в QML из этой коллекции низзя. Нельзя сделать ее ReadOnly, а ведь во многих случаях добавления элементов туда вообще не имеет смысла. Да достаточно взглянуть на то, как оно реализуется в C++ со всякими там статическими методами... Так же мне нравится, что там есть конструктор из QList, который вызывает утечки памяти, что сказано прям в документации. НО это еще не все: в QML есть различные View для представления обьектов, но данная коллекция не может быть использована как model, к этим самым View.
Для View нам рекомендуют использовать в качестве моделей из C++ либо спиоск строк(кому оно вообще надо?), либо лист указателей на QObject в для которых задекларированы property(!!!). К слову, к элментам моделей просто так из QML обращаться нельзя, т.е. проблему выше это не решает(хотя есть еще костыли, как делать это через прокси View, но...). Казалось бы - вот оно решение, НО View не реагирует на изменения в модели. ЛОЛ. Т.е. при изменеии данных, пользователь этого не увидит(ну если не перестроить View заного). Для решения этой проблемы нужно создавать наследника QAbstractItemModel в котором специально для QML сделали костыль из RoleNames(привет Си!). Теперь доступ к данным происходит на основании сравнения значения енума, ведь типизация не нужна, да. Думаете это решение всех бед?! Ну конечно нет, если коллекция не плоская, и какой то ее эллимент - это коллекция, то доступа к ней у вас не будет. QTBUG-25194. И вот тогда приходится добавлять в модель еще QDeclarativeListProperty, которая по индексу вернет коллекцию.
В результате биндинги из C++ в QML могут иметь больше файлов и кода, чем сам код C++. Офигеть.
По поводу документации: вопервых для многих новых QML обьектов ее просто нет(ну или не было еще пару месяцев назад, ща не проверял). Во вторых они с чего то взяли и сменили структуру сайте, и теперь многие ссылки в инете(в том числе и на багтрекер) ведут в никуда, просто редирект на главный сайте.
Ну и баги в компонентах: везде! Скролл из кода того же ListView до какого элемента происходит без анимации. Решение - костыль в виде самостоятельной анимации и использовании свойств, которые документация использовать не рекомендует. Передача сообщение от той же мыши для вложенных MouseArea невозможно(покрайней мере в 4.8, в 5ке, вроде, были какие то подвижки). WebView - вообще один сплошной баг. От невозможности использования anchor scroll на страничке и до проблем с ресайзом https://bugs.webkit.org/show_bug.cgi?id=90421. Стоит ли говорить, что взаимодействие с JavaScript внутри WebView происходит через строки? В 5ке webview переписали, но всеравно есть проблемы, народ на форумах жалуется, что оно течет. Недокументированный Experemental api - это вообще пушка.
Короче проблем когда сталкиваешься много. Некторые можно поправить, некоторые, как говориться, broken by design. Но чего я не понимаю, это то чем занимаются троли. Портируют на разные платформы, добавляют модули и тд. Да кому оно вообще нужно такое вот? Тот же JavaScript с современным количеством ГУИ фреймворков намного чище и проще.
