Я для статической сборки под винду даже мини-инструкции писал

Кстати я для статической сборки некоторых приложений под Windows делал так:

1. Ставил MSYS2

2. Набирал там что-то вроде pacman -S qt5-static gcc g++ make

3. Затем qmake CONFIG+=release app.pro && make -j18, qmake при этом должен быть тот что из /qt5-static.

4. Забирал profit.

Это затаскивает УЖЕ собранную статически Qt, я правильно понял?

Да, без нудного компиляния на три часа. Но с нудным выкачиванием пакета объёмом 1GB и разворачиванием этого архива в ~6-8GB на диске.

https://packages.msys2.org/package/mingw-w64-i686-qt5-static?repo=mingw32
https://packages.msys2.org/package/mingw-w64-x86_64-qt5-static?repo=mingw64

Единственный минус – релизится сборка не сразу, нужно ждать недельку-две до появления новой статической версии после официального релиза Qt.

Годно! Хорошо, что Qt живёт, один из самых приятных инструментов разработки.

Кроме того, я сейчас немного погуглил — они, похоже, одумались, архивы вновь качаются без регистрации и SMS. Но инструкция по комплексной сборке из гита всё равно была бы полезна.

Ну хотя бы архивы доступны - уже неплохо.

Новые версии все доступны, про это речи и не было. Для коммерческих версий, LTS релизы.

А исходный код LTS релизов доступен без подписки?

Нет.

https://www.qt.io/blog/qt-offering-changes-2020

Строгую типизацию кстати так и не завезли, к сожалению. Планируют где-то в одном из 6.x добавить.

Кутешникам бы сделать ещё какую-нибудь лицензию для инди-разработчиков…

Так это же и есть лицензия для индивидуалов:

this license was restricted to companies with a yearly revenue and funding of less than $100 000.

И только недавно стало возможным вдвоём-втроём работать:

Now, based on your feedback, we have changed the limit to $250 000.

На малый бизнес как-то не тянет. Не в СНГ же сидит Qt Company.

для работы которого достаточно всего лишь 80 Кб ОЗУ

Надеюсь Плазму 6 до этих системных требованиях оптимизируют.

Надеюсь Плазму 6 до этих системных требованиях оптимизируют.

Да, было бы неплохо :)

Ещё бы input/output на встроенную память был бы минимален.

А также чтобы в software render режиме работал не хуже TDE.

Еще чтобы Xorg поддерживал.

Вот тогда заживем! :)

Как скоро портируют на «Эльбрус»?

Как только он станет кому-то нужен.

Как скоро портируют на «Эльбрус»?

Вдруг не тролль?

LCC для Эльбрус поддерживает C++17 частично, если подмножества хватит для Qt 6 - будет работать. CMake на Эльбрусе прекрасно себе работает. По крайней мере последние версии Qt 5 на Эльбрусе работают не плохо, тестировал лично. Работает там и PyQt5

Хотелось бы пощупать qml под android, но без offline инсталлятора это будет проблематично (

Хотелось бы пощупать qml под android, но без offline инсталлятора это будет проблематично (

Щупал пятерку, очень даже норм.

Qt 6.0 пока не поддерживает статичную сборку, т.е. использовать можно последнюю LTS 5.15.2

Добавлена подсистема QProperty, обеспечивающая бесшовную интеграцию QML в исходный код на языке C++

Лучше бы добавили опцию: скомпилить бинарь и выкинуть скрипты QML.

Единый интерфейс аппаратного рендеринга с поддержкой Direct 3D, Metal, Vulkan и OpenGL

Отрисовка 2D и 3D графики объединена в единый графический стек

Как в этих всех «интерфейсах» реализована защита исполняемого на GPU кода и памяти GPU?

Разработчики заявляют что Qt 6 не готов для десктопа до выхода версии Qt 6.2 LTS. В Qt 6.0 не хватает многих важных модулей:

• Qt Multimedia
• Qt WebEngine
• Qt WebSockets
• Qt WebView

Ссылка.

Понятно, как обычно, Qt6.0 != Qt6 :)

не слишком ли тяжело для mcu? stm вродь как touchGFX двигает для гуи

А исходный код LTS релизов доступен без подписки?

Нет.

Тут вообще-то, надо бы уточнять. Тебя же человек спросил про настоящее время, а не про будущее. Что там будет с LTS Qt6 - посмотрим, как они появятся. А текущая LTS — это 5.15. Идём и видим:

https://download.qt.io/archive/qt/5.15/

Тут всё есть. И одним архивом, и частями.

Ссылка доступна без регистрации. А статья, ссылку на которую ты привёл — это пока намерения.

Вот если появится Qt 5.15.3 в открытом доступе, то тогда будет о намерениях.

6.2 LTS тоже появится в исходниках. И до выхода 6.3 тоже будут обновления доступны. Может 6.2.1 или 6.2.2. А вот будущие патчи вряд ли будут доступны.

This means that we will handle Qt 5.15 in the same way as e.g. 5.13 or 5.14 for open source users.

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

Внимание, вопрос – вы вендузятник или ксоргоретроград или в wayland кнопку libastral-ом рендерить собрались?

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

Ага. Прочитали ваши коменты в том треде, не иначе.

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

Эх, очень жаль

А вот твоё мнение про cmake не прочитали.

Внимание, вопрос – вы вендузятник или ксоргоретроград или в wayland кнопку libastral-ом рендерить собрались?

Где QtWayland и где QtGui?

На одной и той же системе должны стоять, если хочешь «кнопку» запустить.

Но не опенгл же. Совсем с ума посходили.

это твоя задняя мысль? (c) кин-дза-дза

Ну ок, в завтрашнем дне кнопку под wayland будет вулкан рисовать (скорее всего). Но когда OpenGL «привязывали» к QtGUI, OpenGL не имел альтернатив для гуев.

Ну вот в чём соглашусь, так это в том, что классы QOpenGL* имеют крайне опосредованное отношение к гуям. Кстати как и QVector3D, QMatrix4x4 – этим имхо место или в отдельном «математическом» модуле или, если таковой не планируется, в Core.

Только вот EXL то бугуртит именно с линковки с -lgl ;)

