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

Может серверное ПО тоже через веб делать?

А там и фреймворки ненужны.

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

На серверной стороне.

paramon
()

Ненужно 6.0, надо затестить(на самом деле нет).

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

Змея укусила себя за хвост.

Серверное ПО работает не только на серверах. Речь про клиент-сервер, когда ПО разделено на 2 части и обе части могут работать на обычном домашнем ПК пользователя.

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

Так фреймворки это же хипсторское всякое там. PHP, Javascript, Go, Ruby, Python...

scanner
()

Это неплохо. Ждем новаций в KDE, самом прогрессивном DE сегодня.

anonymous
()

@hatred

Почему дураков? Судя по всему как раз умных людей там не хватает.

А конкретнее?

Зачем то продолжают пилить намертво прибитый к C++ фреймворк с отвратительным API вместо того чтоб перейти на удобный, логичный и полностью свободный стек, доступный из целой кучи языков.

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

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

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

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

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

В очередной раз отвечаю, что в данном контексте я говорю GTK для краткости, имея под этим в виду весь стек gobject-based библиотек.

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

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

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

и дрищет нечитаемыми портянками

а тебя их заставляют читать на ночь? Qt - великолепный инструмент в свой широкой нише. Ничего более удобного пока не придумали.

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

фреймворк с отвратительным API

Наглая брехня.

anonymous
()

Qt - сила! GTK - могила.

KDE прекрасен как никогда. Вечная слава команде KDE!

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

Там опять совместимость API не поломали?

Поломали частично, но ничего капитального. Отключи deprecated методы в 5.15 для ознакомления.

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

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

Конечно. C++17 на дворе, а мы всё ещё пользуемся moc и кастуем костылями для доступа к перегруженным слотам.

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

А можно хотя бы примерно набросать, как сделать без moc аналог QObject с Q_PROPERTY, которая доступна из QML.

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

Если это легаси, оно уже там будет. Если на этом старье кто-то решает делать что-то новое…

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

Я не пользовался Copperspice, просто знаю что это форк Qt без moc.

Вот как их код выглядит:

class MyClass : public QObject
{
    CS_OBJECT(MyClass)
 
    CS_PROPERTY_READ(priority,   priority)
    CS_PROPERTY_WRITE(priority,  setPriority)
    CS_PROPERTY_NOTIFY(priority, priorityChanged)
 
    CS_ENUM(Priority)
 
    public:
       MyClass(QObject *parent = 0);
       ~MyClass();
 
       enum Priority { High, Low, VeryHigh, VeryLow };
 
       void setPriority(Priority priority)
       {
           m_priority = priority;
           emit priorityChanged(priority);
       }
 
       Priority priority() const
       { return m_priority; }
 
 
       CS_SIGNAL_1(Public, void priorityChanged(Priority data))
       CS_SIGNAL_2(priorityChanged, data)
 
    private:
       Priority m_priority;
}

Вот как они это реализуют:

https://github.com/copperspice/copperspice/blob/fc541d534530842f0c98d7e4d009dbe5a5683c73/src/core/kernel/csobject_macro.h#L112

https://github.com/copperspice/copperspice/blob/fc541d534530842f0c98d7e4d009dbe5a5683c73/src/core/kernel/csobject_macro.h#L573

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

А, т.е. всё равно препроцессор на полную катушку, да ещё и с дублированием деклараций. В таком случае не вижу в moc никакого криминала. Что так, что эдак полное извращение из-за недостатка выразительности цпп.

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

А что в шестом с работой без иксов? Помнится в 4-м была замечательная фича QWS (которую в пятом или выпилили, =или на что-то еще поменяли), крайней удобная для эмбедеда.

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

Пишут, что либо только 1 процесс, либо надо Wayland использовать: https://www3.sra.co.jp/qt/relation/doc-snapshot/qtdoc/embedded-linux.html.

Note: As of Qt 5.0, Qt no longer has its own window system (QWS) implementation. For single-process use cases, the Qt Platform Abstraction is a superior solution; multi-process use cases are supported through Wayland.

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

Че-то дичь какая-то. А как они тогда это предлагают в embedded использовать? (вроде бы они себя и в этой нише позиционируют, или уже нет?)

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

Возможно для большинства embedded проектов достаточно одного GUI процесса на весь экран.

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

всё нормально с этим в embedded, если устройство требует некий специфичный вывод - пишется qpa-plugin, если он может выводить через стандартный механизмы, как то linuxfb, то всё работает само в силу присутствия реализации

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

Я бы Qt на Vala или D перенес, выкинув GObject в пользу QObject, сохранив свой механизм сигналов слотов, но решать разработчикам конечно

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

Ой, пожалуйста, не нужно. Это же другой язык учить :-)

rumgot ★★★★★
()

Может быть плохо искала, но не нашла ответы на главные вопросы:

  1. Применяется ли в Qt кодогенерация?
  2. Используется ли макрос Q_OBJECT?
totik
()
Ответ на: комментарий от imb

всё нормально с этим в embedded, если устройство требует некий специфичный вывод - пишется qpa-plugin, если он может выводить через стандартный механизмы, как то linuxfb, то всё работает само в силу присутствия реализации

