leonsolya Apr 2 2021 at 18:05

Пишем свою навигацию в Qt

7 min

8.1K

C++*Qt*

From sandbox

Comments 6

Alex_Crack Apr 2 2021 at 21:51

Однако, интересное решение. Почему-то всегда считал, что мобильные приложения всегда делают с использованием Qml, он для этого как-то больше позиционируется. Но внезапно виджеты оказались довольно красивым решением.

Sazonov Apr 3 2021 at 07:10

Виджеты хороши ровно до тех пор, пока вы не столкнётесь с DPI scaling или необходимостью делать анимацию интерфейса. И не стоит забывать, что вся отрисовка виджетов идёт в один поток на CPU.
Безотносительно Qt — это нормальная практика делать стейт машину для интерфейса. В статье реализация, которая решает свои задачи.
Если фронтэнд программист не занимается обычным формошлёпством, то такой подход вполне логичный.

apro Apr 3 2021 at 14:00

Еще с виджетами гемор работать с "touch screen". То "popup" диалог не работает с touch screen, хотя аналогичный QML отрабатывает нормально, то QListView не различает прокрутку пальцем и нажатие, то к каждому виджету нужно QScroller прикрутить, чтобы "кинетическая" прокрутка работала, хотя опять же QML как-то могут и с мышкой и с "touch screen" из коробки работать. То сам Qt начинает "бажить" с очередной версией, например https://bugreports.qt.io/browse/QTBUG-82355

Amelkai Apr 3 2021 at 22:29

Вообще в qt довольно просто создается многопоточность. GUI должен быть конечно в одно потоке, но логику работы можно сунуть в другие потоки и связать их через connect.

Sazonov Apr 4 2021 at 08:38

Вы пробовали на практике создавать многопоточные модели (QAbstractItemModel)? Так чтобы они эффективно работали с большим количеством элементов. Тут QReadWriteLock не хватит. Не так это и легко на практике.

mapron Apr 4 2021 at 03:50

Часто вижу распространенную ошибку.
Для класса Navigator вам не нужен ни Q_OBJECT макрос, ни public slots: с технической строны. Если вам прям для понимания хочется иметь секцию слотов, если без неё вы не разберётесь что это слоты — пожалуйста. Коннекты будут работать прекрасно.
Почему это вообще важно? 1 строчка, добавил макрос и не паришься, «а вдруг вообще я потом сигналы добавлю» — ну лично мне, например, не хочется иметь лишний moc вызов в сборке (и разрастание размера образа из-за доп генерации).

Если вы используете cmake и moc

… и вас напрягает то что после добавления Q_OBJECT или убирания оного приходится перезапускать cmake для создания правил, можно сделать такой трюк:
пусть правило для генерации moc.cpp из .h будет всегда, но если макроса нет, то файл будет пустым. Потом все moc файлы можно в unity/amalgamation билд включить для еще большего ускорения.

дефолтные cmake методы из Qt конечно, не получится использовать, но можно быстренько написать что-то подобное:
github.com/mapron/FreeHeroes/blob/master/cmake/targets.cmake#L98
github.com/mapron/FreeHeroes/blob/master/cmake/mocWrapper.cmake.in