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

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

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

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

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

А как же кроссплатформенность и каша в коде для зоопарка либ?

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

А как же кроссплатформенность

Браузер есть везде. Серверы это Linux.

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

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

Нинужно.

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

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

Что омерзительно, фанатик?

hatred

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

То есть на современном C++ можно без MOC сделать?

https://www.copperspice.com/ давно сделали без MOC.

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

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

Ну что я могу сказать… Тогда - страдать :)

Я не пользовался 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

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

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

Пишут, что либо только 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.

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

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

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

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

Через FB, емнип.

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

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

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

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

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

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

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

$ ./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 называют всё что не позволяют свободно расширять/обновлять, вплоть до систем хранения размером в несколько юнитов :)

В 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.

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

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

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

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

Потому что:

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

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

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

Видел статью, в которой на бенчмарках этот самый copperspice уделывался обычным Qt5 в кратные цифры по всем фронтам.

https://woboq.com/blog/verdigris-qt-without-moc.html

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

Article posted by Olivier Goffart on 25 May 2016

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

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

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

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

Владимир

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

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

гента не готова - http://gpo.zugaina.org/dev-qt/qtcore

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»