LINUX.ORG.RU

Доступна предварительная сборка Qt 6.0

 , , ,


1

4

Qt Company сообщила в своём блоге о доступности первой предварительной сборки Qt 6.0.

Компания сообщает, что первая предварительная сборка содержит бинарные файлы только для настольных платформ, а для тестирования на мобильных и встроенных платформах необходимо воспользоваться сборкой из исходных текстов, при этом Qt 6.0 требует поддержки C++17 от компилятора, поэтому разработка фокусируется на сравнительно недавно выпущенных компиляторах.

Первая предварительная сборка содержит следующие модули:

  • Qt Core
  • Qt GUI
  • Qt Widgets
  • Qt Network
  • Qt QML
  • Qt Quick
  • Qt Quick Controls
  • Qt SVG
  • Qt Network Authorization
  • Qt SQL
  • Qt Test
  • …и несколько других модулей

Qt Company и далее собирается предоставлять регулярные предварительные сборки Qt 6.0, получить же их можно воспользовавшись установщиком Qt в категории Preview.

Выпуск Qt 6 намечен на 1 декабря, а 31 августа предполагается заморозка добавления функциональности.

>>> Блог Qt



Проверено: unfo ()
Последнее исправление: unfo (всего исправлений: 4)

Деньги теперь надо платить?

anonymous
()

Скажите кто знает, есть шанс что Qt смигрирует на другой язык? Или их плюсы устраивают?

loz ★★★★★
()
Ответ на: комментарий от loz

Примерно такая же, как лтс версии бесплатно.

anonymous
()
Ответ на: комментарий от loz

есть шанс что Qt смигрирует на другой язык?

Конечно. Они уже давно на rust переходят. На С++ осталось только всякое легаси...

LamerOk ★★★★★
()

MOC-костыль с сишной макроснёй под нож пошёл?

На дворе 2020 год, а там всё

#define Q_OBJECT \
public: \
    QT_WARNING_PUSH \
    Q_OBJECT_NO_OVERRIDE_WARNING \
    static const QMetaObject staticMetaObject; \
    virtual const QMetaObject *metaObject() const; \
    virtual void *qt_metacast(const char *); \
    virtual int qt_metacall(QMetaObject::Call, int, void **); \
    QT_TR_FUNCTIONS \
private: \
    Q_OBJECT_NO_ATTRIBUTES_WARNING \
    Q_DECL_HIDDEN_STATIC_METACALL static void qt_static_metacall(QObject *, QMetaObject::Call, int, void **); \
    QT_WARNING_POP \
    struct QPrivateSignal {}; \
    QT_ANNOTATE_CLASS(qt_qobject, "")

/* qmake ignore Q_OBJECT */
#define Q_OBJECT_FAKE Q_OBJECT QT_ANNOTATE_CLASS(qt_fake, "")

#ifndef QT_NO_META_MACROS
/* qmake ignore Q_GADGET */
#define Q_GADGET \
public: \
    static const QMetaObject staticMetaObject; \
    void qt_check_for_QGADGET_macro(); \
    typedef void QtGadgetHelper; \
private: \
    QT_WARNING_PUSH \
    Q_OBJECT_NO_ATTRIBUTES_WARNING \
    Q_DECL_HIDDEN_STATIC_METACALL static void qt_static_metacall(QObject *, QMetaObject::Call, int, void **); \
    QT_WARNING_POP \
    QT_ANNOTATE_CLASS(qt_qgadget, "") \
    /*end*/

/* qmake ignore Q_NAMESPACE_EXPORT */
#define Q_NAMESPACE_EXPORT(...) \
    extern __VA_ARGS__ const QMetaObject staticMetaObject; \
    QT_ANNOTATE_CLASS(qt_qnamespace, "") \
    /*end*/

/* qmake ignore Q_NAMESPACE */
#define Q_NAMESPACE Q_NAMESPACE_EXPORT() \
    /*end*/
EXL ★★★★★
()

требует поддержки C++17 от компилятора, поэтому разработка фокусируется на сравнительно недавно выпущенных компиляторах.

