Компания Qt Company опубликовала первый тестовый выпуск новой ветки Qt 6, в которой будут предложены значительные архитектурные изменения, а для сборки потребуется компилятор, поддерживающий стандарт C++17. Выпуск включает в себя только начальный каркас будущего релиза Qt 6, который намечен на 1 декабря 2020 года. Функциональность в ветке Qt 6 будет расширяться до объявления заморозки кодовой базы 31 августа...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53164
Ждём ебилдов или flutter desktopов?
Ждём анархии в кедах...
Ну что STD в контейнерах, с лямбдами?
Такой же как в шышыа, или поцивилизованнее?
Flutter, как мне кажеться, больше приуспел чем QML. Видимо Qt не сильно вкладывалась в этой направление. Сейчас же они позиционируют QML как решение для встраиваемых систем.
вот только оно для мобилок и от гугла
Flutter web и desktop. Пока сыроват, но всё же. От гугла: Qt тоже корпоративный продукт, и сейчас гнут палку похлеще любого гугла.
таки лучше qt, чем гугл. они занимаются одним продуктом и никогда его не выкинут
Не выкинут, а вот выкинуть на обочину немалое количество разработчиков которые используют Qt вполне могут, исходя из последних событий.
Что-то это не первоочередная задача у Гугла принести флаттер на десктопы. П.С. сам на флатере пишу чутка
Мне кажется у них дарт и flutter в целом не первоочередная задача). По большей части всё держится на энтузиазме, не всё успевают делать. Разработчиков из гугл которые поддерживают, например, дарт, можно пересчитать по пальцам. Да, гугл пилит фуксию и там flutter ключевой фреймворк, но это только эксперимент.
Не только для мобилок, и как бэ уже давно на всех конференциях об этом рассказывали. И в чем проблема от гугла? Шизафазия.
Слово Flutter вызывает у меня беспокойство и дискомфорт, потому что означает крайне опасное явление в авиации, приводящее к ужасным катастрофам.
Надо переименовать.
Скоро бабахнет в КДЕ
Надо выкидывать старые технологии.
Qt 4 вон в Ubuntu только что выкинули.
Да, GPL выкинут и перейдут на модномолодежный EULA.
>Скоро бабахнет в КДЕ
>Надо выкидывать старые технологии.У тебя-то в голове постоянно бабахает.
Надо запасаться старыми версиями, пока их не удалили.
Вчера пытался найти где то инсталляцию под винду Qt5.2...Qt5.6 (Последняя версия работающая на Win XP. Капец - выпилено, а я лось не хранил.
http://download.qt.io/archive/qt/
Если MOC выкинут и заменят чем-то вроде Boost.Signals2 и аналогичной библиотекой для свойств, Qt, наконец, станет труЪ православным каноническим C++ фреймворком. Тогда можно будет говорить "пишу на C++", вместо "пишу на Qt". Хотя, к тому времени 95% кода уже будет писаться на QML.
Нет не станет. У них до сих пор строки не из std.Я вот ждал, что они наконец на STL переведут большую часть своего барахла. А получилось вот так:
>Переход при разработке на стандарт C++17 (ранее использовался C++98). В Qt 6 планируют реализовать поддержку многих современных возможностей C++, но без потери обратной совместимости с кодом на основе прошлых стандартов.
> У них до сих пор строки не из stdИ это прекрасно
> И это прекрасноЧем-же это прекрасно?
Вы ещё скажите, что STL нужно всеми силами избегать.
Понаделали своих собственных рукожопых контейнеров....
>Чем-же это прекрасно?вероятно софт без поддержки все еще можно будет собрать без серьезных патчей
>Вы ещё скажите, что STL нужно всеми силами избегать.это слишком сильно сказано, но utf-8 строк в std вроде нет. Точнее такую строку можно впихнуть в std::string, но на этом все
>но без потери обратной совместимости с кодом на основе прошлых стандартов.если они сделают это в виде оберток над std, то что в этом плохого? Старые проекты будут использовать обертки, новые — напрямую
https://en.cppreference.com/w/cpp/string/basic_string
std::u8string (C++20)
а с этим как быть?
> size/length — returns the number of charactersтот же substr отрезает в байтах, что в принципе ожидаемо
>> Переход при разработке на стандарт C++17 (ранее использовался C++98)..
> https://en.cppreference.com/w/cpp/string/basic_string
> std::u8string (C++20)угу
Никогда они не перейдут полностью на STD чисто из-за того что они подсаживают на frendly контейнеры с кучей дублирующих алгоритов, который вызываються через методы, что для новичка удобнее, а потом привычка и вот это все.
они уже давно говорили - если есть в STL что-то, берите оттуда. Qt-шные медленнее, но есть всегда, где есть Qt. Java-style алгоритмы у них уже давно не true объявлены.
На строках из STL честный юникод (даже utf-32 на u32string) не сделать, а в Qt это как раз нужно и при выпиливании создаст кучу ненужных проблем
Не неси чушь, QString был на UTF-16 теперь в Qt6 будет на UTF-8, STD подерживает UFT-8 потому что обайтные доп коды.
>в Qt6 будет на UTF-8Ну и хорошо, разработчикам Jabber-клиентов на Qt жизнь упростится. Поскольку, UTF-8 для XMPP стандарт.
>std поддерживает utf8Да, но где простые и удобные аналоги fromUtf8, fromLocal8bit, и др?
> Не неси чушь, QString был на UTF-16 теперь в Qt6 будет на
> UTF-8, STD подерживает UFT-8 потому что обайтные доп коды.Собственно о чём я и говорю. Поддерживает абсолютно неверный термин т.к. операции определены для US-ASCII, а UTF-8 они просто не ломают потому, что (удивительно) при разработке UTF-8 об этом подумали. А то с таким же успехом можно утверждать что ANSI C89 поддерживает UTF-8.
Написал STL и опорафинился (Standard Template Library, STL) — стандартная библиотека шаблонов в языке программирования C++. String это STD просто набор псевдоконтейнера в пространстве имен.
> Boost.Signals2говно тяжеленное
Наглый навет.
MOC выкинут и заменят Reflections. В штате Qt член WG21, который, так совпало, форсит эту тему в C++23.
C++23 это уже явно не в Qt 6 будет.
>Перевод полной поддержки JavaScript в разряд опцийСначала все тащили к себе это проклятие веб-браузеров, потом долго и радостно годами оптимизировали, а теперь начинают потихоньку выпиливать.
Как-то сделал немного математики для этой штуки (благо от С отличия практически только в заголовках). Показал французу. Спросил, на чем это написано и очень удивился.
>а теперь начинают потихоньку выпиливатьВаши бы слова, да Electron'у в уши.
> Ваши бы слова, да Electron'у в уши.Их уже услышал гугел и усиленно катит Flutter
Вы предлагаете из Electron'a выкинуть Electron?
Это же кутеρасты, у них жοпа чешется, если Qt просто работает... Надо срочно всё переписать по другому.
Вот любопытно, они сделают move-конструкторы для QObject, или unique-указатели вместо голых? На C++11 все уже давно перешли.
> или unique-указатели вместо голыхЧтобы это могло значить? Тебе и сейчас никто не мешает использовать std::unique_ptr в Qt. Или вообще не использовать указатели, а размещать объекты на стеке.
> Или вообще не использовать указатели, а размещать объекты на стеке.иди почитай, что такое указатели и чем стек отличается от кучи, чтобы больше так не позориться
а что собственно не так?
> Или вообще не использовать указатели, а размещать объекты на стеке.я типа теперь не должен юзать указатели для вещей на стеке? типа не разрешаете? а и как мне теперь без строк и массивов, которые тоже указатели?
Тебе никто ничего не запрещал, не психуй. Но использовать std::unique_ptr и аналоги для объектов на стеке - как минимум глупо, если не сказать больше.
> Но использовать std::unique_ptr и аналоги
> для объектов на стеке - как минимум глупо, если не сказать
> больше.Ну да. Но ведь большая часть QObject'ов через new создаётся. Тут умные указатели были бы кстати. А если они уже внутри есть, то зачем двойное выделение на куче?
> а что собственно не так?Прост на указателях модифицировать дерево какой объект компу принадлежит гораздо удобнее. Особенно если каждый объект дерева может быть самых разных размеров (разных классов). При этом все элементы должны не пропадать после выхода из функции, в которой были созданы, и одним стеком тут не обойдёшься.
Ну и понятно, если работаешь с большими массивами, но тут уж надеюсь и так понятно.
Что вы тут устроили... в Qt-разработке есть вполне конкретный best practiсe, что в heap-области должны быть аллоцированы только те объекты, чье время жизни сравнительно долгое (окна, кнопки, модели данных в виде всяческих списков и хэш-таблиц). Легкие ресурсы должны аллоцироваться в хипе при старте приложения, тяжелые - лениво инициализироваться по мере необходимости. Если ресурсы "флуктурируют" - например, это модель всяческих документов, изображений и т.д. - все, что юзер может открыть и закрыть, это все должно оборачиваться в соответствующий смартпоинтер, если объект по смыслу не "пристегнуть" к QObject-иерархии. Все остальное должно быть стековым и передаваться const-ссылкой. Работа со стеком всегда дешевле работы с кучей, а за счет copy elision и move-семантики там даже лишней работы по копированию нет, если инициализируем безымянным объектом, как это часто бывает. И куча, кстати, при агрессивном использовании стандартного аллокатора фрагментируется и при высоком аптайме будут постоянные кэш миссы. Data locality при аллокации на стеке соблюдать проще.
Не стоит газифицировать космос - он большой. Если хочешь сказать что-то конкретное - говори конкретно.
> размещать объекты на стекеДве шнобелевки этому господину.
Тогда и авторов официальной документации не забудь отблагодарить https://doc.qt.io/qt-5/qtwidgets-mainwindows-application-exa...
там под капотом через d_ptr всё в куче, юноша
То есть по этой логике иметь указатель на d_ptr "под капотом" на кучу - правильно, а сразу положить объект на стек - "две шнобелевки"?
> То есть по этой логике иметь указатель на d_ptr "под капотом" на кучу - правильно, а сразу положить объект на стек - "две шнобелевки"?Не соpримся коллеги..
Пример из exmaple(s) QPainter:
ложешь/кладешь экземляр QPainter на стек( перегружаешь ..::paintEvent(..) ), а под капотом аллокации в QPainter...
Идиома PImpl - надо внимательно управлять/следить за врмеменем жизни экземпляра, так называемого "стекового" экземпляраПримеры из жизни по libqwt(доработка 5.*, 6,*), вынос "стекового" QPainter в объявления Qwt* класса( плюс нек-рые финты ушами касаемо float ) позволил на 30-40 %% понизить cpu-usage.
Вообщем - мин. аллокаций в run-time..
Да понятно, что можно -- в той части кода, которая не QT.
Но зачем, если внутри QObject уже есть свой самописный умный указатель, зачем передавать для наследования указатель?QObject a{};
QObject b{a};А весёлая магия подсчёта ссылок -- внутри самих объектов. Нормальное RAII, короче.
Наверное для вас будет открытие но qobject сам по себе smart pointer, именно поэтому возможны вещи типа qpointer,
Который на самом деле аналог weak_ptr изнутри
Тогда тем более непонятно, почему в 20-м году нужно создавать объекты через new и передавать голые указатели, если всё это можно запихнуть внутрь конструктора. И бонусом высвобождение ресурсов по выходу из видимости.Для QT5 я могу это понять, совместимость и всё такое. Но в новых-то продуктах, хотя бы как альтернативу, можно без голых указателей на каждый чих.
> Для QT5 я могу это понять, совместимость и всё такое.
> Но в новых-то продуктах, хотя бы как альтернативу, можно без голых указателей на каждый чихВозможно это:
>> Qt 6 планируют реализовать поддержку многих современных возможностей C++,
>> но без потери обратной совместимости с кодом на основе прошлых стандартов.
Голые указатели - это нормально, если они аргументы функции-члена, которая не предполагает никакой семантики владения. Об этом еще Герб Саттер писал. Если сильно паника, что кто-то может изменить данные - можно сделать указатель на константу. Ну а ручной delete не в деструкторе будет вызывать только конченный и про это даже джуны знают и способны как сами себя проконтролировать, так и на ревью поймать.
> C++11Если бы из данного стандарта откровенную глупость убрать, которая генерирует ни к чему не обязывающие ворнинги, но засоряющие выдачу чисто эстетически.
Т.е. ждем в опенсорсе через год?
через год вообще всё закроют.
Когда ждать KDE 6? :)
Аликс Поль недавно говорил про полгода-год.
После релиза 6.
Пусть Wayland в 5 сначала допилят.
Вэйленлд нужен 2,5 калекам, поэтому его не надо вообще "пилить".
Кек. В кедах иксы уже объявлены как Легаси)
И будут ли такие "мозги" совместимы и со старым "железом"? (И улучшится ли там и как-либо и поддержка "Wayland"?)
> совместимы и со старым "железом"?нет, конечно. Требования такие, что фик запустишь на старом.
А что там с лицухой? ТроллТех будет троллить или free version останется free?
Меня больше волнует, в каком виде это будет. То, что сейчас с 5.15 (можете ознакомиться у них на сайте), совершенно не устраивает.
Что конкретно не устраивает?
Для опенсорса будут выходить обновления до выхода следующей версии, а что ещё надо?
Due to The Qt Company offering changes, open source offline installers are not available any more since Qt 5.15. Read more about offering changes in the https://www.qt.io/blog/qt-offering-changes-2020 blog.If you need offline installers, please consider our new Qt for Small Business offering: https://www.qt.io/blog/available-now-qt-for-small-businesses
А кто-то ещё использует оффлайн инсталляторы? Зачем?
> А кто-то ещё использует оффлайн инсталляторы? Зачем?Я. Чтобы инсталлировать на компьюьтеры не подключенные к интернету.
КО-решение: Один раз установить онлайн, а затем копировать сколько нужно.PS Мейнтейнеры пакетов дистров соберут вам оффлайновые инсталляторы.
> КО-решение: Один раз установить онлайн, а затем копировать сколько нужно.Кретино-Отмороженное решение? Везти комп за N километров чтобы на него ставить нужные пакеты? Это, безусловно, путь к успеху! (сарказм)
Чтобы в инсталляторах телеметрия не отрабатывала. Зачем, как ты думаешь, были придуманы эти олайн-инсталляторы? Чтобы собрать телеметрию.
https://github.com/miurahr/aqtinstall - альтернативная реализация онлайн-установщика.
Насколько понял тенденцию, гайки будут затягивать, как раз чтобы форсировать переход на новый стандарт языка. Что из этого выйдет в итоге -- большой вопрос.
Они последовательно сокращают количество LGPL компонентов. Думаю, в итоге все останется под GPL и коммерческой лицензией. Так что КДЕшникам и энтерпрайзу (который может платить over $5000 в год за разработчика) - пофиг. А инди всякие идут ...
И сколько же LGPL компонентов уже переведено на GPL?
Где жесть-то вся? Скриншоты там, чтоп юзер адекватного UI сразу проблевался?
> чтоп юзер адекватного UI сразу проблевался?А зачем юзеру адекватного UI блевать от того, на чём этот UI создан?
ты, видно, всю техническую документацию исключительно по картинкам читаешь (если они есть) :-D
"прафесянал"
> ты, видно, всю техническую документацию исключительно по картинкам читаешь (если они есть)
> :-D
> "прафесянал"Прафесьанал :-)
" Возможность компиляции QML в представление на C++ и машинный код. " два года ждал.
ну вообще-то в qtquickcompiler это давно добавили. сначала сделали в байткод, потом в плюсы
qtquickcompiler сначала в коммерческую версию добавили, в бесплатной не было
А кто вам сказал, что сейчас в бесплатной будет?
Сейчас ведь есть
Но это и, скорее всего, означает, что можно писать проги чисто на C++, без использования QML, но со всем его функционалом. Может и корявова-то, конечно, код выглядеть будет, но зато сразу на плюсах.
Его и без moc можно писать. Только потом лучше удалять.
Лучше удалять из-за нечитабельности?
> Реструктуризация кодовой базы с разбиением на более мелкие составные части и сокращением размера базового продукта.Вот это правильно, годное направление. И так вполне уже разбили удобно, двигаемся дальше.
А исходников то нету :(
dev-ветка уже не катит?
https://code.qt.io/cgit/qt/qtbase.git/log/
Кокой хороший годный кумыс, довайте на нём всё перепишем, и жуэс ещё, чтобы каждая макака могла написать "приложение" на "плюсах".Ой, компиляций, типизация, генерация мама, мы в аду мама!
Выпиливают ЖуэС.
Тем временем гтк 4 все никак не закончат
И не надо. А то напишут {println('Hello!')}, а затем 10 лет по одной строчке дописывать свою альфа-версию.
Опять что ли темы переписывать собрался?
Через год-два выйдет KDE 6. Надеюсь, что не будем материться словом "опять"
Надеюсь, вы его не начнёте использовать с версии 6.0? Поэтому и материться не надо будет.
Кде5 пользуюсь с 2015 года, ну т.е. где-то через полгода уже перебежал на него. И выкинул все приложения в режиме совместимости с kde4, было немного пусто сперва, но в целом нормально. Потом ещё были какие-то баги в кутях, но меня они чудесным образом обошли. Чем тебя не устроили пятокеды?Правда с тех пор kde4 либы пропихнули мне всё же, непонятно зачем, без них замечательно работало
kde-plasma/khotkeys-5.19.0 requires >=kde-frameworks/kdelibs4support-5.70.0:5[X]
kde-plasma/plasma-desktop-5.19.0 requires >=kde-frameworks/kdelibs4support-5.70.0:5
kde-plasma/plasma-workspace-5.19.0 requires >=kde-frameworks/kdelibs4support-5.70.0:5
Хехе, удалил, эта дрянь нужна для knetattach lookandfeeltool и чего-то ещё, вроде ничего нужного. Но без этого мусора плазма (и сервис активитис) что-то не собирается, раньше она была более модульной. Ну ладно, пусть будет.
Активити сервис, на самом деле, тебе тоже не нужен. И без него всё работает (если не сломали за это время). Активити это решение в поисках проблемы.
> Активити сервис, на самом деле, тебе тоже не нужен. И без него
> всё работает (если не сломали за это время). Активити это решение
> в поисках проблемы.Без активитис всё сломалось (systemsettings в первую очередь, хоть и не особо необходим, но всё же). Даже okular и kde-cli-tools -- последнее намекает на то, что кеды вообще нерабочие будут.
Ничосе изменения. Что они там сделали такого.
> решено использовать CMakeДа вы, видимо, решили давить на мазоли? Вам же сразу сказали: используйте CMake! Но нет, у нас свой путь, ваш CMake - тупой. Вот, держите несколько несовместимых 5.x веток.
Зачем так делать? Непонятно.
Хорошо, что в конце образумились.
Но ведь cmake действительно отвратен
Но да, qmake тоже ужасен, классические два стула
Была надежда на qbs как на лучик света в этом царстве хаоса, но увы
>а для сборки потребуется компилятор, поддерживающий стандарт C++17А что делать старым пердунам пишушим на Си с классами?
>В качестве системы сборки решено использовать CMake вместо QMake.
CMake изначально создавался для Си плюс-плюсников, ну и кто тут тормоз?
> А что делать старым пердунам пишушим на Си с классами?читать новость и код новых версий Qt, срезать "углы" в совем коде..
>> Переход при разработке на стандарт C++17 (ранее использовался C++98).
>> В Qt 6 планируют реализовать поддержку многих современных возможностей C++, но без потери обратной совместимости с кодом на основе прошлых стандартов.От стаи старых пердунофф..
> А что делать старым пердунам пишушим на Си с классами?Минимизировать использование stl)
> Переход при разработке на стандарт C++17 (ранее использовался C++98).Хватит эту херню из новости в новость писать, с 5.7 Qt без С++11 не скомпилируется. В оригинальном блогпосте было про то что Qt 5.0 был на С++98.
В итоге сообщество форкнуло Qt или нет?
Зачем? Ничего не было и ничего не случалось
>обираться с использованием CMakeОлично
Где скачать нул?
Сколько килобаксов стоит "Tools used when building & packaging Qt 6.0"?