Комментарии 25
Поэтому, через пару лет, когда мы с (другим) коллегой коротали вечер за пирожками в одном из кофешопов Амстердама
Что то не припомню я пирожков в Амстердамских кофешопах, разве что с мухаморчиками.
Или это сейчас так называется? :)
Между прочим после этих самых «пирожков» очень прет на умные мысли :)
Если эта статья хоть кому-то будет интересна, мы можем продолжить рассматривать наше видение QML
Конечно продолжайте!
Интересный проект. Продолжайте писать.
Правда некоторые примеры не работают
Еще интересует транслятор QML в C++, можно немного подробнее.
Правда некоторые примеры не работают
Еще интересует транслятор QML в C++, можно немного подробнее.
Спасибо за то что посмотрели, на эту тему с утра уже была буря в чятике, починят/починили уже, наши лучшие полтора программиста работают над этим!
Про C++, к сожалению, вся интеллектуальная собственность осталась в той корпорации, и у нас даже был зеленый свет на открытие частей, но мы так и не собрались, ну и там ничего интересного нет, оно просто достаточно аккуратно написано, имеет постоянный memory footprint, и не аллоцирует больше чем 8 мегабайт, вместе со всеми картинками и приложениями. :)
По идее, вы можете взять грамматику и промежуточное представление из нашего проекта. Но проблема смены языка в том, что весь рантайм придется полностью переписать, так как код во вставках станет c++. Но это, возможно, не такая уж и большая проблема. Мы использовали дополнительные native блоки, которые могли вставлять свое содержимое в код результирующего класса или прямо в header/cpp файл.
В этот раз мы решили зайти с другой стороны. Сделать layout-независимый javascript-движок, который может исполнятся в нашем нативном браузере (не-html, см. скриншот ниже).
Попутно мы исследуем возможность компиляции js в бинарный кросс-платформенный код и свою библиотеку исполнения js, и мы даже некоторых успехов уже достигли, когда будет используемо, выложим в открытый доступ.
Про C++, к сожалению, вся интеллектуальная собственность осталась в той корпорации, и у нас даже был зеленый свет на открытие частей, но мы так и не собрались, ну и там ничего интересного нет, оно просто достаточно аккуратно написано, имеет постоянный memory footprint, и не аллоцирует больше чем 8 мегабайт, вместе со всеми картинками и приложениями. :)
По идее, вы можете взять грамматику и промежуточное представление из нашего проекта. Но проблема смены языка в том, что весь рантайм придется полностью переписать, так как код во вставках станет c++. Но это, возможно, не такая уж и большая проблема. Мы использовали дополнительные native блоки, которые могли вставлять свое содержимое в код результирующего класса или прямо в header/cpp файл.
В этот раз мы решили зайти с другой стороны. Сделать layout-независимый javascript-движок, который может исполнятся в нашем нативном браузере (не-html, см. скриншот ниже).
Попутно мы исследуем возможность компиляции js в бинарный кросс-платформенный код и свою библиотеку исполнения js, и мы даже некоторых успехов уже достигли, когда будет используемо, выложим в открытый доступ.
Просто суперкрутая идея, я постоянно думаю о том что все современный веб стек это полнейший дурдом и на его месте должен быть нормальный язык разметки интерфейсов.
Я тоже постоянно думаю об этом, почему веб пошел своим путем, а не путем даже java.awt еще тех древних времен (ответ конечно есть, но я им не очень удовлетворен). Прочитав статью (признаюсь, знал об этой теме ранее, хотя отношения к ней не имею) я что-то не подумал об этом. Наверное потому что на Qt/QML практического ничего ни разу не писал. Вечером всё установлю, поверчу в руках.
Если вам нужна будет помощь, вы можете присоединиться к нашей группе в телеграмме, обновил пост, поставил ссылку на группу.
да, на сыром html/js писать можно убиться, слишком низкоуровнево это всё сейчас стало, нужно поддерживать миллион вещей и бороться с разными особенностями, например невозможностью что-то выровнять по вертикали, без хаков, ну и миллион других вещей.
потому что они для этого не предназначались изначально, всё делалось для гипертекстового веба, но постепенно обрастало костылями, сейчас про гипертекст все забыли, основной веб это приложения, а браузер стал виртуальной машиной для этих приложений.
В html с помощью элемента div, джаваскрипта и классов стилей (!) делают компоненты графического интерфейса, которые по идее должны быть стандартными.
А непонятно откуда взявшийся javascript из инструмента для выведения alert окошек превратился в что-то типа языка программирования, хотя и отягощённого родовыми травмами.
Всё это печально, лучше бы питон и qml былы на их месте.
В html с помощью элемента div, джаваскрипта и классов стилей (!) делают компоненты графического интерфейса, которые по идее должны быть стандартными.
А непонятно откуда взявшийся javascript из инструмента для выведения alert окошек превратился в что-то типа языка программирования, хотя и отягощённого родовыми травмами.
Всё это печально, лучше бы питон и qml былы на их месте.
Вашей смелости и амбициозности остается только позавидовать.
Большое спасибо за статью и код, весьма любопытно.
Программирование по хардкору — это очень круто.
Но все-таки остаются вопросы.
Прежде всего поддержу комментатора выше: очень интересует трансляция QML в С++.
Делали ли вы какое-то сравнение с родным QtQuickCompailer-ом?
Как прогнозы относительно существующей и грядущей генерации кэша?
Планируете ли Вы продолжать крестовые походы в этом направлении?
Большое недоумение вызывает выбор в пользу HTML\JS и всей остальной обвязки.
Вы начинали с того, что вывели в мир новую связку QML+С++(вместоJS), я так понимаю в 10-м году это был еще Qt Quick 1.0. В результате QML-код не стал компилироваться в полноценный бинарник, а добавилась еще одна прослойка интерпретации\трансляции. То есть то, о чем сейчас много шумят: между нативным фреймворком и кросплатформенным Вы выбрали кросплатформенный.
Почему? Поправьте, если я где-то неправильно понял.
Хотелось бы еще узнать о том, как решен\решается вопрос с Native Look & Feel.
Если говорить о телевизорах, те же Android-TV и AppleTV, то они таки имееют определенные особенности.
Буду очень признателен, если поможете найти это в примерах.
Касательно производительности. Очень хочется больше Цифръ(!). Очень сложно поверить, что транслирование в HTML дало такой существенный прирост (говорю о дне сегодняшнем) по сравнению с QML.
У ребят из SpbTv имеется нативный низкоуровненый фремворк с поддержкой того же Qt: в этой обвязке они запускают стримовое видео на старых чернобелых Palm-ах, а там всего около 10 Мб памяти.
Хотелось бы также узнать сколько сейчас разработчиков трудятся над проектом?
Какие у вас перспективы? Простите, если вопрос лишний.
Еще раз спасибо за статью и код.
Надеюсь это не последний рассказ.
я выше немного написал про c++
Сравнение с оригинальным qtquickcompiler'ом не делали, у нас главный сравнитель была та железка на armv5, по мощности как древние фичернокии, но разрешение побольше. Мы не использовали код Qt, всё было свое, включай транспайлер в C++. Изначально мы транслировали Qml в c++ и использовали нативный код, без всяких прослоек. Сейчас мы делаем по другому, т.к. вектор немного изменился, а выбор в пользу html был сделан только потому что это позволит сразу же расширить количество платформ на браузеры, мобильные браузеры, и телевизоры. В большинстве smartTV сейчас html/js API, а если возиться с нативом, то можно очень быстро устать, и вряд ли вендоры позволяют так легко нативные куски запускать на телеках.
Вопрос с Native Look & Feel можно решить двумя способами: вы/мы можем создать qml компоненты вокруг нативных контролов, или эмулировать стилями, как это делает Qt. AppleTV мы пока не поддерживаем, к сожалению. У нас пока не было задачи такой, мне кажется в телевизоре вектор больше на создание индивидуального стиля для приложения, чтобы он соответствовал корпоративному стилю, и т.п.
Цифры я к сожалению, не могу предоставить, я уже больше года не работаю в той корпорации, но memory footpring ui, сравнимого с телефонным, лаунчер, менюшки, приложения простые, потреблял постоянное количество памяти, устанавливаемое заранее, у нас было 8Мб.
Разработчика сейчас всего три, включая меня. Перспектив никаких нет, ахаха. Мы просто используем это в небольших коммерческих и некомерческих проектах, ну и для баловства тоже используем.
Сравнение с оригинальным qtquickcompiler'ом не делали, у нас главный сравнитель была та железка на armv5, по мощности как древние фичернокии, но разрешение побольше. Мы не использовали код Qt, всё было свое, включай транспайлер в C++. Изначально мы транслировали Qml в c++ и использовали нативный код, без всяких прослоек. Сейчас мы делаем по другому, т.к. вектор немного изменился, а выбор в пользу html был сделан только потому что это позволит сразу же расширить количество платформ на браузеры, мобильные браузеры, и телевизоры. В большинстве smartTV сейчас html/js API, а если возиться с нативом, то можно очень быстро устать, и вряд ли вендоры позволяют так легко нативные куски запускать на телеках.
Вопрос с Native Look & Feel можно решить двумя способами: вы/мы можем создать qml компоненты вокруг нативных контролов, или эмулировать стилями, как это делает Qt. AppleTV мы пока не поддерживаем, к сожалению. У нас пока не было задачи такой, мне кажется в телевизоре вектор больше на создание индивидуального стиля для приложения, чтобы он соответствовал корпоративному стилю, и т.п.
Цифры я к сожалению, не могу предоставить, я уже больше года не работаю в той корпорации, но memory footpring ui, сравнимого с телефонным, лаунчер, менюшки, приложения простые, потреблял постоянное количество памяти, устанавливаемое заранее, у нас было 8Мб.
Разработчика сейчас всего три, включая меня. Перспектив никаких нет, ахаха. Мы просто используем это в небольших коммерческих и некомерческих проектах, ну и для баловства тоже используем.
И ещё немного написал. Скажите, зачем вам qml-c++?
А вы не задумывались о связке QML/WebAssembly. Мне кажется очень перспективная тема.
А вы не смотрели на qmlweb?
Присоединяюсь к просьбе о подробностях QML C++.
Ну там в целом ничего интересного про c++, в целом схема такая же:
Мне больше интересно, зачем вам нужен декларативный C++, мы делали из бедности, т.к. Qt не лезло.
Мы сейчас ведем разработку ультра-лайтового js, который залезет везде где есть c++, без депенденсов, и вроде даже каких-то результатов добились. 10-15 раз меньше памяти, работает 20-120% скорости v8 на arm :) 300к либа, пока без рантайма (но с практически готовым языком)
- qml расширен native { } вставками в тело компоненты и тело файла, если native мимо компоненты, чтобы можно было легко колбасить нативные компоненты, например:
Image { native { qml::DiscardableSurfaceHolder _image } }
большая часть рантайма написана на таком qml, чтобы долго не возиться - парсер парсит, создается промежуточное представление, генерятся классы 1-в-1 компонента-класс, практически как бы вы руками писали
class Rectangle : Item { qml::Property<int> x; qml::Property<int> y; };
- …
- profit!
Мне больше интересно, зачем вам нужен декларативный C++, мы делали из бедности, т.к. Qt не лезло.
Мы сейчас ведем разработку ультра-лайтового js, который залезет везде где есть c++, без депенденсов, и вроде даже каких-то результатов добились. 10-15 раз меньше памяти, работает 20-120% скорости v8 на arm :) 300к либа, пока без рантайма (но с практически готовым языком)
На qmlweb — смотрели, и когда-то, на заре хотели его использовать, но все таки решили сделать свой.
Если смотреть глобально, то и у pureqml, и у qmlweb, общая цель — облегчить разработку UI для современных платформ. Но подходы к достижению этой цели несколько разнятся.
QmlWeb ориентируется на полную совместимость с Qt QML, что безусловно имеет свои плюсы, в PureQML, мы тоже стараемся поддерживать совместимость, но скорее в одну сторону, чтобы можно было оригинальные Qt QML приложения запускать на PureQML. Поскольку браузеры, десктопные, мобильные или телевизионные заточены определенным образом, в PureQML используется ряд расширений для пущей производительности, если использовать их в разработке, то в обратную сторону, на оригинальном Qt QML, приложение не заработает, ну или придется кое что переписать. Ну или же не использовать расширения и есть кактус.
QmlWeb целится на HTML-based платформы. В PureQML HTML хоть и самая проработанная из платформ, но есть еще и нативная и планы по влезанию на Android/iOS по тому что принципу, что и, например, React Native.
Есть конечно же еще множество отличий, но это уже, больше, детали.
Я бы сказал, что PureQML и QmlWeb, на данном этапе, дружественно дополняют друг друга, неся изящество декларативного программирования в массы.
Если смотреть глобально, то и у pureqml, и у qmlweb, общая цель — облегчить разработку UI для современных платформ. Но подходы к достижению этой цели несколько разнятся.
QmlWeb ориентируется на полную совместимость с Qt QML, что безусловно имеет свои плюсы, в PureQML, мы тоже стараемся поддерживать совместимость, но скорее в одну сторону, чтобы можно было оригинальные Qt QML приложения запускать на PureQML. Поскольку браузеры, десктопные, мобильные или телевизионные заточены определенным образом, в PureQML используется ряд расширений для пущей производительности, если использовать их в разработке, то в обратную сторону, на оригинальном Qt QML, приложение не заработает, ну или придется кое что переписать. Ну или же не использовать расширения и есть кактус.
QmlWeb целится на HTML-based платформы. В PureQML HTML хоть и самая проработанная из платформ, но есть еще и нативная и планы по влезанию на Android/iOS по тому что принципу, что и, например, React Native.
Есть конечно же еще множество отличий, но это уже, больше, детали.
Я бы сказал, что PureQML и QmlWeb, на данном этапе, дружественно дополняют друг друга, неся изящество декларативного программирования в массы.
whoozle Я тут случайно наткнулся на весьма интересный проект — ENAML, он умеет кроссплатформенный гуй, но вот веба похоже не имеет, хотя под капотом там есть Qt, может можно к ним прикрутить PureQML и получить ещё и веб?
функциональности получения данных\событий из внешних источников для qml\javascript
а-ля Integrating QML and C++ не предусмотрено?
а-ля Integrating QML and C++ не предусмотрено?
Есть, но возможно не с той стороны, которой вы ожидаете. У нас есть бэкенд, который позволяет предоставить со стороны js окружения реализацию простых примитивов, типа Text, Image, Rectangle и обрабатывать их стили.
Платформа называется pure.femto, можно сгенерировать код под неё используя либо ключ -p , либо прописав в манифесте.
Пример реализации на java под Android есть в
github.com/pureqml/qmlcore-android/tree/master/app/src/main/java/com/pureqml/android/runtime
Аналогично можно пробросить любые объекты которые вы хотите.
Платформа называется pure.femto, можно сгенерировать код под неё используя либо ключ -p , либо прописав в манифесте.
Пример реализации на java под Android есть в
github.com/pureqml/qmlcore-android/tree/master/app/src/main/java/com/pureqml/android/runtime
Аналогично можно пробросить любые объекты которые вы хотите.
всё таки я должен уточнить вопрос.
речь идёт о классическом клиент-серверном взаимодействии — фронтенд на qml\javascript, бакенд на чём придётся.
я увидел только автономное выполнение javascript(qml\javascript) на браузерах платформ(html5,web...), без бакенда.
речь идёт о классическом клиент-серверном взаимодействии — фронтенд на qml\javascript, бакенд на чём придётся.
я увидел только автономное выполнение javascript(qml\javascript) на браузерах платформ(html5,web...), без бакенда.
Я не очень понимаю в чем вопрос. Наш qml вообще никак пользователя не ограничивает, мы можете подключать любые модули, и использовать любые API для работы с чем угодно. Хотите XHR, хотите fetch(), в итоге получается обычный Javascript код, который может свободно использовать все возможности окружения.
Backend и интеграцию с ним мы не предоставляем, все делают по разному, обобщить практически невозможно. Вы можете использовать любые современные технологии для бэкенда.
У нас есть в roadmap обобщение простых способов работы с REST (CRUD), и других эндпоинтов, как SSE, WS, но пока не очень понятно как сделать так, чтобы угодить всем.
Backend и интеграцию с ним мы не предоставляем, все делают по разному, обобщить практически невозможно. Вы можете использовать любые современные технологии для бэкенда.
У нас есть в roadmap обобщение простых способов работы с REST (CRUD), и других эндпоинтов, как SSE, WS, но пока не очень понятно как сделать так, чтобы угодить всем.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я перестал бояться и переизобрел QML