Это гцц 7, в принципе не такой уж и новый, от 2017-2018 года, но на самом деле даже в гцц ещё не всё поддерживается, в шланге ещё не всё доделали, в последнем только частичная поддержка. Но им наверное и не надо 100%.

А кто-то кутэ использует не на локалхосте, компиляторы с с++17 есть в наличии? Как там вообще с портируемостью сейчас обстоят дела?

anonymous
()
Ответ на: комментарий от loz

Скажите кто знает, есть шанс что Qt смигрирует на другой язык? Или их плюсы устраивают?

Есть рекомендация, чтобы портировали на C#. Там Qt не хватает, ну и это необходимо для повышения популярности Qt.

Skullnet ★★★★★
()
Последнее исправление: Skullnet (всего исправлений: 2)
Ответ на: комментарий от Skullnet

C# - это легаси, надо мигрировать на vala с с-апи, это будущее.

anonymous
()
Ответ на: комментарий от anonymous

А кто-то кутэ использует не на локалхосте, компиляторы с с++17 есть в наличии? Как там вообще с портируемостью сейчас обстоят дела?

Тут палка о двух концах. С одной стороны Qt 5 действительно легко портировать на любую микроволновку, благодаря внедрению QPA.

Умельцам даже Qt на GTK+ портировать удалось: https://github.com/CrimsonAS/gtkplatform, и это может иметь какой-то смысл, учитывая что X.Org вместе со своими костылями вроде Xlib и XCB объявлен устаревшим, а GTK+ на сегодня по сути дефолтный графический тулкит в Linux. Возможно в будушем Qt примет этот QPA-модуль себе в upstream вместо устаревшего QPA-модуля XCB и этот шаг поможет решить проблему мимикрирования одних тулкитов под другие в Linux и превратит Qt в сахарок над более низкоуровневым GTK+, как сейчас Qt сахарок над XCB или QtWayland.

Но с другой стороны, фреймворк постоянно поднимает стандарты и если раньше условный C++98, на котором был написан Qt, был доступен на каждом чайнике, то сегодня на старом железе, которое забросили вендоры, использовать Qt новых версий будет трудно или вообще невозможно.

Но не стоит забывать, что мы живём в эпоху, когда Linux победил и все коммерческие UNIX’ы вроде AIX/HP-UX/Solaris/SCO Unix и иже с ними отправлены на свалку истории, и даже порты на RTOS вроде INTEGRITY, QNX и VxWorks потеряли свою актуальность. Захожу на страничку официальной документации и вижу:

If you are interested in later Qt releases, please contact Qt professional services.

https://doc.qt.io/qt-5/vxworks.html

Собственно Linux даже на Embedded по сути победил. А раз он победил, значит никаких проблем заюзать GCC 7 или Clang/LLVM с поддержкой C++17 на новых платках и нету. Разве что если у тебя будет что-то очень-очень старое.

EXL ★★★★★
()
Ответ на: комментарий от EXL

Я спрашивал у тех кто использует не на локалхосте. Когда гтк сможет использовать другой тулкит в качестве бекэнда, тогда и расскажешь что-нибудь про объявления на заборах.

anonymous
()
Ответ на: комментарий от loz

Весь Qt вряд ли когда-нибудь смигрирует с C++. Но вот надежда, что пребывающие в стагнации QtCore и QtWidgets сама компания или энтузиасты перепишут на тот же Rust – есть.

EXL ★★★★★
()
Ответ на: комментарий от bhfq

Макрос-макросу рознь. Не следует сравнивать макросы в C/C++ и Rust. В случае первого на уровне лексера/препроцессора используется банальнейшая автоподстановка, а в случае второго это полноценная модификация AST, в результате чего макросы гигиенические и не несут опасности для окружающего кода. К тому же в Qt вся эта макросня приправлена отдельным MOC-костылём, который проходит по каждому исходнику ища в нём Q_OBJECT и дрищет нечитаемыми портянками, которые дополнительно компилируются и линкуются с твоей программой. Просто омерзительно.

EXL ★★★★★
()

Там опять совместимость API не поломали? А то недавно пришлось чинить программу написанную под Qt4.

X512 ★★★★★
()
Ответ на: комментарий от EXL

