LINUX.ORG.RU

История изменений

Исправление EXL, (текущая версия) :

Существенно модернизирован QML:

  1. Поддержка строгой типизации.
  2. Возможность компиляции QML в представление на C++ и машинный код.
  3. Перевод полной поддержки JavaScript в разряд опций (использование полнофункционального JavaScript-движка требует больших ресурсов, что мешает применению QML на таком оборудовании, как микроконтроллеры).

Это отличное решение, выкинуть вебню-клей в лице JavaScript’а из QtQuick и транспилировать логику сразу в быстрые крестцы. По мотивам этого треда, см. комментарий от @hobbit: Зачем нужен QML в Qt? (комментарий)

Получается они в итоге пришли к решениям, косвенно схожими с теми, что были озвучены нами в том топике. Осталось только понять, зачем нужно было вообще ковыряться с JavaScript.

В свете озвученных метаморфоз в QtQuick/QML сегодня очень смешно выглядят заявления всяких удалённых ЛОРовских клоунов-фанатиков с порваным задом по ссылке выше.

Специфичные для OpenGL классы перемещены из QtGui в отдельный модуль QtOpenGL.

Это что же получается, приложение-кнопка на Qt теперь не будет зависеть от OpenGL, как в Qt 5? qt 5.3 и qt 5.5 (комментарий)

Ой, а ЛОРовские клоуны-фанатики на всю критику по раздутию зависимостей фреймворка Qt 5 визжали «так надо! вы ничего не понимаете!». Внимание, риторический вопрос: будут ли ЛОР’овские Qt-фанатики теперь визжать «верните нам в QtGui зависимость от OpenGL»?

Это очень хорошо, что разработчки Qt – адекваты, а не какие-нибудь фракталы с ГСМ, прости-господи. И это отлично, что в Qt 6 начали исправлять архитектурные недостатки и жирность Qt 5, в котором была заявлена некая «модульность», а на деле если сравнивать с Qt 4 – размер приложения-кнопки вырос в два раза как раз за счёт подобного «мёртвого» хлама внутри QtGui.

Qt for Microcontrollers (MCU), для работы которого достаточно всего лишь 80 Кб ОЗУ в минимальной конфигурации

Интересно, а QString и QVector там полноценные? Это очень круто, использовать сахарок Qt для разработки под MCU и какой-то рутины вроде нормальных операций со стороками.

Поддержка CMake для сборки приложений Qt

Эх, очень жаль что этот выбор похожей на autocrap поделки сугубо политический и кошерный и свой собственный QBS не прижился в Qt, но получился настолько удобным, что на него даже сторонние программисты из Embedded-мирка обратили внимание: Создаю QBS плагин для VS Code (комментарий)

Печально, что на IT, как и на весь наш мир действуют одни и те же законы, из-за которых выигрывает не простое и приятное решение, а уродливое и неказистое: autotools, CMake, X.Org, PHP, etc.

Поддержка HiDPI

Так-то давно она была. Как минимум с Qt 5.6 нормально реализовали, но вроде как не для всех тем, а для Fusion. Улучшена, наверное?

@hobbit: Они таки убили неюникодные кодировки. Одной причиной использовать QString стало меньше. Притом, что файлы, использующие эти кодировки, у пользователей никуда не девались.

Соглашусь с тобой. Это может быть проблемой, если ты делаешь программу которая, например, читает какой-то специфический и древний файл. Или из определённой БД берёт строки в каком-нибудь там Win1251 или Win1252. Получается теперь чтобы манипуляции с такими сущностями производить (хотя бы конвертнуть их в приемлемый для фреймворка вид), нужно будет тянуть в свой Qt-проект какие-нибудь сторонние либы типа iconv, у которых с кросс-платформенностью не всё так радужно, как у Qt? Печальная ситуация, согласен.

Исправление EXL, :

Существенно модернизирован QML:

  1. Поддержка строгой типизации.
  2. Возможность компиляции QML в представление на C++ и машинный код.
  3. Перевод полной поддержки JavaScript в разряд опций (использование полнофункционального JavaScript-движка требует больших ресурсов, что мешает применению QML на таком оборудовании, как микроконтроллеры).

Это отличное решение, выкинуть вебню-клей в лице JavaScript’а из QtQuick и транспилировать логику сразу в быстрые крестцы. По мотивам этого треда, см. комментарий от @hobbit: Зачем нужен QML в Qt? (комментарий)

Получается они в итоге пришли к решениям, косвенно схожими с теми, что были озвучены нами в том топике. Осталось только понять, зачем нужно было вообще ковыряться с JavaScript.

В свете озвученных метаморфоз в QtQuick/QML сегодня очень смешно выглядят заявления всяких удалённых ЛОРовских клоунов-фанатиков с порваным задом по ссылке выше.

Специфичные для OpenGL классы перемещены из QtGui в отдельный модуль QtOpenGL.

Это что же получается, приложение-кнопка на Qt теперь не будет зависеть от OpenGL, как в Qt 5? qt 5.3 и qt 5.5 (комментарий)

Ой, а ЛОРовские клоуны-фанатики на всю критику по раздутию зависимостей фреймворка Qt 5 визжали «так надо! вы ничего не понимаете!». Внимание, риторический вопрос: будут ли ЛОР’овские Qt-фанатики теперь визжать «верните нам в QtGui зависимость от OpenGL»?

