Ларс Кнолл (Lars Knoll), создатель движка KHTML, руководитель проекта Qt Project и технический директор компании Qt Company,рассказал (https://blog.qt.io/blog/2019/08/07/technical-vision-qt-6/) о планах создания следующей значительной ветки фреймворка Qt. Qt 6 будет развиваться с оглядкой на обеспечение совместимости с Qt 5, но намеченные архитектурные изменения невозможно будет реализовать без потери определённого уровня совместимости. Для сглаживания перехода некоторые намеченные на Qt 6 возможности планируется в сокращённом виде включить в состав выпусков Qt 5.14 и Qt 5.15 LTS. После завершения формирования функциональности ветки Qt 5.14 разработка будет сфокусирована на подготовке выпуска Qt 6, который ожидается в конце 2020 года.
Среди основных целей для следующей значительной ветки называется приведение функциональности в соответствие с требованиями 2020 года, проведение чистки кодовой базы и упрощение сопровождения проекта. Ожидаемые изменения:- Существенная модернизация QML:
- Поддержка строгой типизации.
- Возможность компиляции QML в представление на C++ и машинный код.
- Перевод полной поддержки JavaScript в разряд опций (использование полнофункционального JavaScript-движка требует больших ресурсов, что мешает применению QML на таком оборудовании, как микроконтроллеры).
- Отказ от версионирования в QML.
- Унификация структур данных, дублирующихся в QObject и QML (позволит сократить потребление памяти и ускорить запуск).
- Уход от генерации структур данных во время выполнения в пользу генерации во время компиляции.
- Скрытие внутренних компонентов через использование приватных методов и свойств.
- Улучшенная интеграция с инструментами разработки для диагностики ошибок во время компиляции и рефакторинга;- Добавление нового абстрактного слоя Rendering Hardware Interface (RHI) для обеспечение возможности бесшовного использования различных графических API, включая OpenGL, Vulkan, Metal и Direct 3D (раньше Qt был завязан только на OpenGL). На использование RHI будет переведена вся имеющаяся инфраструктура рендеринга, включая QPainter, Qt Quick Scenegraph и Qt3D. Также планируется добавить модуль Qt Shader Tools для поддержки различных языков разработки шейдеров и обеспечения кросс-компиляции шейдеров как на этапе сборки, так и во время выполнения программы;
- Подготовка унифицированного API для создания интерфейсов пользователя, сочетающих элементы 2D и 3D графики и позволяющий использовать QML для для определения 3D-элементов интерфейсов без задействования формата UIP. В новом интерфейсе для интеграции 3D-контента с Qt Quick планируют решить такие проблемы, как большие накладные расходы при интеграции QML с контентом из Qt 3D или 3D Studio, и невозможность синхронизации анимации и преобразований на уровне отдельных кадров между 2D и 3D. Совместная в вложенная отрисовка 2D и 3D будет реализована при помощи нового движка рендеринга. Предварительная реализация нового Qt Quick с поддержкой 3D ожидается в выпуске Qt 5.14;
- Добавление инструментов для обработки связанных с графикой ресурсов на этапе компиляции, например, для преобразования PNG-изображений в сжатые текстуры или для конвертации шейдеров и мешей в оптимизированные бинарные форматы для конкретного оборудования;
- Встраивание унифицированного движка для тем оформления и стилей, позволяющего добиться внешнего вида приложений на базе Qt Widgets и Qt Quick, родного для разных мобильных и настольных платформ;
- Унификация инструментов для создания интерфейса пользователя. Для исключения дублирования функциональности и прекращения поставки двух отдельных продуктов, ожидается интеграция функциональности Qt 3D Studio в Qt Design Studio, многие подсистемы которого и фреймворк подключения плагинов построены на единой с Qt Creator кодовой базе.
В Qt Design Studio также планируют обеспечить качественную интеграцию с пакетами для создания контента, такими как Photoshop, Sketch, Illustrator, Maya и 3D Max. В качестве основных языков, поддерживаемых в унифицированном инструментарии для разработки, называются C++, QML и Python. Унификация также подразумевает возможность обращения из Qt Creator к средствам проектирования интерфейса, и предоставления дизайнерам интерфейса возможностям из инструментов для разработчиков, например, компиляции проекта или тестировании приложения на устройстве;- В качестве системы сборки решено использовать CMake вместо QMake. Поддержка сборки приложений при помощи QMake будет сохранена, но сам Qt будет собираться с использованием CMake. CMake выбран, так как данный инструментарий получил широкое распространение в среде разработчиков проектов на C++ и поддерживается во многих интегрированных средах разработки. Разработка сборочной системы Qbs, которая претендовала на роль замены QMake, прекращена (https://www.opennet.ru/opennews/art.shtml?num=49519);
- Переход при разработке на стандарт C++17 (ранее использовался C++98). В Qt 6 планируют реализовать поддержку многих современных возможностей C++, но без потери обратной совместимости с кодом на основе прошлых стандартов.
- Возможность использования из C++ некоторой функциональности, предлагаемой для QML и Qt Quick. В том числе, будет представлена новая система свойств для QObject и подобных классов, из QML будет в основной состав будет интегрирован движок для работы с биндингами, что позволит снизить нагрузку и потребление памяти для биндингов и сделать их доступными для всех частей Qt, а не только для Qt Quick;
- Продолжение работы по расширению поддержки дополнительных языков, таких как Python и WebAssembly;
- Реструктуризация с разбиением на более мелкие составные части и сокращением размера базового продукта. Инструменты для разработчиков и специализированные компоненты будут поставляться в виде дополнений, распространяемых через новый каталог-магазин. Для распространения будут приниматься и дополнения к Qt от сторонних разработчиков, как бесплатные, так и платные.
URL: https://blog.qt.io/blog/2019/08/07/technical-vision-qt-6/
Новость: https://www.opennet.ru/opennews/art.shtml?num=51238
Чем qlm/c++ лучше электрона и нормального фреймфорка и нормального языка (typescript)? Во времена кде 3 был адекватным фреймфорком с набором приемлимого софта, но видно что-то пошло не так.
Только высоким порогом входа, который надёжно отфильтровывает откровенных индусов. В итоге создаётся иллюзия, будто бы эта Qt какая-то волшебная технология, которая жрёт меньше памяти, чем Electron, и меньше тормозит. Ну чисто за счёт хоть какой-то квалификации тех, кто способен с этим работать.
Разумеется, если по-настоящему квалифицированный программист будет делать UI на Electron, получится не хуже.
Прям почитаешь некоторых, весь софт это один сплошной ui.
точнее "прям читаешь некоторых, а монитор аж жиром обрастает от тупого засаленного троллинга"
Вообще-то да. НЕ все ЧИСЛОДРОБИЛКИ пишут!!!!
nginx это число-дробилка? ох и сколько же идиотов на свете
> будто бы эта Qt какая-то волшебная технология, которая жрёт меньше памяти, чем Electron, и меньше тормозитElectron в микроконтроллеры не влазит.
Зато node.js давно уже - можно на нем серверную часть делать спокойно для управления.
Господа, у нас тут "эксперт" в треде, который не видит разницу между 700мб на qt против 3гб на елехтроне. Да и нужно быть уж совсем отбитым, чтобы приравнивать обрезок webgl к vulkan.
Это не говоря уже о том, что индусы говнокодеры как раз таки и избегают плюсов, выбирая всякую дичь типа джаэса и тупскрипта.
Судя по всему, это критическое преимущество, т.к. по-настоящему квалифицированные программисты ещё ни разу не брались за приложения на Electron. Да и за сам Electron. Напомнило: https://github.com/electron/electron/issues/8124
>Чем qlm/c++ лучше электрона и нормального фреймфорка и нормального языка (typescript)?Помимо сильно меньшего потребления ресурсов? Возможностью интеграции с ОС, нормальной работой с экранными ридерами и прочими приблудами для слепых и убогих, человеческим скейлингом шревтов (скоро 8k будет актуально, а электрон на 4k выглядит как треш).
лучше абсолютно всем. QML предоставляет возможность очень быстро и удобно создавать UI, и если вы имеете опыт в этом деле то вы сможете это ощутить (в подкрепление сказанного могу предложить поискать в интернете информацию о тех компаниях, которые приняли данную технологию для реализации UI в своих продуктах). С/С++ позволяет реализовывать задачи в машинный код, исполнение которого потребляет наименьшие кол-во ОЗУ, при максимальной скорость выполнения. Благодаря таким свойствам можно реализовывать не просто красивенький UI, но и реализовывать технологию. Если хотите то на QT можно за 2-3 дня создать свой электрон, с функциональностью необходимой под конкретную задачу. Для этого практически не нужно чтото самому придумывать, почти все для реализации можно взять как говорится из коробки.
К сожалению или к лучшему, но большинство программистов в меру своего мышления не в состоянии оценить ценность возможностей языка C++, но это и хорошо, ибо в современном мире требуются контенщики, армия которая не будет не при каком обстоятельстве конкурентами googl или других компаний которые задают курс, рождают технологии. Необходима армия кодеров способная быстро реализовать контент, расширить функционал модулем на lua, js итд.
Порой я слышу о страхе "выстрелить себе в ногу" программируя на с++, таким людям я рекомендую не брать в руки рогатку ибо могут выбить себе глаз, не кататься на велосипеде ибо могут разбиться, не заходить в воду ибо смогут утонуть,, не открывать рот ибо могут нести чепуху.
Ну, проблема переусложненности C++ имеет место быть, что усугубляется тем, что в проектах с долгой историей неизбежна дикая мешанина подходов от "C с классами" до современного C++.Но если проект начинать с нуля, то - да, достаточно использовать "вменяемое" подмножество современного C++, и все будет хорошо.
C++ имеет множество недостатков, но только не в сравнении с Javascript об этом говорить.
сложно ... сложно не согласиться, но ... при всех нед0статках, все же имеет 2 ... целых 2 плюса! так то!
Главная претензия к C++ это полнейший ад с реиспользованием кода. Там нет модулей, а есть только инклюды. Хуже того, после интеграции с Qt плюсовый код уже как бы и не совсем плюсовый, там поверх всякого накидано. И сборка Qt-либ тот ещё квест, как и линковка с ними.
И наконец, если я пишу на Electron, то я, сидя под Linux, забесплатно получаю бинарники и под винду, и под макось. А как мне собрать exe, компилируя Qt-проект из-под Linux? Ставить докер, пачку контейнеров и там ещё париться с настройками? А под макось? Мак покупать, чтобы этот ваш C++ под неё собирать?
В XXI веке язык, не способный в Zero-setup cross compilation, не имеет будущего. C++ сдохнет если не под Electron'ом, так под чем-то вроде Go, где всё это есть из коробки, уже в ближайшее десятилетие, оставшись только в легаси. Это когда кроме винды и x86 ни хрена не было, C++ рулил. Его псевдо-кроссплатформенности тогда хватало. Сейчас - это, извините, полная убогость.
винду или линукс можно установить на виртуалку и там откомпилить. мак ось наверное тоже можно установить на виртуалку, нет так если вы пишете под мак то думаю и купить себе мак для работы отличная идея. Кроме того как уже писали выше, не UI единым сыт программист. Есть во много раз больше задач без гуи, где требуется скорость выполнения и надежность. Конечно если рукожопость выше красной отметки то да, лучше писать на бэйсике или на js. Я представляю современного программиста в армии - это что то такое которое обязательно на стрельбище прострелит себе ногу )))
> Я представляю современного программиста в армии - это что то такое которое обязательно на стрельбище прострелит себе ногу )))Это выросшее на питоне поколение..... Для них и сортировку пузырьком написать самому - что-то на уровне фантастики. А чтобы собрать С++-проект - так не бывает.....
Ну да, ради права прикоснуться к Божественным Крестам можно и мак купить, и виртуалку поставить с виндою. Зато не Electron же, ради этого можно и не на такие жертвы пойти...
Поймите, что C++ просто неудобно пользоваться. Слишком много сил и времени уходит на какую-то муть вроде настройки сборки проекта. А потом вы клонируете проект на другую машину, и там тоже придётся настраивать, причём скорее всего по-другому, особенно если там другая ОС. И это при том, что уже появилось полным-полно языков и сред, где от этих проблем в значительной мере избавились. Так почему вы считаете, что они хуже? Потому, что "нормальный кодер" должен страдать? А если не способен стойко переносить страдания, то он и не программист вовсе?
Если вам не нужен GUI, то вместо Electron'а можно использовать к примеру Go, или любой другой язык, где нет проблем с кросс-компиляцией. Но не C++, который в плане кроссплатформенности на сегодняшний день один из худших существующих языков, и только религиозный фанатизм до сих пор не позволяет крестовикам наконец признать это.
Ну напиши на своем жеесе 3D-движек, лооооол
К сожалению, Юнити уже написали. Крысы давятся, колятся, но жрут, причмокивая.
Юнити - игровой движек, правильнее всего говорить, 3D ядро там на C++А весь интерфейс на JS(через language bindings) или Mono
движОк
"Поймите, что C++ просто неудобно пользоваться. "
мы и в правду разные поколения и по разному мыслим. Мне реально нечего вам сказать.
> Если вам не нужен GUI, то вместо Electron'а можно использовать к примеру Go, или любой другой язык, где нет проблем с кросс-компиляцией.Если вам не нужен GUI, то "вместо Electron'а" можно использовать стопицот языков где нет проблем с кросс-компиляцией. Ожидал примером Python увидеть.
Но вообще, в статье речь очевидно именно про GUI.
В чем проблема со сборкой проекта? сейчас уже все автоматизировано в IDE. Хотишь что то оптимизировать - пожалуйста, тут конечно нужно погуглить ман. А в чем проблема? Ну что вы вот все пропогандируете свою слабость и малоумие? C++ кросплатформенный ибо компилятор есть под абсолютно любую платформу. Вам что бы ноду запустить, нужно саму эту ноду откомпилировать на плюсах )). Реально, кроме как назвать вас it быдлом - я не могу, вы быдлокодеры, и добавить больше нечего вам.
ад с реиспользованием кода? хорашая лажа ) внезапно js стал сверхпереиспользованным?
пожалуй у явы и питона не будет явных проблем с переиспользованием)) и скриптов баша(ну тут как повезет). а плюсы и правда нагружены по небалуй)) но язык хорош. вот думаю доведут новые языки на замену плюсам с плюшками современных интерпретируемых))
Представьте себе, да. Есть единый кодовый реп, и при помощи npm вы по щелчку пальцев можете скачать себе всё что угодно. И интегрировать в проект. Одной командой.
И вам не нужно добавочно изучать Perl, Python, Bash и язык makefile'ов одновременно, только чтобы понять, какого хрена код не хочет линковаться к проекту и как теперь править скрипты сборки. Просто берёте и подключаете. И не только библиотеки, но даже и мелкие функции, некоторые по 10 строчек кода всего. Система сборки и интеграции в C++ просто полный отстой по сравнению с этим.
И можете хоть 1000 раз тут написать, что "нормальный кодер" должен всё писать сам, а не скачивать чужой код. Но в XXI веке язык, где можно собрать программу, не написав ни строчки кода, просто подгрузкой готовых компонентов, многократно лучше динозавроподобной хрени, где подключить готовый код зачастую сложнее, чем написать собственный аналог.
>можете скачать себе всё что угодно.спасибо, но мне бы то, что нужно. И совсем не хочется чтобы все, что угодно, тянулось само.
> язык, где можно собрать программу, не написав ни строчки кода, просто подгрузкой готовых компонентовВсё, что вы хотели знать об этих обезьянах, но стеснялись спросить.
>А как мне собрать exe, компилируя Qt-проект из-под Linux?Вот и выросло поколение программистов....
А то что можно и нужно скачать кроссверсию Qt религия не позволяет? Задаеш ключи линкеровщику с компилятором и готово, отлаживать правда трудно, но есть люди которые пользуются wine и не чего,не жалуются.
Хочешь посмотреть кросспоект на Qt который сам себя соберает- это правда не чистый Qt, коммерческий лазариус,морда к фрипаскалю, отлично компилируется под все 3 перечисленные платформы,там только небольшие исполняемые файлы для запуска установщика.
И давно у нас лазарь стал коммерческим?
>И давно у нас лазарь стал коммерческим?Внезапно для тех кто незнал-CodeTyphon Studio, компания PilotLogic .
Коммерческая версия, есть бесплатная версия, отстает от коммерческой на 1-2 релиза.
> Задаеш ключи линкеровщику с компилятором и готово, отлаживать правда трудно,Проверять в любом случае следует на целевой платформе, даже wine для этого не достаточно: можно столкнуться с тем, что в wine нормально работает и глючит на натуральной винде.
>А как мне собрать exe, компилируя Qt-проект из-под Linux? Ставить докер, пачку контейнеров и там ещё париться с настройками?Отставить контейнеры! Собрать cross-mingw-w64.
>Главная претензия к C++ это полнейший ад с реиспользованием кода. Там нет модулей, а есть только инклюды. Хуже того, после интеграции с Qt плюсовый код уже как бы и не совсем плюсовый, там поверх всякого накидано. И сборка Qt-либ тот ещё квест, как и линковка с ними.Сразу видно специалиста.
Электрон принадлежит мелкософту.
>приведение функциональности в соответствие с требованиями 2020 годаи какие же требования 2020 год предъявляет к функциональности, мать их?
Для начала нормальный менеджер зависимостей. Вот например ваш проект использует 20 сторонних компонент. Некоторые из них, в свою очередь, тоже могут от чего-то зависеть.
Эти компоненты время от времени обновляются, например в них правят уязвимости. И вам хотя бы раз в неделю надо проверять, какие из этих компонент обновились и делать update обновившихся, подтягивая последние версии в ваш проект.
В Javascript благодаря npm это делается одной командой, потому что это язык XXI века. Точно так же как и в Go, и в Python, и в Rust, и вообще в любом языке, где хоть немного думают об удобстве и продуктивности разработчика.
А в вашем "божественном" C++ как такое сделать?
Использовать системные библиотеки, а не тащить с собой. Для обновления есть пакетный менеджер.
Пакетный менеджер? В винде?
На всякий случай напомню, что проекты, созданные в любом нормальном языке XXI века, должны быть кроссплатформенными и работать минимум на трёх платформах. Язык, где всего этого нет из коробки, не имеет будущего.
>Пакетный менеджер? В винде?зачем поддерживать платформу, где даже пакетный менеджер не осилили? Это, получается, мне еще и за обновлением всех компонентов следить?
>зачем поддерживать платформу, где даже пакетный менеджер не осилили1) Он не нужен для пользователя. А что надо - само в фоне обновится. И это ПРАВИЛЬНО!
2) Пользователи. Ориентированный на 1% бизнес-план - это БРЕД!!
>А что надо - само в фоне обновится.и как на винде оно само обновится? С чем собрали с тем и будем сидеть.
Делай автоапдейтер как у хрома/лисы/фотошопа (лицензионного) и будет тебе счастье.Все обновляется само в фоне, тебе даже задумываться не надо. Красота!
какой автоапдейтер? А пакетный менеджер за автоапдейтер не сойдет? Может еще автоапдейтеры писать под весь софт, которым я пользуюсь, но его разработчики на это забили?
ну-ну
https://habr.com/ru/post/280099/
NPM и left-pad
Так и под c++ есть пакетный менеджер, и даже несколько.
.
Conan.io
а вот предположением что в одной из зависимостей программист допустил ошибку, и вы раз в неделю одной командой пересобираете проект и дальше что ? да да ) дальше все не так радужно ) и вы потеряли контроль над всем. Да конечно если это бэк на сайте куда ходит 100 чел в день это одно, но если это система расчета телеметрии на спутнике? ту да то и обновления каждую неделю не нужны ,, но допустим ))) даа, словите вы попу ).
Уважаемый , вы рассуждаете с высоты своего мышления которое не позволяет вам видеть дальше чем фронтенд (класика) + бэк (тоже класика +- пхп , нода, питон),, все! ) вот и все ) вы не понимаете суть вопроса )
Как-то $5500+ в год сильно дороговато для небольших контор и отдельных разрабов
Не поделитесь линкой на страницу где 5500 упоминается?
https://www.qt.io/buy-product/
а его можно юзать без подписки?
Конечно, LGPL же.
> Конечно, LGPL же.странно тогда чем пассажир не доволен, это же вполне годная лицензия
тем, что далеко не все компоненты под lgpl
Вроде их не много. Вот модули GPL/Commercial Licenses:
Qt Charts;
Qt Data Visualization;
Qt Network Authorization;
Qt Virtual Keyboard;
Qt Quick WebGL.Вот модули Commercial Licenses:
Qt Automotive Suite (информационно-развлекательные системы в транспортных средствах);
Qt for Automation (KNX, OPC UA, and MQTT);
Qt for Device Creation (встраиваемые устройства).MQTT есть сторонняя библиотека для Qt на LGPL, про другое не знаю, возможно тоже есть аналоги на LGPL. А чего нет, то видимо и не нужно. А если нужно, то плати :)
>Как-то $5500+ в год сильно дороговато для небольших контор и отдельных разрабовНе линкуй статически и будет конторе (проприерастической) счастье.
Можно и статически, но предоставлять obj файлы по запросу.
А можно делать морду кирпичом и не предоставлять!
Не хорошо ругаться. Сам то небось семью только работой на opensource кормишь, да?
Написанные мной слова нецензурными не являются. (Список смотри у Роскомнадзора)
В моей конторе лицензии соблюдают.
Ничего страшного в нестатической линковке нет.
Планы наполеоновские. Удачи им
Конец тоже будет наполеоновским.
Как ни странно, нет - конец у них как у той стюардессы, которую заново закопали. :) Трепыхаются, планы какие-то строят, но сам-то фрэймворк - фуфло! Безобразная модель лэйаутов отпугивает даже профи. Размеры - дичайшие. С++ нэйтив, соотв. кривые байндинги и нулевая возможность переписать это на человеческом языке. WPF стократ лучше даже с существующими недостатками.
Может, стоило бы задуматься о встраивании одного из недавно опубликованых встраиваемых JS-движков вместо выпиливания оного?
Всё же у встраиваемых движков производительность не та, на них особо не повертишь сложный интерфейс 60+ кадров в секунду. А электрон у нас уже есть.
Фуксия вертит.
Если уж прям нужен JS, я бы наоборот - предпочёл минималистичный JS-движок, который опнимает синтаксис на уровне 2005 года и работает быстро. Потому что писать на JS в UI нечто большее - плохая затея.
> Возможность компиляции QML в представление на C++ и машинный код.
> Перевод полной поддержки JavaScript в разряд опций (использование полнофункционального JavaScript-движка требует больших ресурсов, что мешает применению QML на таком оборудовании, как микроконтроллеры).
> Уход от генерации структур данных во время выполнения в пользу генерации во время компиляции.
> Переход при разработке на стандарт C++17 (ранее использовался C++98).Ну наконец то адекватность пошла. Ибо примеры в инете все на qml теперь, ибо макаки не могут в C++.
> Реструктуризация с разбиением на более мелкие составные части и сокращением размера базового продукта. Инструменты для разработчиков и специализированные компоненты будут поставляться в виде дополнений, распространяемых через новый каталог-магазин. Для распространения будут приниматься и дополнения к Qt от сторонних разработчиков, как бесплатные, так и платные.
Вангую проприетаризацию и копирастию.
Похоже жабоскрипты встроят в ядро, а виджеты вынесут в отдельный модуль.
>Похоже жабоскрипты встроят в ядроИз чего высосан этот вывод?
>а виджеты вынесут в отдельный модуль.
Виджеты и так в отдельном модуле. Qt он такой модульный.
Аналитики, хватит придумывать новости!
>Из чего высосан этот вывод?Из новости. Работай дальше.
>Виджеты и так в отдельном модуле. Qt он такой модульный.qtbase? Не, не слышал.
Нет такого модуля qtbase, есть qtcore и гуй в него не входит. Есть qtwidgets, это и есть те виджеты.
Ну замени модуль на субмодуль уже. qtwidgets лежат в qtbase, а будут отдельно. Или опять будешь запятые считать?
QtBase это не модуль, а QtWidgets это не субмодуль. QtBase - это собирательное название основных модулей, костяк так сказать.>а будут отдельно
Похоже для тебя это больной вопрос. Все ждешь, когда виджеты куда-то перенесут, откуда-то исключат, а они вон, в Qt 6 просочились. Да еще собираются унифицировать внешний вид Qt Widgets и Qt Quick на всех платформах и всю инфраструктуру рендеринга.
Спасибо за бесплатную консультацию. Вот у меня на счёт "костяка" и вопросы. Знаем, плавали. Темы тоже вон в "субмодуль" перенесли. Результат, так сказать, на лицо. С xml вон похожее приключилось.
>Из новости. Работай дальше.Где именно, давай цитату.
Ну так почитай ещё раз. Сказано однозначно, все силы брошены на QML. Про виджеты ни слова почти.
>Похоже жабоскрипты встроят в ядро
>Из чего высосан этот вывод?
>Из новости. Работай дальше.
>Где именно, давай цитату.
>Ну так почитай ещё раз. Сказано однозначно, все силы брошены на QML. Про виджеты ни слова почти.Слив засчитан.
"Возможность компиляции QML в представление на C++ и машинный код."
>Ну наконец то адекватность пошла. Ибо примеры в инете все на qml теперь, ибо макаки не могут в C++.Макаки не причём. Гуй на QML тупо удобнее разрабатывать хотя бы потому, что можно видеть изменения сразу при редакторивании кода, а не ждать пока компилятор пережуёт 100500 темплейтов.
А логику гуя ты на чём собрался описывать? А взаимодействие с плюснутым кодом? В общем иногда лучше жевать.
логика гуя описывается на QML, взаимодействие с плюснутым кодом через ВНЕЗАПНО систему взаимодействия с плюсовым кодом https://doc.qt.io/qt-5/qtqml-cppintegration-topic.htmlв общем иногда лучше жевать
Ты это Ларсу расскажи, а то он целый анонс уже выкатил, тебя не спросил.
> Ну наконец то адекватность пошла.Прям такое ощущение, будто уволили манагера и наняли менеджера.
> Возможность использования из C++ некоторой функциональности, предлагаемой для QML и Qt Quick. В том числе, будет представлена новая система свойств для QObject и подобных классов, из QML будет в основной состав будет интегрирован движок для работы с биндингами, что позволит снизить нагрузку и потребление памяти для биндингов и сделать их доступными для всех частей Qt, а не только для Qt Quick;Вангую потяжеление и больший оверхед для нативных приложений.
Как нефиг делать. Первые две попытки заточить всё под QML с треском провалились.
А вы как хотели, в 2020-м сидеть на компах начала 2000-х?
Можно подумать за последние лет 10 были какие-то суперулучшения в плане общей производительности. Спасает современный софт только многоядерность, тонны оперативы и SSD, иначе всё это убердно разработанное с применнием "улучшенных" средтв разработки и "новых ускоренных библиотек парсящих JS ещё быстрее чем вчера" даже не заводится
А суперулучшений производительности никто и не обещал. Железео подтянулось к нуждам софта просто.
Да, хотели. И хотим.
Тысячи владельцев рвзбери-пи и подобного хлама сейчас неодобрительно посмотрели в твою сторону.
И что? Выйдут следующие Raspberry/Orange с большим количеством ядрез и ОЗУ. Вон MTK уже 20-тиядерники выпускает.
>Добавление нового абстрактного слоя Rendering Hardware Interface (RHI) для обеспечение возможности бесшовногоНе прошло и 10 лет.
И это сейчас вынуждены сами добавлять, а тогда промежуточный слой с похожим механизмом совместно с сообществом и Canical для мира писать отказались.
Шутки про КДЕ за 200 уже были?
>Qt 6Ну всё, опять KDE переписывать!
зачем? плазма итак не падает
так это же повод)
Люди ещё на KDE5-то толком не перешли, многие всё ещё пользуются 4. А они уже Qt6 планируют!
А при чем тут вообще, блин, KDE? Больше Qt никто не использует?
Я - перешёл. И на 6 перейду сразу, как только компилироваться линуксовым шлангом программа под винду нормально будет с рантаймом мингв.
>многие всё ещё пользуются 4Кто же слоупокам виноват?
>Возможность компиляции QML в представление на C++ и машинный код.llvm фронт сделать не? Будет новый «орленок» ))
Кроме вашего LLVM в мире ещё полно других компиляторов, а одна из основных фишек Qt - кроссплатформенность.
Зашевелились наконец-то, на фоне планов переименовать GTK+ в GTK.
Ну это точно переможное достижение!
А как переименование поможет GTK ? ;)
>будет переведена вся имеющаяся инфраструктура рендеринга, включая QPainter, Qt Quick Scenegraph и Qt3D.Разве перед перечмслением не должно быть двоеточие?
>Новый API позволит использовать QML для для определения 3D-элементов
Я это имел ввиду:
>для обеспечение бесшовного использования различных графических API, включая OpenGL, Vulkan, Metal и Direct 3D (раньше Qt был завязан только на OpenGL). Н
В данном случае — не должно. Вот если бы присутствовал, например, оборот «в том числе», то двоеточие было бы уместно, а если «как-то» — обязательно.
Как-то не так анонимы используют обороты, как то: «включая», «в том числе», «как то»…
Ещё один технический директор не знает, чем строгая типизация отличается от статической?
ахахаха, пощади, человек-анонимcтрогая типизация существует только для тех, у кого strong переводится как строг xD
Ошибки времени выполнения продолжаем игнорировать?
оригинал новости слабо было открыть? нужно сюда сразу писать, да?
Меня всегда интересовал вопрос, что думали в Qt, когда просирали корссплатформенгсть всяким электронщикам? Причем сам Qt, с 90 годов прошлого века? Кто в руководстве? Полные бараны, не умеющие подумать по полгода вперед?
Когда кому-то удастся продать автогигантам лицензии на Electron за тонны нефти, тогда можно будет начинать критиковать руководство Qt.
> Кто в руководстве? Полные бараныХорошо что тут пришёл высокоинтеллектуальный Аноним и поставил этих дураков на место. Аноним лучше знает!
Ничего что Электрон это 1 окно внутри которого отображается HTML/JS? Проще говоря Браузер?
Вы просто думаете как разработчик. А надо как продажник. Продать можно какое угодно овно. Нужен лишь навык
> Ничего что Электрон это 1 окно внутри которого отображается HTML/JS? Проще говоря Браузер?Нет, это хуже. В браузере можно много страничек открыть. (Хм, записал в календарь на 2030 год: предложить гениальную идею универсального приложения для просмотра любых веб-сайтов.)
> Меня всегда интересовал вопрос, что думали в Qt, когда просирали корссплатформенгсть всяким электронщикам?В интересном мире живут электронщеги.
А у нас все не так - кутя даже на бздах и андроидах с айосями заводится, в отличие от "кросплатформенного" ляктрона с первоочередной поддержкой любимой элегтронщегами Вендочки и Ге^W МакОСи, поддержкой Пингвинчика
по остаточному
https://www.reddit.com/r/archlinux/comments/7y7sk4/is_it_jus.../
https://github.com/electron/electron/issues/10955
https://github.com/electron/electron/issues/12541
принципу и всех-всех-всех платформ i686, amd64, armv7.
>Существенная модернизация QMLЯ так и не осилил эту гадость. Я так и не понял как это дебажить: оно чувствуется как веб-хрень. Доводка до рабочего состояния происходит методом тыка. Если что-то делается неправильно, то что-то не отображается. Ничего не сегфолтится, никаких вменяемых ошибок, ничего.
Возможно если знать QML на хорошем уровне, то там есть плюшки, но если не знать, то всё намного мутнее чем при использовании QWidgets.
Ну пока что, синтаксически, QML вне конкуренции для построения UI. Или что есть лучше, варианты?
А основные спорные моменты как раз и упомянуты в этой статье> Ничего не сегфолтится
Звучит будто проблема)
Но на самом деле пару раз бывало, что крешится и QML> никаких вменяемых ошибок
Обычно есть, если это реально ошибка. В каком usecase не хватает стандартного вывода?
>QML вне конкуренции для построения UIГолословное утверждение. Какого гуи? Для каких целей? А кто же его знает.
Для любого интерфейса пользователя в прикладном ПО, где нужно взаимодействовать или мышью / клавиатурой или сенсорным экраном, очевидно же.
Другое дело, что технически оно далеко не идеально, но движется в правильном направлении
Да вот что-то не наблюдается в упор движения. Топтание на месте скорее. Хотели для мобильных интерфейсов, но там своего хватает за глаза.
Было бы удобно знаете что? Было бы удобно следующее:
1 пишется о отлаживается прототип на Qml
2 прототип финализируется путём автоматпческого превращения в C++ код на виджетах
3 далее код на виджетах допиливается вручную и далее используется только он.
> Опубликован план развития функциональности Qt 6Дядя проги под кутю будут менее жирными?
>Дядя проги под кутю будут менее жирными?И были и будут менее жирными чем на GTK.
>>Дядя проги под кутю будут менее жирными?
> И были и будут менее жирными чем на GTK.Не знаю, не знаю. Хелло ворлд окошко с кнопочкой на qt4 стартует мгновенно и кушает 36МБ RSS, на qt5 уже есть заметная задержка и хочет оно уже за 80МБ. Yad окошко на гтк3, стартует тоже с задержкой, но ест 30. Тот же yad на гтк2 запумался мгновенно и отъедал 20.
Claws на гтк2 хочет 50 и даже после пары дней не переваливает за 75.Вообще, жор памяти у гтк прог при переходе 2->3 увеличился где-то на треть, а у qtшных приложений 4->5 увеличило где-то в 2раза.
Особенно заметно увеличившееся время старта и жор обеих тулкитов на мелочи типа всяких индикаторов громкости. Курочка по зернышку -- и вот уже современное окружение в иксах жрет тройку сотен МБ вместо десятка да ещё и тормозит. Прогресс, однако!
>у qtшных приложений 4->5 увеличило где-то в 2раза.Ваша реализация GLX - г-но. Просто qt с 5й версии всегда запускает OpenGL контекст для каждого окна
> Ваша реализация GLX - г-но.Увы, не моя:
glxinfo|grep "vendor"
server glx vendor string: SGI
client glx vendor string: Mesa Project and SGI
> Просто qt с 5й версии всегда запускает
> OpenGL контекст для каждого окнаЯ ж и говорю - прогресс!
Но да,
% glxinfo|grep "Device"
Device: llvmpipe (LLVM 6.0, 128 bits) (0xffffffff)
На самом деле можно сменить qpa плагин на какой-нибудь другой, без запроса контекстаВообще с этим приколом я столкнулся на i965, там оказался очень жырный opengl контекст
Завалялся пакет wireshark 2.6.5 на гтк2 в локальной репе:Wireshark 2.6.5 на gtk2 - запускаем, выбираем wlan0 интерфейс, "capture" - 141МБ
Wireshark 2.6.5 на gtk3 - то же самое, 159МБ
Wireshark 2.6.5 на qt5 - 223МБ
Wireshark 3.0.3 на qt5 - 227МБ
открываем на gtk3 на pentium4 без видеокарты... и ловим тормоза...
а сам самый умный аноним гуи на wxwidgets пишет? tcl? MFC?
> Существенная модернизация QML:
> Поддержка строгой типизации.
> Возможность компиляции QML в представление на C++ и машинный код.это очень хорошая идея
Всегда любил Qt и как программист, и как пользователь.
Он будет жить долго, т.к. в эмбеддед очень хорошо войдет.
На Qt можно даже под Андроид писать не трогая Яву. Нормально работает.
Андроид все, держите Фуксию и Котлин
Ну пока что Андрюша везде, а Фикцию на реальных устройствах не встречали.
запилят и на фуксию, проблема блин
Справедливости ради, большинство важных взаимодействий ОС - только через Джаву, или с JNI, что в принципе-то почти тоже самое
> Возможность компиляции QML в представление на C++ и машинный код.
> Перевод полной поддержки JavaScript в разряд опций (использование полнофункционального JavaScript-движка требует больших ресурсов, что мешает применению QML на таком оборудовании, как микроконтроллеры).Make Qt great again!
Создаётся такое впечатление - что QML - чемодан без ручки...
Одно дело когда его nokia придумала для телефончиков
Вот чем оно закончилось
https://root-nation.com/posts/istinnye-prichiny-provala-meeg.../
QML/declarative - это очень перспективно на самом деле, настоящее отделение UI-ной части от реализации (с возможностью адаптации этой части под разные типы устройств!)Основная проблема в том, что технически красиво реализовать на плюсах-03 было сложновато + хотелось приманить толпу js-макак (причем месседжи были противоречивыми: то они предлагают делать qml-only приложения, то в собственной документации пишут о том что нужно свести использование js к минимуму). Толпа макак не пришла, Нокию убили, а Дигия сейчас разгребает весь этот шлак
> (ранее использовался C++98)Т.е. в Qt5 было ни строчки C++11?
было, но всё под ifdef-ами на случай, если компилятор не умеет
Начиная с Qt 5.7 компиляторы не умеющие C++11 не поддерживаются, они в приницпе не смогут Qt собрать
>Возможность использования из C++ некоторой функциональности, предлагаемой для QML и Qt Quick. В том числе, будет представлена новая система свойств для QObject и подобных классов. Из QML в ядро Qt будет интегрирован движок для работы с биндингами, что позволит снизить нагрузку и потребление памяти для биндингов и сделать их доступными для всех частей Qt, а не только для Qt Quick;Всё ускоряют Qml, всё пыжатся чего-то, а он всё равно тормозной и странный...
странный и тормозной это человек, который говорит про qml в qt 5.0 в 2019 году
Надо говорить про Qml в Qt6 ?
> Всё ускоряют Qml, всё пыжатсяА он и так уже быстрый, вот дела.
Ну так скажи им, а то они страдают всё по скорости. Даже компилятор завезли, бедные.
Когда в Qml появились Desktop components?
А когда у них починили сглаживание шрифтов?
Аарон Сейго - тот мудилло, который убил КДЕ. Сначала своей плазмой, потом переписыванием её на Qml.
Ну так канадец же...
Допустили канадца к КДЕ - угробил,
другого канадца допустили в Nokia - угробил...
А что не так с плазмой то?
то что КДЕ выкинули со всех дистров...
Толсто. Из двух дистров, один из которых активно пилит гном3, а второй продолжает пилить гном2.
>Разработка сборочной системы Qbs, которая претендовала на роль замены QMake, прекращенаСсылочку надо было на https://code.qt.io/cgit/qbs/qbs.git/log ставить, чтобы было видно, что это ложь
Отличная возможность бросить kde5 и начать все сначала с kde6
кде6.0 != кде6
Слушайте, прекратите постоянно развивать Qt!!! Мы не успеваем портировать наши программы с версии на версию
http://local.joelonsoftware.com/wiki/%D0%9E%D...Огонь и движение
Автор: Джоэл Сполски
Эта статья начинает играть совершенно другими красками, если учесть, что спустя 6 лет после написания её автор основал Stack Overflow.
> Эта статья начинает играть совершенно другими красками, если учесть, что спустя 6
> лет после написания её автор основал Stack Overflow.Знал ли автор, что лет через 10 появится масса клонов, переведённых специалистами с Али на русская языка?
Скорее бы уже допилили wxQT...
я читаю вот эти коменты про пакетный менеджер, про другие какието притянутые за яйца причины. Реально приходят аналогия общества капиталистического, летературного, наконец it. везде есть быдло и неудачники которые вечно будут сетовать на то что это трудно, нам для того что бы начать работать нужен личный бухгалтер, и что бы в моих докментах была настроена нормальная отчетность, ой, ехать самому в банк или в налоговую я нет, пас, ну так ведь по дороге можно в аварию попасть. Нет я эту книгу не читал, много букв, нет уже давно аудиокниги, почему писатели не заботятся о читателях, почему сразу не готовят аудио книги. Вот ребята, вот образ современного программиста. но оно и к лучшему, разделение на кассы оно даже при СССР было, правда не так открыто офишировалось, вроде как все равны ). Поэтму будут в it инженера (архитекторы, аналитики, системные программисты, разработчики игровых движков) т.е. людей локомотивов. а так же будут в it - быдло. это контентщики, т.е. потребители, модники, хайпушечки плюшечки,, молоко и печеньки, с плавающей головкой, с минтолом и эвкалиптом, тот кто всегда хочет сникирснуть по айтишному. Это можно признать и не обращать внимание на таких но понимаете, как с гомосексуалистами, нормальному человеку все ровно куда и с кем они любятся, но нормальному человеку не все ровно когда этот гомосексуалист называет нормального мужчину фобом, заявляет во всю что сэкс с двум мужчинами это хорошо а отношения между мужчиной и женщиной это отвратительно и так далее. не приятно видеть на улице как двое парней целуются, не приятно читать строки идиотов про то что на С++ можно выстрелить себе в ногу поэтому язык говно. Если солдат застрелится на посту то проблема не в оружии, а в солдате. Проблема не в языке а в навыках и опыте программиста. Если задача наплодить говнокодеров это одно, если задача выращивать инженеров- разработчиков - это совсем другое.