Можно сложить все это добро в Grid и тогда оно само перенесется, если не влезет. Или же руками руками навертеть логики разной степени безумности, типа:
Можно подружить одним из двух способов:
1. Добавив стили в html файл, т.е. как обычно;
2. Добавить в рантайме через stylesheet._addRule().
Но проблему разъезжания можно, и это наверное даже проще, решить декларативно через context.system.layoutType или context.width, что-то вроде:
font.pixelSize: context.system.layoutType <= System.MobileL? 14: 18;
На 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, на данном этапе, дружественно дополняют друг друга, неся изящество декларативного программирования в массы.
Задумывались слегка, но для html баттлнеки не в js коде(хотя время запуска с WebAssembly было бы лучше), а в том сколько работы ложится на браузер при изменении того или иного стиля.
Вообще, WebAssembly, наверняка, хорошо зайдет, если рендерить в канвас. Да, спасибо за идею.
Или завернуть во FlexBox и доверить браузеру. Или крутить display.
Но грид, в данном случае, наиболее изящнен.
1. Добавив стили в html файл, т.е. как обычно;
2. Добавить в рантайме через stylesheet._addRule().
Но проблему разъезжания можно, и это наверное даже проще, решить декларативно через context.system.layoutType или context.width, что-то вроде:
font.pixelSize: context.system.layoutType <= System.MobileL? 14: 18;
Если смотреть глобально, то и у pureqml, и у qmlweb, общая цель — облегчить разработку UI для современных платформ. Но подходы к достижению этой цели несколько разнятся.
QmlWeb ориентируется на полную совместимость с Qt QML, что безусловно имеет свои плюсы, в PureQML, мы тоже стараемся поддерживать совместимость, но скорее в одну сторону, чтобы можно было оригинальные Qt QML приложения запускать на PureQML. Поскольку браузеры, десктопные, мобильные или телевизионные заточены определенным образом, в PureQML используется ряд расширений для пущей производительности, если использовать их в разработке, то в обратную сторону, на оригинальном Qt QML, приложение не заработает, ну или придется кое что переписать. Ну или же не использовать расширения и есть кактус.
QmlWeb целится на HTML-based платформы. В PureQML HTML хоть и самая проработанная из платформ, но есть еще и нативная и планы по влезанию на Android/iOS по тому что принципу, что и, например, React Native.
Есть конечно же еще множество отличий, но это уже, больше, детали.
Я бы сказал, что PureQML и QmlWeb, на данном этапе, дружественно дополняют друг друга, неся изящество декларативного программирования в массы.
Задумывались слегка, но для html баттлнеки не в js коде(хотя время запуска с WebAssembly было бы лучше), а в том сколько работы ложится на браузер при изменении того или иного стиля.
Вообще, WebAssembly, наверняка, хорошо зайдет, если рендерить в канвас. Да, спасибо за идею.