Но вот надежда, что пребывающие в стагнации QtCore и QtWidgets

Какие с ними проблемы? Или нужно постоянно что-то менять для имитации бурной деятельности?

X512 ★★★★★
()
Ответ на: комментарий от EXL

Пацаны, ваша проблема в том, что вы не умеете программировать, а щеки надуваете так как будто умеете, и ктото не знающий кто вы такие может принять ваши высеры за истину. В с++ есть constexpr и consteval, и это не модификация текста в каком-то виде, а вычисления во время компиляции примерно как в Лиспе. Но это все все равно не может сделать даже половины того что может сделать элементарный препроцессор.

Идите почитайте что-нибудь про программирование, чисто для общего развития, но не Википедию, не стековерфлоу и не реддит, книжку какую-нибудь купите, а? Ваш бред какбы немного утомляет и провоцирует флейм.

anonymous
()
Ответ на: комментарий от EXL

на старом железе, которое забросили вендоры Разве что если у тебя будет что-то очень-очень старое.

Только поддержка и багофиксы. Железо заброшенное вендорами… Можешь привести примеры такого, где может потребоваться актуальная версия Qt? На котором планируется разработка нового проекта?

DIY проекты на барахле с АлиЭкспресса не в счёт.

hatred ★★★
()
Ответ на: комментарий от EXL

дрищет нечитаемыми портянками, которые дополнительно компилируются и линкуются с твоей программой.

Это ещё пример не самой худшей кодогенерации.

hatred ★★★
()
Ответ на: комментарий от anonymous

Именно поэтому предлагается static reflection и generative metaprogramming. Но они, скорее всего, не раньше 26х будут.

anonymous
()
Ответ на: комментарий от anonymous

C++17 объявлен полностью поддерживаемым в gcc9. Недавно уже 10й вышел. Для не локалхоста не нужно всю систему переделывать, достаточно только собрать компилятор, который там запустится (ну и может стандартную библиотеку допилить. Компилятор вполне может быть кросс-компилятором, поэтому разрабатывать для baremetal arm вполне можно и на c++20. Главное, чтобы бакенд не дропнули (такое случается и в gcc для барахла). Даже если бакенд дропнули, или его не было, можно взять хороший фронтенд и дописать, например, для того же llvm. Или взять edg, который C может генерировать. Так что нет причин тянуть «портабилити», только усложняя разработку.

anonymous
()

Так что, будут пилить шестую плазму? Сколько будут поддерживать Qt5 после выхода Qt6?

anti_win ★★
()
Ответ на: комментарий от loz

Скажите кто знает, есть шанс что Qt смигрирует на другой язык? Или их плюсы устраивают?

Но… зачем??? Кому в каком горячечном бреду может понадобиться мигрировать с плюсов?

curufinwe ★★★★★
()
Ответ на: комментарий от loz

Rust не готов, добавлять зависимость от жирного уродского рантайма net или jvm смысла нет, ибо просто electron возьмут, кому нативное не нужно. Ocaml и вообще ml не популярны. Т.е. кроме первого варианта остальное и рассматривать не стоит.

anonymous
()
Ответ на: комментарий от EXL

Но не стоит забывать, что мы живём в эпоху, когда Linux победил и все коммерческие UNIX’ы вроде AIX/HP-UX/Solaris/SCO Unix и иже с ними отправлены на свалку истории,

как припекает-то до сих пор - загляденье

anonymous
()

Тем временем из системы только-только удалились библиотеки Qt4.
Совместимость-то хоть не поломают? Нового переписывания кеды не переживут.

dogbert ★★★★★
()
Ответ на: комментарий от silver-bullet-bfg

В этом и был смысл моего сообщения. Прочитай то, на которое я отвечал.

Siborgium ★★★★★
()
Ответ на: удаленный комментарий

Просто объявили бы Qt устаревшим и призвали разработчиков переходить на GTK.

Переходить с Мицубиcи в сборе на кузов от Ниссана, ага.

В очередной раз повторяю: GTK — графический тулкит, Qt — фреймворк, включая кучу библиотек и систему сборки. Аналог GTK — это QtGui+QtWidgets.

P.S. Против GTK как таковой ничего не имею, кому нравится на ней писать — пусть пишет. Вот только считать свой инструмент единственно правильным — один Apple у нас уже есть.

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 2)

