Комментарии 13
Не понимаю почему Qt/QML так мало используют в мобильной и уж тем более в десктопной разработке. Очень удобный фрейморк или СДК, кому как нравится, работает быстро, накладные расходы на кроссплатформенность минимальные, платформенно специфичные баги бывают, но достаточно редко. Я его использую для разработки внутреннего тулинга в геймдеве, причем уже в двух компаниях. Альтернатива электрон, но смотрю на слак и скайп, постоянно то одно то другое бажит и как-то желания даже смотреть его нет. Скайп был вообще мегастабильный до перехода на электрон. Вайбер и Телеграмм на qt сделаны, телеграмм конечно достаточно специфично qt использует )) но то ладно.
По теме топика, какую версию Qt используете?
В Авроре 5.6.х вроде версия. Она старая очень.
А используют реже потому что что сама ide то ещё по сравнению с Android studio гораздо хуже. Сам язык сложнее. Непонятки с QML/C++ что где писать и на что ориентироваться. И ещё куча всего. Ну и сам kotlin гораздо приятнее чем с++
IDE может быть любой, красота Qt в том что вы можете писать программу полностью на десктопе под десктоп, без эмуляторов, симуляторов и прочего, почти 95% кода так можно написать и остается 5% которым потребуется платформенно зависимые штуки, скорее всего это будут пуши, может быть работа с камерой. Нет проблемы разрабатывать на Qt используя андроид студию. В разработке на qt строго говоря вы вообще не привязаны к IDE. Насчет сложности С++ разговоры сильно преувеличены, тут конечно вкусовщина, это мой основной язык разработки на протяжение наверно 20 лет, но у него есть плюс, даже два, он кроссплатформенный, программа написанная на котлин или Swift будет работать только под одной платформой, и если их выбрать как основу, вам нужно иметь две команды которые будут фактически делать два приложения, программа написанная на с++ будет работать везде, конечно же мы говорим про логику, а не взаимодействие с ОС специфичными. "сам kotlin гораздо приятнее" Вы же понимаете что это вкусовщина, язык должен позволять выполнять определенные задачи, грубо говоря реализовывать алгоритм, все Си подобные языки более менее одинаковые (если не нравится си подобный, можно сказать оберон подобные или процедурные или ООП, кому как нравится). В целом что бы решать почти все задачи достаточно функций и структур, остальное это синтаксический сахар, корутины, замыкания, стандартная библиотека и прочее и прочее, это удобные помощники, но не больше.
"Непонятки с QML/C++ что где писать и на что ориентироваться" стоит начать и все сразу станет понятно, с++ это строительные блоки QML это клей который склеивает их между собой. С++ строго типизированный язык, на нем нужно писать 90% кода, в случае если что-то пойдет не так, программа как правило не соберется(имею ввиду не соответствие типов), QML дает свободу в виде отсутствующей типизации, на нем удобно склеивать между собой различные блоки сделанные на с++, но если вы нарушили типизацию узнаете(как в питоне) в момент выполнения программы. QML по большей части декларативный язык, это такой HTML на стероидах, в нем можно писать блоки на JS, но лучше что бы это были простые функции проброса данных в с++ и логику на js лучше вообще не писать. Ну и мегафича Qt/QML это свои виджеты, у вас есть RHI(можно считать что это OpenGL) и делай что хочешь и как хочешь, шейдеры, многопоточный рендер, все сразу, любые капризы, вот тебе gl контекст делай шо хочешь. У нас представление игры в тулинге фактически через один виджет реализовано, просто сделали его оберткой вокруг движка и игры.
Писать мобильные приложения на десктопе без эмуляторов и прочего это кстати очень удобно и значительно быстрее. Просто делаете приложение, оно запускается, отлаживается, все как в любом десктопном приложение, любой профилировщик втягивается, потом шаманите с системой сборки, где МОКи для мобильно специфичных задач подменяются на реальные при сборке и вырезается все что вы прикрутили на десктопе для отладки и профилирования и прочие хелперы. И хлоп на выходе мобильное приложение, причем у себя на машине вообще не собираю его, все делает CI. Я просто пишу приложение как для десктопа, а потом магическим образом получаются ios и android приложения.
Вероятно я менее опытный чем вы, но все же...
Я не видел примеров работы в другой ide отличной от qt creator. Если скинете примеры, буду благодарен.
Так то и kotlin уже мультиплатформенный, ui для ПК уже есть, для iOS в альфе сейчас. И ui декларативный, с кучей примеров где все разжевано, а не как в qt. Тут больше претензии не к самому языку, а к инфраструктуре примеров вокруг, может он и крутой, но примеров очень мало, с Android developer не сравнить.
Ну и то, что все языки одинаковые это все же лукавство, да, делать можно одинаковые вещи, но удобнее на языках более высокого уровня. (У меня есть опыт написания проектов и на с и на kotlin и даже на ассемблер, есть с чем сравнить так сказать). Что касается вкусовщины или нет, по мне работать с coroutines приятнее и удобнее чем с потоками, да плюс асинхронщину в сам язык вроде не так и давно завезли (я про с++). Впрочем сигналы/слоты вроде это все же упрощают. Но я лучше буду на kotlin писать где мне или кодогенерация или gson распарсят json без особых стараний с моей стороны, чем писать монструозную реализацию на с++.
На gl мне сказать нечего, я с ними особо не работал, на Android их полноценно только в 12 версии завезли (agsl)
Ну ладно, нет там магии для Android и iOS. И работы там сделано много, просто она от вас спрятана, так и про flutter можно сказать, он тоже все собирает. И ci сейчас у всех так, Jenkins вроде не сильно сложная штука.
В общем мой основной посыл, что связка qt/C++ менее удобна чем kotlin/as. Хотя я честно пытался разобраться и что-то сделать.
"Если скинете примеры", что скидывать то? есть правила сборки qt приложения, они примерно такое, qml файлы декларируются в qrc файле, дальше при сборке весь контент перечисленный в qrc файле трансформируется в с++ код, прим в исходнике base64 текстом все бинарные фалы идут. Потом компилятор все собирает в бинарные файлы. Данные падают в секцию данных и доступны грубо говоря как глобальные переменные, обертка над ресурсной системой позволяет их доставить типа QFile("qrc://main.qml"), все. Для того что бы собрать проект нужна любая система сборки которая позволяет делать правила компиляции для файлов. Сборка qt/c++ приложения это последовательный вызов определенных утилит, которые делают определенные трансформации над данным и в итоге получается бинарный файл. Для того что бы это все руками не настраивать есть CMake он интегрируется в Gradle, и с помощью него же генерируется xcode проект где уже все настроено. Для того что бы писать на qt достаточно минимальных знаний cmake, после чего вы получите проект для MSVS, XCode, такие среды как CLion и QtCreator могут прямо открывать Cmake файлы и показывать из них проекты. Отладчик QML вы кроме QtCreator больше нигде не получите, но там особо отлаживать нечего, это статическая верстка и очень тривиальный код.
"для iOS в альфе сейчас" В 2012 году уже писал на Qt/QML большой коммерческий проект под Android.
"с coroutines приятнее и удобнее чем с потоками" так используйте они же есть уже в стандарте. Но операционка все равно оперирует потоками и семафорами, хотите быстро и полный контроль тут без шансов, вам нужно манипулировать самым близким уровнем к железу, а это с++.
"где мне или кодогенерация или gson распарсят json без особых стараний с моей стороны" Как выглядит парсинг JSON в с++:
namespace ns {
struct person { std::string name; std::string address; int age; };
}
NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE(person, name, address, age)
Сложно?
Для с++ сделали пакетный менеджер уже несколько лет, даже несколько есть конан, не использовал, есть vcpkg там 2200 библиотек. Есть такие библиотеки которые невозможно переписать на что-то иное, максимум вокруг с++ написать обертку в нужный язык, boost::graph, opencv, curl, jolt, box2, bullet, openimage, spirv, implot, sqlite3, libtorrent, tesseract, cgal. Каждая из этих библиотек это сотни человеколет работы, мы с вами вместе за всю жизни не напишем даже одну из этих библиотек, даже если всю жизнь будем работать только над этим.
Скорее всего для многих написали обертки в котлин для Qt даже есть обертка в питон. Но зачем нужно ждать пока кто-то сделает и зачем нужна обертка, если все равно основные библиотеки все на с++ написаны, бери исходник, даже WebRTC это с++ в основе, там без шансов быть чему-то иному.
Вы просто попробуйте решить задачу редактора любой игры прям на девайсе. Тут же столкнетесь с кучей проблем, если только у вас движок игры будет не на котлине, а на котлине он врядли будет, просто не потянут не по перфу не по сложности, все это тут же сожрет всю память сегментацией и будут дикие фризы во время сборки мусора, это кое как решили в юнити, и то, вместо фриза на кадр, просадки на несколько кадров. Мощь с++ не в том что он какой-то удобный или в его синтаксическом сахаре, его мощь в библиотеках которые решают любую задачу которые можете придумать и скорее всего они уже лежат на гитхабе и добавлены в vcpkg.
Хороший комментарий. Странно, что заминусовали
Раскройте мысль, пожалуйста, почему на JS в QML не стоит писать логику, с чем это связано? Сложность отладки?
Все просто, причина та же по которой с++ программисты не понимают зачем код покрывать 100% юнит тестами. Условно код программы можно разделить на:
1) код который выполняет задачу, как правило это какой алгоритм, у него есть входные данные и выходные
2) код который занимается доставкой данных из разных мест и отправкой результата в нужные места программы или обработки различных действий по результатам(показать попап, обновить БД или еще что).
Причем кода второго типа может быть достаточно много, но он простой, ошибиться можно разве что написав метод с ошибкой или имя переменной, нарушить типизацию или еще что, особенно это важно когда происходит какой-то рефакторинг. Так вот правильность имен переменных, правильность типов, совместимость данных большей частью проверит компилятор во время сборки. А JS исполняется строчка за строчкой и программа содержащая ошибку в JS коде запустится, но работать не будет и вы узнаете о ошибке в название метода или переменной во время работы приложения. Контролировать большое количество такого кода становится проблемой. Я не говорю что компилятор это магическая палка выручалка которая защитит вас от всего на свете, но она защитит вас от ошибки в именах методов, классов, функции, от несоответствия типов, а если применять мета программирование(шаблоны) еще много от всего.
И конечно же с++ код легче отлаживать, отладка с++ кода реализована наверно в любом компиляторе и на любой платформе, от программирования микроволновок, до микро сервисов(да на с++ то же можно писать микро сервисы, причем для этого есть очень крутые системы типа CORBA которым 100500 лет). Беда многих молодых программистов в том что они даже если слышали про CORBA открывают ее документацию смотрят минут 15 и закрывают, после чего начинают делать JRPC на с++, сталкиваются с тем что не понимают как быстро написать парсер json после чего идут смотрят на Go, где это пишут чуть ли не во введение и решают писать на нем. Я не против Go, это хороший язык, но неплохо было бы знать какие методы и решения использовались до того как появился Go, возможно там будет что-то более мощное и функциональное. Или еще пример, опять же про тот же json, есть такая библиотека simdjson, у нас получилось на современном компьютере парсить 3Гб json файлов за 150мс на нем. Кто-то может похвастаться таким перфом?
Или boost::graph, я половины этой библиотеки не понимаю, но даже то что понимаю позволяет решить все задачи на графах которые у меня когда либо возникали, причем достаточно компактными 15-20 строчками кода, да это будут очень странные 20 строчек кода, на которые посмотришь и такой, чё???? Но работать будет быстро и лучше ничего нет, вообще. Как и CGAL это наверно самая фундаментальная и комплексная геометрическая библиотека которая существует.
В данном случае мы использовали версию Qt 5.15.7, т.к. на ней основана Aurora IDE. В дальнейшем будем использовать более новые версии Qt, вероятнее всего 6.5, т.к. планируем выпускать приложение и под Android
Версия ide != версии sdk. На авроре версия sdk 5.6.3. Вроде в планах есть перейти на 5.15, про 6ую и речи нет.
Портировал декстоп приложение на Qt 5.15 на аврору. И там плюсовый код не так много надо было адаптировать, в отличие от qml. UI пришлось полностью с 0 писать.
Мы заранее продумали UI и практически не использовали компоненты из Sailfish Silica (использовали в основном стандартный qt quick). Поэтому адаптировать qml-код практически не нужно будет. Только избавиться от компонентов Page и SilicaListView.
А про версию мы в курсе, в планах для Android не использовать в принципе Аврора SDK, а использовать чистый Qt. Получается, для сборки будут использоваться два разных SDK: для "Авроры" — "Aurora SDK", для Android — "Qt 6 SDK". Пока это только все в планах, так что точно не можем сказать, какие трудности могут возникнуть.
А в чём смысл писать на 5.15 если Аврора его не поддерживает и не соберётся если в С++ используются новые конструкции/классы?
Разработка мобильного клиента СДУ «Приоритет» под ОС «Аврора» на фреймворке Qt