Доброго времени суток!
Потребовалось сделать Qt-приложение, максимально похожее на приложения, разработанные с помощью библиотеки  MFC. Именно похожее, сам функционал не обязателен.
Начал с переписывания стиля, но вскоре понял, что как то "до фига".
Может кто-нибудь делал подобное или видел готовый стиль для такого? Платный вариант тоже вполне рассматривается.
P.S. Дл любителей читать по диагонали - приложение НЕ под винду. Совсем.

Программа требует Qt5Core.dll, а вы её подсунули дебажную библиотеку. Которая Qt5Cored.dLL

Возможно, что это зависело от региона. Ну и от провайдера/опсоса.

Может её и банят, но где-то там, в виртуальном пространстве. И в отчётах.

Ну так галку для начала неплохо бы поставить. Выбрать комплект.

Настройки то есть. И были всегда. И там 3 варианта выбора. Проблема в том, что они у меня никогда не работали. И переключался я как раз с помощью "eselect opengl set nvidia". А как сейчас это делать, я не знаю.
Этот libglvnd себя позиционирует как некий "автомат", который сам вроде как может разобраться, кому нужен доступ к opengl. Если я правильно понял документацию, конечно. Но оно не работает для KDE. Т.е. приложения с opengl будут работать, но не все. Допустим, стим. Ну и "эффекты рабочего стола" тоже не работают.

Суть вопроса: относительно недавно некоторые программы начали фактически требовать флаг libglvnd (например telegram-desktop).
Но, если его задать у того же mesa, то нужно будет удалить пакет eselect-opengl.
Соответественно, уже не получится просто переключить между программной отрисовной и использованием opengl (я про "eselect opengl set nvidia")
Как сейчас это правильно сделать, чтобы opengl работал в KDE? А то без него нет эффектов (типа куба рабочего стола)

Так можно прямо в .pro задать каталоги сборки. Есть же ключи. Я вон, вообще в памяти временные папки создаю автоматом, там и собираю. В /dev/shm
unix:!macx {
    OBJECTS_DIR = /dev/shm/my_programm/$$FOLDER/$$TARGET/obj
    MOC_DIR     = /dev/shm/my_programm/$$FOLDER/$$TARGET/moc
    UI_DIR      = /dev/shm/my_programm/$$FOLDER/$$TARGET/ui
    RCC_DIR     = /dev/shm/my_programm/$$FOLDER/$$TARGET/rc
}

macx {
    OBJECTS_DIR = build/obj
    MOC_DIR     = build/moc
    UI_DIR      = build/ui
    RCC_DIR     = build/rc
}

android {
    OBJECTS_DIR = build/obj
    MOC_DIR     = build/moc
    UI_DIR      = build/ui
    RCC_DIR     = build/rc
}

win32 {
    TEMP_PATH = "X:"
    OBJECTS_DIR = $$TEMP_PATH/my_programm/$$FOLDER/$$TARGET\\obj
    MOC_DIR     = $$TEMP_PATH/my_programm/$$FOLDER/$$TARGET\\moc
    UI_DIR      = $$TEMP_PATH/my_programm/$$FOLDER/$$TARGET\\ui
    RCC_DIR     = $$TEMP_PATH/my_programm/$$FOLDER/$$TARGET\\rc

    CONFIG -= debug_and_release #debug_and_release_target
    CONFIG += no_fixpath

    DEFINES += WIN32_LEAN_AND_MEAN
}

Почему? Вполне будут уместны. Они будут НЕ уместны, если вы программу используете сами, никому не показывая. А так будет вполне себе нарушение лицензии.
Мне просто интересно - зачем всем именно 1 исполняемый файл? Не проще ли сделасть инсталлятор - он заодно и избавит от вопросов "где та программа, которую я зачем то ставил на прошлой неделе?"

Если бы это работало - я бы тему не поднимал. И это не работает и toplevelwidget. Есть предположение, что можно отследить перемещение виджетов и просто запоминать, какой из них в какой момент стал верхним (или несколько верхних).
Но однозначного решения я не нашёл.

Сестра Надежда ещё не умерла. Просто, если что-то можно сложить в стопку, то должно же как то отличаться верхнее, от не верхнего.
Я сомневаюсь, что я первый обратил на это внимание. Складывание доков в стопку вроде было еще в 4-ке...
P.S. А вот насчёт paintEvent надо проверить. Даже при перекрываемых окнах, у полностью открытого верхнего дока область отрисовки будет либо равной этому доку либо наибольшей у нескольких.

С Z-ордером тоже не всё так однозначно. Хотя решение должно быть...

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

Сурово. Одно наследуется от QAbstractItemModel, другое от QAbstractTableModel.
В принципе можно использовать , но как по мне - это изврат. Проще переделать архитектуру проекта.