Это очень хорошо, что разработчки Qt – адекваты, а не какие-нибудь фракталы с ГСМ, прости-господи. И это отлично, что в Qt 6 начали исправлять архитектурные недостатки и жирность Qt 5, в котором была заявлена некая «модульность», а на деле если сравнивать с Qt 4 – размер приложения-кнопки вырос в два раза как раз за счёт подобного «мёртвого» хлама внутри QtGui.

Qt for Microcontrollers (MCU), для работы которого достаточно всего лишь 80 Кб ОЗУ в минимальной конфигурации

Интересно, а QString и QVector там полноценные? Это очень круто, использовать сахарок Qt для разработки под MCU и какой-то рутины вроде нормальных операций со стороками.

Поддержка CMake для сборки приложений Qt

Эх, очень жаль что этот выбор похожей на autocrap поделки сугубо политический и кошерный и свой собственный QBS не прижился в Qt, но получился настолько удобным, что на него даже сторонние программисты из Embedded-мирка обратили внимание: Создаю QBS плагин для VS Code (комментарий)

Печально, что на IT, как и на весь наш мир действуют одни и те же законы, из-за которых выигрывает не простое и приятное решение, а уродливое и неказистое: autotools, CMake, X.Org, PHP, etc.

Поддержка HiDPI

Так-то давно она была. Как минимум с Qt 5.6 нормально реализовали, но вроде как не для всех тем, а для Fusion.

@hobbit: Они таки убили неюникодные кодировки. Одной причиной использовать QString стало меньше. Притом, что файлы, использующие эти кодировки, у пользователей никуда не девались.

Соглашусь с тобой. Это может быть проблемой, если ты делаешь программу которая, например, читает какой-то специфический и древний файл. Или из определённой БД берёт строки в каком-нибудь там Win1251 или Win1252. Получается теперь чтобы манипуляции с такими сущностями производить (хотя бы конвертнуть их в приемлемый для фреймворка вид), нужно будет тянуть в свой Qt-проект какие-нибудь сторонние либы типа iconv, у которых с кросс-платформенностью не всё так радужно, как у Qt? Печальная ситуация, согласен.

Исходная версия EXL, :

Существенно модернизирован QML:

  1. Поддержка строгой типизации.
  2. Возможность компиляции QML в представление на C++ и машинный код.
  3. Перевод полной поддержки JavaScript в разряд опций (использование полнофункционального JavaScript-движка требует больших ресурсов, что мешает применению QML на таком оборудовании, как микроконтроллеры).

Это отличное решение, выкинуть вебню-клей в лице JavaScript’а из QtQuick и транспилировать логику сразу в быстрые крестцы. По мотивам этого треда, см. комментарий от @hobbit: Зачем нужен QML в Qt? (комментарий)

Получается они в итоге пришли к решениям, косвенно схожими с теми, что были в том топике. Осталось только понять, зачем нужно было вообще ковыряться с JavaScript.

В свете озвученных метаморфоз в QtQuick/QML сегодня очень смешно выглядят заявления всяких удалённых ЛОРовских клоунов-фанатиков с порваным задом по ссылке выше.

Специфичные для OpenGL классы перемещены из QtGui в отдельный модуль QtOpenGL.

Это что же получается, приложение-кнопка на Qt теперь не будет зависеть от OpenGL, как в Qt 5?

qt 5.3 и qt 5.5 (комментарий)

Ой, а ЛОРовские клоуны-фанатики на всю критику по раздутию зависимостей фреймворка Qt 5 визжали «так надо! вы ничего не понимаете!». Внимание, риторический вопрос: будут ли ЛОР’овские Qt-фанатики теперь визжать «верните нам в QtGui зависимость от OpenGL»?

Это очень хорошо, что разработчки Qt – адекваты, а не какие-нибудь фракталы с ГСМ, прости-господи. И это отлично, что в Qt 6 начали исправлять архитектурные недостатки и жирность Qt 5, в котором была заявлена «модульность» а на деле, если сравнивать с Qt 4 – размер приложения-кнопки вырос в два раза как раз за счёт подобного «мёртвого» хлама внутри QtGui.

Qt for Microcontrollers (MCU), для работы которого достаточно всего лишь 80 Кб ОЗУ в минимальной конфигурации

Интересно, а QString и QVector там полноценные? Это очень круто, использовать сахарок Qt внутри MCU для какой-то рутины вроде нормальных операций со стороками.

Поддержка CMake для сборки приложений Qt

Эх, очень жаль что этот выбор похожей на autocrap поделки сугубо политический и кошерный и свой QBS не прижился в Qt, но получился настолько удобным, что на него даже сторонние программисты из Embedded-мирка обратили внимание: Создаю QBS плагин для VS Code (комментарий)

Печально, что на IT, как и на весь наш мир действуют одни и те же законы, из-за которых выигрывает не простое и приятное решение, а уродливое и неказистое: autotools, CMake, X.Org, PHP, etc.

Поддержка HiDPI

Так-то давно была.

@hobbit: Они таки убили неюникодные кодировки. Одной причиной использовать QString стало меньше. Притом, что файлы, использующие эти кодировки, у пользователей никуда не девались.

Соглашусь с тобой. Это может быть проблемой, если ты делаешь программу которая, например, читает какой-то специфический и древний файл. Или из определённой БД берёт какой-нибудь там Win1251 или Win1252. Получается теперь чтобы манипуляции с такими сущностями производить (хотя бы конвертнуть их в приемлемый для фреймворка вид), нужно будет тянуть в свой Qt-проект какие-нибудь либы типа iconv, у которых с кросс-платформенностью не всё так радужно, как у Qt? Печальная ситуация, согласен.