Как стать автором
Обновить
31
-1

Пользователь

Отправить сообщение

Qt любят ребята, которые ценят кроссплатформенность. Например, Tesla использует его для своего UI. 

А у Tesla есть несколько на столько разнородных платформ, что им нужна кросс-платформенность? Или речь про какие-то клиенты?

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

Но и в обратную сторону: последнее время много прикладных ребята приходило на собесы, которые пользуют(!) Qt, но его механику воспринимают как магию или просто данность. Сигнал-слот соединение - ну классная штука, много пользы, но при чем тут moc-компилятор, и как оно так асинхронно долетает в другой поток - без понятия. Соответственно, в чистых плюсах тож плавают. С другой стороны, в 2023 так уж ли надо знать разницу между 'ё' и "ё", и почему взятие символа в русской строке не работает в STL просто так.

Кажется к Qt надо допускать только за выслугу лет и только летом. Но QML - прекрасен, спору нет.

Чет я разворчался)

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

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

И спасибо за статью.

Мне нравится идея написания кода, который во время компиляции позволит детерминировать кучу типозовисимых событий. Но особенно интересно, на сколько вырастет\сократиться время написания такого кода?
Полно программистов, которые достаточно быстро проверяют гипотезы и достигают цели говнокодом, а за тем несколькими итерациями отладки, рефакторинга, codereview, багофиксом доводят решение до ума. (привожу в пример не небожителей, а подрастающих трудяг). Таких вырастить и использовать стоит N. Интересно, как изменится это N в реальных проектах при переходе на такой ЯП. Или как оно повлияет на процесс обучения.
Это только так кажется. 30-40 программных сущностей\интерфейсов\формочек спустя начинаешь понимать, какой объем работы надо проделать; после реализации сотого рабочего места понимаешь, что фишка многослойной системы на X++ — это практически золото; когда открывается офис в другой стране, отдаешь должное универсализации SAP систем; а потом последуют структурные изменения, включение еще одной валюты, разграничение доступа, неполадки у интернет-провайдера, и отчеты, микроотчеты, мегаотчеты, макроотчеты…
А для работы магазина или небольшого предприятия современных возможностей Excel-а хватит с головой.
Спасибо за статью.

Напоминаем, что QML-компоненты на Sailfish OS не компилируются в ресурсы, а поставляются в виде отдельных файлов. В результате все зависимости от JavaScript тоже желательно поставлять в виде отдельных файлов.

QML-файлы и другие ресурсы возможно вложить в QRC, только для этого необходимо править не только .pro, но и .yaml.
Тоже самое про Qt Charts и Qt Data Visualization: их можно использовать в Sailfish, но сборка чуть сложнее.

Спасибо за статью.
Если я ничего не упускаю, то к геолокации, сервисам и SFOS статья отношения имеет мало.
Вы хорошо локализовали документацию Qt(QML-ную часть) и перечислили библиотеки-плагины.
Лично я бы хотел увидеть в таком цикле статей пример описания нового Location-плагина для, например, Яндекс Карт (с голосовым распознованием было классно), особенности позиционирования при использовании ГЛОНАС, занебесно крутым было бы решения конфликтов жестов: вертикальный свайп по карте и открытие PullDownMenu. Самое лучшее, что я видел в этом плане — Maep.


Успехов Вам, Коллеги.

Большое спасибо, за статью. Есть, чем дополнить.
Рекомендую изучить презентацию: Efficient models for QML with QSyncable
Один из первых подобных проектов — QQmlObjectListModel — прошел лед и пламень, и остался на плаву. Ben Lau (о его проектах в презентации) развил идею чуть дальше.

Теперь к критике: IMHO, многие утверждения здесь носят спорный характер.
Экономия на QObject — экономия на спичках при условии, что само приложение или размер контейнера малы. Если Вам довелось писать что-то вроде email-клиента — отказ от QObject-а дает весомое снижение ресурсоемкости. У Дениса Кормалева есть об этом в одном из выступлений.
Ваша аргументация о том, что у Electron ситуация еще хуже — совсем не аргумент.
Модель нужна ListView для того, чтобы поддержать анимирование операций над элементами (transitions). А сама QAbstractListModel как раз позволяет экспортировать НЕ Qt-типы в QML без дополнительных регистраций.
Если у вас есть QList и QObject-ы, но не нужен визуальный обвес ввиде красивых исчезновений элемента при удалении, вы можете прокинуть сам QList. Да, с «приколами», но тем не менее — это штатное средство без макросов, без абстракций.
О качестве QList и его дальнейшем существовании в Qt 6 одно время велись споры среди самих разработчиков Qt. Кроме того, при условии работы с другой STL-библиотекой, генерирующей данные, на выходе у вас будет STL-ный же контейнер. QList хорош, когда не надо запариваться.
Для получения данных элемента в статье используется самописный метод ::item()(шаг третий), в то же самое время использование штатного QAbstractItemModel::data() c явным «преобразованием» QObject* в QVariant. На моей практике, штатный метод, используемый для формирования объектов model\modelData в делегате, бывает куууда полезней.

Сам по себе подход, описанный в этой статье — не панацея, а решение конкретных проблем, например, описанных в этой статье: много полей — грустно таскать каждое из модели — значения отдать QVariant-ом с Q_GADGET. Это проблема.
Тот факт, что приходится переписывать многа букав — проблема при условии, что вы прототипируете, или делаете MVP или тому подобное. Из невероятного: у вас много однотипных Qt-only моделек, которые использоваться будут также тривиально. Шаг влево — и вам придется написать костыль для того, чтобы сохранить использование вашей абстракции; шаг вправо — и вы сильно рискуете потерять контроль над жизнью объектов в QML (в качестве примера, советую поэкспериментировать с ListModel, QObject* в QML и gc() — все не так гладко).

