Я пользовался может четыре года назад, через официальный андроид-клиент. Тоже удалили.
Стыд и срам, у меня там все контакты из детства и вообще :(

Я не очень понимаю в чем вопрос. Наш qml вообще никак пользователя не ограничивает, мы можете подключать любые модули, и использовать любые API для работы с чем угодно. Хотите XHR, хотите fetch(), в итоге получается обычный Javascript код, который может свободно использовать все возможности окружения.

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

У нас есть в roadmap обобщение простых способов работы с REST (CRUD), и других эндпоинтов, как SSE, WS, но пока не очень понятно как сделать так, чтобы угодить всем.

Есть, но возможно не с той стороны, которой вы ожидаете. У нас есть бэкенд, который позволяет предоставить со стороны js окружения реализацию простых примитивов, типа Text, Image, Rectangle и обрабатывать их стили.

Платформа называется pure.femto, можно сгенерировать код под неё используя либо ключ -p , либо прописав в манифесте.

Пример реализации на java под Android есть в
github.com/pureqml/qmlcore-android/tree/master/app/src/main/java/com/pureqml/android/runtime

Аналогично можно пробросить любые объекты которые вы хотите.

простите, какого именно кризиса? где?

в манче свой, а тут везде йоркширский, owt, nowt, scran, луф и бус.

Leeds пока ещё держится! Привет!

Есть золотое правило: «не имейте дел с мудаками» (я бы добавил «и с русскими»). Вы бы погуглили, что это за xored и кто такой Платов, прежде чем подписываться под чем-либо. Не стоит ехать только затем чтобы уехать, имеет смысл тщательно выбирать компанию, в которой можно будет проработать первые два-три года, и у которой есть опыт импорта сотрудников.
(Сам понауехал в западный йоркшир, суровые британские севера, без особенных приключений)

Я видимо что-то не понимаю, в qml обработчики событий задаются так же как у нас. Просто мы синтаксически не разделяем эти две декларации, что позволяет задавать методы, если они не с onXyz начинаются. Визуально путаницы никакой нет.

reset : { this.model.reset() }
update: { this.model.update(this.range) }

Я, честно признаюсь, не исследовал оригинальный qml, насколько он строг в этом смысле.

Разве? Вот ссылка на qml-ный синтаксис.

Мы поддерживаем и простой вариант, типа

method: { }

, с одной лишь оговоркой, что

function onFoo() { }

это метод onFoo, а не обработчик сигнала.

И ещё немного написал. Скажите, зачем вам qml-c++?

Ну там в целом ничего интересного про c++, в целом схема такая же:

1. qml расширен native { } вставками в тело компоненты и тело файла, если native мимо компоненты, чтобы можно было легко колбасить нативные компоненты, например:
   

   Image
   { 
     native
     {
        qml::DiscardableSurfaceHolder _image
     }
   }
   

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

   class Rectangle : Item
   { 
     qml::Property<int> x;
     qml::Property<int> y;
   };
   

   
   
3. …
4. profit!

Мне больше интересно, зачем вам нужен декларативный C++, мы делали из бедности, т.к. Qt не лезло.

Мы сейчас ведем разработку ультра-лайтового js, который залезет везде где есть c++, без депенденсов, и вроде даже каких-то результатов добились. 10-15 раз меньше памяти, работает 20-120% скорости v8 на arm :) 300к либа, пока без рантайма (но с практически готовым языком)

я не узнал тебя в гриме! :D

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

да, на сыром html/js писать можно убиться, слишком низкоуровнево это всё сейчас стало, нужно поддерживать миллион вещей и бороться с разными особенностями, например невозможностью что-то выровнять по вертикали, без хаков, ну и миллион других вещей.

я выше немного написал про c++

Сравнение с оригинальным qtquickcompiler'ом не делали, у нас главный сравнитель была та железка на armv5, по мощности как древние фичернокии, но разрешение побольше. Мы не использовали код Qt, всё было свое, включай транспайлер в C++. Изначально мы транслировали Qml в c++ и использовали нативный код, без всяких прослоек. Сейчас мы делаем по другому, т.к. вектор немного изменился, а выбор в пользу html был сделан только потому что это позволит сразу же расширить количество платформ на браузеры, мобильные браузеры, и телевизоры. В большинстве smartTV сейчас html/js API, а если возиться с нативом, то можно очень быстро устать, и вряд ли вендоры позволяют так легко нативные куски запускать на телеках.

Вопрос с Native Look & Feel можно решить двумя способами: вы/мы можем создать qml компоненты вокруг нативных контролов, или эмулировать стилями, как это делает Qt. AppleTV мы пока не поддерживаем, к сожалению. У нас пока не было задачи такой, мне кажется в телевизоре вектор больше на создание индивидуального стиля для приложения, чтобы он соответствовал корпоративному стилю, и т.п.

Цифры я к сожалению, не могу предоставить, я уже больше года не работаю в той корпорации, но memory footpring ui, сравнимого с телефонным, лаунчер, менюшки, приложения простые, потреблял постоянное количество памяти, устанавливаемое заранее, у нас было 8Мб.

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

Спасибо за то что посмотрели, на эту тему с утра уже была буря в чятике, починят/починили уже, наши лучшие полтора программиста работают над этим!

Про C++, к сожалению, вся интеллектуальная собственность осталась в той корпорации, и у нас даже был зеленый свет на открытие частей, но мы так и не собрались, ну и там ничего интересного нет, оно просто достаточно аккуратно написано, имеет постоянный memory footprint, и не аллоцирует больше чем 8 мегабайт, вместе со всеми картинками и приложениями. :)

По идее, вы можете взять грамматику и промежуточное представление из нашего проекта. Но проблема смены языка в том, что весь рантайм придется полностью переписать, так как код во вставках станет c++. Но это, возможно, не такая уж и большая проблема. Мы использовали дополнительные native блоки, которые могли вставлять свое содержимое в код результирующего класса или прямо в header/cpp файл.

В этот раз мы решили зайти с другой стороны. Сделать layout-независимый javascript-движок, который может исполнятся в нашем нативном браузере (не-html, см. скриншот ниже).

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

Что то не припомню я пирожков в Амстердамских кофешопах

space cake ;)

Я люблю perf, он крутой.
Простите за оффтоп, есть ли какие-то планы по поддержке paypal в качестве платежной системы? платить из англии это боль.