В блоге по ссылке, похоже, ЛОР-эффект…

hobbit ★★★★★
()
Ответ на: комментарий от EXL

Собственно Linux даже на Embedded по сути победил. А раз он победил, значит никаких проблем заюзать GCC 7 или Clang/LLVM с поддержкой C++17 на новых платках и нету. Разве что если у тебя будет что-то очень-очень старое.

да китайцы до сих пор поставляют gcc-4.9 в лучшем случае, казалось бы не такой старый, но даже на Qt-5.12 есть «особенности», а Qt-5.15 вообще не собирается, требуется constexpr конструкторы насколько я понял

imb ★★
()
Ответ на: комментарий от hatred

Можешь привести примеры такого, где может потребоваться актуальная версия Qt? На котором планируется разработка нового проекта?

любой Qt-программист предпочтёт использовать максимально свежую сборку, так как работать с legacy в виде Qt-4.7.3 без stl они не могут/не хотят :)

imb ★★
()
Ответ на: комментарий от imb

Ты вроде в теме, напомни пожалуйста в какой версии Qt перестал собираться компилятором который поддерживает только C++98 (C++03)?

EXL ★★★★★
()
Ответ на: комментарий от paramon

Ну так имеются сторонние библиотеки, фреймворки ненужны! (111)

Под каждую платформу свои библиотеки и методы их использования. Зоопарк в коде получится если делать кросплатформенно, а без этого сегодня никуда.

anonymous
()
Ответ на: комментарий от paramon

С чего это вдруг? Кому нужно пусть и идет.

Может серверное ПО тоже через веб делать? Да и многое веб не умеет, например как там организовать обмен через RS485? MQTT? Работа с базами данных?

anonymous
()
Ответ на: комментарий от EXL

А он переставал? По-моему все фишки С++11 до сих пор отключаемы. Edit: хотя не, я не прав, прямо в QObject есть std::enable_if безо всяких условий исключения этого кода.

unC0Rr ★★★★★
()
Последнее исправление: unC0Rr (всего исправлений: 1)
Ответ на: комментарий от imb

Не, ты чего. Они 98-ой тянули очень-очень долго.

Тут нашёл:

Leveraging C++11

The core of Qt comes from its C++ foundation and the powerful native performance it offers you. We of course always want to ensure Qt is on top of the latest C++ developments, so that the framework continues to grow with your needs. Qt has supported the use of C++11 in application code for a long time. We also wanted to keep supporting C++98 compilers up to Qt 5.6, which meant that we needed to wait before fully leveraging C++11 features in the Qt framework libraries themselves.

Starting with Qt 5.7 all compilers are C++11 compatible, which allows us to start using new C++ functionality such as auto, lambda and many more in Qt itself. These features will also start to appear in the Qt API, where it makes sense to do so. For those who can’t move yet the long term supported Qt 5.6 provides full C++98 compatibility.

https://www.qt.io/blog/2016/04/21/qt-5-7-beta-released

EXL ★★★★★
()
Ответ на: комментарий от unC0Rr

Qt 5.6 LTS официально последняя версия, которую можно собрать компилятором с C++98/03 стандартом. Она же и последняя работающая на Windows XP :^)

EXL ★★★★★
()
Ответ на: комментарий от EXL

changes-5.7.0


  •                    Important Behavior Changes                        *
    

  • Starting with Qt 5.7, Qt requires a C++11 compiler with support for C++11 atomics. This affects user code too: Qt headers no longer compile with a C++98 compiler. The minimum compiler versions for this release are:
    • GCC 4.7
    • Clang 3.4 (found in XCode 5.1)
    • Microsoft Visual Studio 2013

несколько двояко, но проверять не буду

скажем для Qt-5.15 они поддерживают C++11, но с некими неявными ограничениями, странно то, что в самом коде они проверяют версии от GCC-4.3 и не выходят с ошибкой при обнаружении оного, повидимому руки не дошли поправить

imb ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.