Такие наработки хороши: они оптимизируют на 70% время работы с модельками. Одна беда: они применимы в 5% случаев, которые составляют 0,01% от числа всех проблем отдельно взятого приложения. (цифры условные)
Спасибо за статью, очень доходчиво.
Правильно ли я понимаю, что как раз ConnMan и используется в собственном WiFi менеджере панели управления Sailfish OS?
Есть ли при работе с TechnologyModel или NetworkService возможность работать с кешированными сетями? В каком виде хранится кеш и кому он доступен?

Идею личной пробы одобряю, но как и многие до меня призову Вас задуматься, как сделать так, чтобы постфактум на этом проекте не появилась жирная надпись «ПОТРАЧЕНОе даром время».
История реглигий не согласиться с гипотезой о глиняных табличках))

Вашей смелости и амбициозности остается только позавидовать.
Большое спасибо за статью и код, весьма любопытно.
Программирование по хардкору — это очень круто.


Но все-таки остаются вопросы.


Прежде всего поддержу комментатора выше: очень интересует трансляция QML в С++.
Делали ли вы какое-то сравнение с родным QtQuickCompailer-ом?
Как прогнозы относительно существующей и грядущей генерации кэша?
Планируете ли Вы продолжать крестовые походы в этом направлении?


Большое недоумение вызывает выбор в пользу HTML\JS и всей остальной обвязки.
Вы начинали с того, что вывели в мир новую связку QML+С++(вместоJS), я так понимаю в 10-м году это был еще Qt Quick 1.0. В результате QML-код не стал компилироваться в полноценный бинарник, а добавилась еще одна прослойка интерпретации\трансляции. То есть то, о чем сейчас много шумят: между нативным фреймворком и кросплатформенным Вы выбрали кросплатформенный.
Почему? Поправьте, если я где-то неправильно понял.


Хотелось бы еще узнать о том, как решен\решается вопрос с Native Look & Feel.
Если говорить о телевизорах, те же Android-TV и AppleTV, то они таки имееют определенные особенности.
Буду очень признателен, если поможете найти это в примерах.


Касательно производительности. Очень хочется больше Цифръ(!). Очень сложно поверить, что транслирование в HTML дало такой существенный прирост (говорю о дне сегодняшнем) по сравнению с QML.
У ребят из SpbTv имеется нативный низкоуровненый фремворк с поддержкой того же Qt: в этой обвязке они запускают стримовое видео на старых чернобелых Palm-ах, а там всего около 10 Мб памяти.


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


Еще раз спасибо за статью и код.
Надеюсь это не последний рассказ.

А что вы имеете ввиду под "дает больше свободы"?

А все-таки интересно услышать сторонников PWA.
Мнения против, действительно, ценны, но тут либо дискуссию начинать, либо во второй статье смысла не будет.
Свежих аргументов в ней наверняка не прибавиться.

Автору грандиозный респект за его осмысление и труд, замечательную статью и открытый код.
К сожалению, пока только в комментариях.
О личном опыте — была задача на архитектуру с rest-api в QtQuick: до отдельной библиотеки дело не дошло, но получилось весьма похоже.
Добавлю, что для того, что бы уйти от лишних QObject-ов, активно задействовался Q_GADGET, например при клике на элемент DetailModel формировался такой объект, что позволило ослабить хватку слежения за выделяемой памятью (понятие ownership оказалось не без подвохов).

Разве?
Если не ошибаюсь, здесь просто реализовано обращение к SpeechKit Cloud API, отправляемое запрос post-ом и только.
Библиотека SpeechKit Mobile SDK, пока отсутствует. FRUCT, так ли это?

Спасибо большое за развернутый ответ.

А поделитесь опытом:
На сколько удобным оказалось на практике применение Flux в QML?
Обнаружились ли подводные камни при реализации паттерна или библиотеки QuickFlux?

В этом случае оборачивание в QVariant повлечет за собой:


  • написание Q_GADGET wrapper-а с пачкой Q_PROPERTY, которые будет также неудобно описывать (если я правильно Вас понял.);
  • копирование данных при выполнении QVariant::fromValue(), что при большой структуре отразится на производительности;
  • необходимость в qml-коде обращаться к конкретному свойству через объект: model.object.property (сахар, конечно, но это будет раздражать).

С другой стороны, сохранение значения model.object позволит минимизировать обращение к QAbstractItemModel::data() со всеми вытекающими.


Так что соглашусь: нужно смотреть по ситуации.

Хорошая статья, важное замечание.

Предложил бы еще так же сказать пару слов о макросе Q_DECLARE_OPAQUE_POINTER и смежных.

Не совсем согласен с утверждением:
Почему то мы не можем использовать ValueType в методах помеченными Q_INVOKABLE.

Утверждаю, что следующий код будет работать в 5.6.1:
// record.h
class Record
{
  Q_GADGET
...
}

// listener.h
class Listener: public QObject
{
  Q_OBJECT
...
  Q_INVOKABLE Record foo ();
}

//main.cpp
...
qRegisterMetaType<Record>();
qmlRegisterType<Listener>("MyModule", 1, 0, "Listener");
...


// main.qml
...
Component.onCompleted: {
    var  r = someListener.foo();

    print(r)
    print(typeof r)
    print(Qt.isQtObject(r))

    r.text = "hooray";
    print(r.text)
}
...

// output:
qml:  Record()
qml:  object
qml:  false
qml:  hooray



Информация

В рейтинге
Не участвует
Работает в
Зарегистрирован
Активность