Я возражаю, что раз на современном линуксе (основной, я полагаю, платформе для Qt) без использования OpenGL было невозможно нарисовать кнопку во времена пятый кутей, то и линковка с OpenGL не «лишняя» и не «жор».

Уменьшилось ли потребление оперативной памяти на десктопе? Пятые кеды у меня тормозят на 5 Гб оперативки.

всего лишь 80 Кб ОЗУ в минимальной конфигурации

80 Кб ОЗУ

всего

в минимальной конфигурации

Чот дофига.

Только вот EXL то бугуртит именно с линковки с -lgl ;)

Не, я именно бугурчу от того, что QtGui завязан на OpenGL. То бишь без GL-хедеров и либы даже собрать ничего не получится. И при использовании того же XCB-backend’а ты обязательно зависел от OpenGL, хотя в приложении оно никак не использовалось. Пять-семь лет назад (посты как раз той давности по моим ссылкам) это было актуально, особенно учитывая что в Qt 4 такого прикола не было. В Windows, кстати, аналогичная ситуация при использовании GDI-backend’а была.

Ну вот в чём соглашусь, так это в том, что классы QOpenGL* имеют крайне опосредованное отношение к гуям.

Это чисто архитектурная проблема Qt 5, на которую я и жаловался раньше. Ну не должен Gui-модуль завязываться на какое-то определённое API, будь то XCB, OpenGL, Vulkan и т. д. В Qt 4 была завязка на XCB в QtGui (там QtGui включал в себя QtWidgets), а в Qt 5 – взяли и зачем-то завязались на OpenGL{ES}. А ведь там и QPA есть и возможность выделить всё в QtOpenGL, как в Qt 4, тоже была.

Кстати как и QVector3D, QMatrix4x4 – этим имхо место или в отдельном «математическом» модуле или, если таковой не планируется, в Core.

Да. Странно, что они вообще попали в QtGui.

Да вы точно ебнулись. qbittorent на Qt 4 стартовал у меня секунду-две. Теперь ему надо секунд 10 чтобы окно отрисовать. Было: требуется процессор не менее... Стало: требуется процессор не менее, видеокарта не менее.

Нафига?

Лучше 10 секунд инициализировать графический ускоритель, чтобы потом за 0,1 секунды отрисовать. (Чем сделать это за 1 секунду но сразу.) По мотивам «Крылья, ноги и хвосты».

в Qt 5 – взяли и зачем-то завязались на OpenGL{ES}.

Затем, что в то время xcb уже устаревал, а рендерить гуй вулканом находилось в категории «немыслимого». Соглашусь, что при живом то QPA, завязываться на конкретное графическое апи – решение кошмарное с архитектурной точки зрения. Но на практике (OpenGL{ES} по сути единственный путь) в то время было норм.

из-за которых выигрывает не простое и приятное решение

Ты ещё пожалуйся что мир устроен не по механике Ньютона.

https://t.me/Haiku_mus_RU_chat/3157 завезли даже в OS Haiku

Бэкэнд это конец сзади. Выглядит ужасно

В квотезы!

Achtung!

EXL обозвали ксоргоретроградом, все в машину, срочно!

Он собрался кнопку рендерить не OpenGL-ем, а xcb. Кто он после этого?

Соглашусь, что при живом то QPA, завязываться на конкретное графическое апи – решение кошмарное с архитектурной точки зрения.

Именно так. Кошмарное архитектурное решение, раздувшее Qt 5.

В Qt 6 всё сделали правильно, абстрагировавшись от каких-либо GAPI.

Он собрался кнопку рендерить не OpenGL-ем, а xcb. Кто он после этого?

Речь идёт не только о XCB, но и о CocoaAPI и GDI. Насколько я помню, приложения-кнопки на Qt 5 под macOS и Windows тоже требовали OpenGL, но использовали его лишь в каком-нибудь QtQuick. Тот же macdeployqt и windeployqt раздували тебе дистрибутив программы зависимостями ANGLE и opengl32sw.{dylib,dll}.

То бишь 99.99% времени классы QOpenGL* валялись мёртвым грузом.

я что то не совсем понял как добавлять файл и каталог , создал проект под управлением cMake и внезапно в трее не смог добавить ни файл ни каталог, приофигел от такого посыла, пересоздал в qmake и все норм.

В Qt Creator в дереве проектов вызови контекстное меню НЕ У ИМЕНИ ПРОЕКТА, а У ИМЕНИ ЦЕЛИ. Но это ведь функционал Qt Creator, а не библиотеки.

я что то не совсем понял как добавлять файл и каталог , создал проект под управлением cMake и внезапно в трее не смог добавить ни файл ни каталог, приофигел от такого посыла, пересоздал в qmake и все норм.

В Qt Creator в дереве проектов вызови контекстное меню НЕ У ИМЕНИ ПРОЕКТА, а У ИМЕНИ ЦЕЛИ. Но это ведь функционал Qt Creator, а не библиотеки.

Это диалог пятизвёздочных.

Д.ы, б.ь (c) Лавров

И когда ждать новых кед?

Поддерживаю по всем пунктам кроме наезда на CMake. Он какой-никакой универсальный стандарт. Уж лучше его чем зоопарк.

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