Он про сервер окошек. В Qt до пятой версии был аналог иксов, назывался QWS и позволял на платках манипулировать окнами, сейчас туда для этого дела обычно тянут Wayland или вообще одно приложение запускают на весь экран и избавляются от диалоговых окон.

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

FB без ускорения ведь. А сейчас в каждой кофеварке GPU. Поэтому в embedded юзают eglfs в основном.

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

На оба вопроса ответ положительный. Избавлятся они от этих костыльков пока не планируют. Может с переходом на C++20 когда там рефлексию нормально подвезут, они эту сишную лапшу красиво перепишут и moc выкинут. Но это очень медленно будет продвигаться. На тот же C++11 они перешли только спустя 5-6 лет после его релиза.

EXL ★★★★★
()
Ответ на: комментарий от EXL
$ ./configure -help
............
  Platform backends:
    -direct2d .......... Enable Direct2D support [auto] (Windows only)
    -directfb .......... Enable DirectFB support [no] (Unix only)
    -eglfs ............. Enable EGLFS support [auto; no on Android and Windows]
    -gbm ............... Enable backends for GBM [auto] (Linux only)
    -kms ............... Enable backends for KMS [auto] (Linux only)
    -linuxfb ........... Enable Linux Framebuffer support [auto] (Linux only)
    -mirclient ......... Enable Mir client support [no] (Linux only)
    -xcb ............... Enable X11 support. Select used xcb-* libraries [system/qt/no]
                         (-qt-xcb still uses system version of libxcb itself)
...........

сейчас можно «тащить» X11, но если такое требуется, то такой ли это embedded? я конечно слышал, что сейчас embedded называют всё что не позволяют свободно расширять/обновлять, вплоть до систем хранения размером в несколько юнитов :)

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

В embedded обычно eglfs теперь.

Кстати directfb по сути умер, странно что его не дропнули.

Вот тут всё написано:

https://doc.qt.io/qt-5/embedded-linux.html

On Embedded Linux systems, there are multiple platform plugins that you can use: EGLFS, LinuxFB, DirectFB, or Wayland. However, the availability of these plugins depend on how Qt is configured.

EGLFS is the default plugin on many boards. If it’s not suitable, use the QT_QPA_PLATFORM environment variable to request another plugin. Alternatively, for quick tests, use the -platform command-line argument with the same syntax.

Note: As of Qt 5.0, Qt no longer has its own window system (QWS) implementation. For single-process use cases, the Qt Platform Abstraction is a superior solution; multi-process use cases are supported through Wayland.

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

ну, не всему софту это требуется, а если софт пишется под несколько платформ и на части их них нет OpenGL, то выбора как-то особо нет

а зачем убирать DirectFb? по факту это же не самостоятельная технология а оболочка над нужной, проще говоря - всего лишь интерфейс, не стоит его удалять

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

Reflection не раньше 23, а более реалистично 26. В 20е только сделали динамическую аллокацию в constexpr (нужно для introspection, для начала).

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

а зачем убирать DirectFB

Потому что:

  1. Последний коммит в этот проект был четыре года назад, https://github.com/deniskropp/DirectFB, а последний минорный релиз более пяти лет назад.
  2. С официального сайта DirectFB вот уже четыре года рассказывают разработчикам, которые ищут документацию на DirectFB, как им заняться первым в жизни сексом: http://www.directfb.org/how-to-prepare-for-the-first-sex/ (видимо тонко намекая, чем им обернётся ковыряние в этом DirectFB).

Если серьёзно, то проект давным-давно уже мёртв и его поддержка только захламляет и так излишне раздутую кодовую базу Qt, отнимает время.

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

DirectFb это сторонняя программа. Qt может работать через ядерный LinuxFB точно так же как и через DirectFb.

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

статья 2016 года, может там за 4 года уже всё изменилось…

Article posted by Olivier Goffart on 25 May 2016

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

с этим я не спорю, DirectFb действительно скорее труп, но не думаю что его поддержка чего то стоит в силу устоявшегося API

но это уже пошли отвлечённые рассуждения, как вариант его можно вынести в отдельный модуль, для примера Broadcom в своём SDK реализовал вывод через DirectFb, для Qt5 мы от него отказались и реализовали qpa-plugin c прямым использованием Nexus API

но тут есть обратная сторона, DirectFb даёт унификацию, что положительно сказывается при поддержке железа с разным API и я имею в виду не только вывод на экран, это ещё управление

imb ★★
()

Кути сложный язык? Стоит ли мне его учить?

Владимир

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

Кстати, QTextCodec таки выкинули, как грозились?

Да, теперь там QStringEncoder/Decoder. Список кодировок: Utf8, Utf16, Utf16LE, Utf16BE, Utf32, Utf32LE, Utf32BE, Latin1,

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

DirectFb даёт унификацию, что положительно сказывается при поддержке железа с разным API и я имею в виду не только вывод на экран, это ещё управление

Вот так будет работать и управление при выводе через linuxFb

export QWS_KEYBOARD=«LinuxInput:/dev/input/event0 LinuxInput:/dev/input/event1»

export QWS_MOUSE_PROTO=«LinuxInput:/dev/input/event0 LinuxInput:/dev/input/event1»

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