...

Ты пересобирал проект?

Rebuild all?

Да, разумеется.

Пересобирал именно ту конфигурацию, что "проверчешь" ?

давай я тоже переспрошу)

удалил папку сборки?

И релиз версию пробовал, и x64 пробовал.

Во, это следующий шаг , что я хотел предложить...

А вот этого не сделал...

Ну, попробуй...
Надо будет только заново сконфигурить билд систему

(qmake)

Этот вариант рабочий. Не знаю как он это делает, оказывается, генерирует эти файлы и скрывает. Успел заметить. Помогло. Спасибо!

Вопрос конечно хороший. Проектировщик из меня не очень. Но вот какие у меня мысли.
Создаю ядро приложения с минимальнейшим функционалом за основу взял класс QMainWindow (так как главное окно вижу как MDI в своем приложении. Для ядра такой класс может и не годиться, но пока так). Загружается главное окно с минимальным меню и в системном трее отображается значек приложения. При закрытии главного окна приложение не выгружается из системы, а сворачивается лишь окно и убирается из панели задач. Для того, чтоб вызвать окно имеется значек в системном трее.

Далее по сценарию должен быть функционал для связи с СУБД и прохождение авторизации пользователя средствами СУБД. После авторизации пользователя в СУБД из приложения, приложение делает запрос в СУБД и получает какие модули (плагины) должны быть загружены для группы пользователей в которой состоит авторизированный пользователь. Ядро приложения проверяет наличие этих модулей(плагинов) на локальной машине и если чего-то не хватает, то догружает. Также проверяет актуальность имеющихся модулей(плагинов, их версии), если требуется то обновляет до того как будут загружены в ядро приложения.
Ну, а далее загружаются модули (плагины) и приложение приобретает функционал для нормальной работы авторизированного пользователя.
За счет такой схемы я думаю пользователь сможет с легкостью пересеть на другую машину (ПК) и продолжить свою работу не смотря на то, что его машина на обслуживании, занята и т.д.
Это одна сторона.
Вторая сторона.
Модульность(за счет плагинов) позволит иметь небольшое лего из которого можно будет лепить по потребностям пользователей.
Ну и расширять функционал можно будет постепенно при это не надо будет компилить все приложение. А лишь ту часть над которой работали. Также я думаю обновление будет менее затратным по времени, чем бы пришлось обновлять все приложение из-за какой-то мелочи.
Третьей стороной - это возможность работы команды разработчиков при этом каждый занимается своим направлением. Один к примеру занимается навигацией и понятия не имеет, что происходит в модуле с информацией по обработке поступющих вызовов, но предоставляет возможность к примеру поиска адреса, определения координат на местности, вычисления расстояний и т.д. Для любых модулей кому требуется.

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

Могу конечно во всем ошибаться, но как могу изучаю, фантазирую, проектирую и реализую.

Как говориться Москва не сразу строилась. Сказать, что все осилю и реализую задуманное всего функционала, который требуется! Могу смело сказать НЕТ!!! Но если будет получаться и желание не пропадет, то ядро будет позволять расширяться с наименьшими затратами.
Локализацию уже в приложение запилил и работает. Мне не требуется приложение многоязычное, но возможность перевода есть без переписки кода.
Git осилил первоначально хоть и общаюсь с ним на Вы, но общаюсь. Решил пока общаться вообще с ним только консольно пока на "Ты" с ним не перейду.
Doxygen тоже изучил и по тихоничку начинаю внедрять и описывать код.

Двигаюсь со своей скоростью, но двигаюсь...

Моя рекомендация пока не думать об этом, о плагинах, а делать функционал. Как минимум 30-50% думаю можно сделать без нормальной архитектуры, а позже уже переделывать.
Будет видно уже и что требуется от плагинов

Мне одновременно нужно двигаться в двух направлениях. Причем функционал у обоих направлений разный. А работа с данными будет с одними и теме же. Одни собирают информацию и формируют документы, а другие анализируют данные и формируют свои документы. Причем вторые вмешиваться в корректировку информации не имеют права. В добавок вторым интерфейс первых не нужен. Как то так

> Будет видно уже и что требуется от плагинов
Вот тут да. Для меня пока непонятно каким должен быть интерфейс для плагина.

> Как минимум 30-50% думаю можно сделать без нормальной архитектуры
Предположим возможно. Да, что предполагать - возможно.

> а позже уже переделывать
а если в процессе разработки мне захочется внедрить функционал вот такого приложения.
http://www.sasgis.org/sasplaneta/
а при изучении вопроса будет вывод, что проще все заново переписать, чем внедрять. Я думаю и желание вообще пропадет этого делать.

Вот разработчикам этого приложения я задавал вопрос. Вот требуется поворот карты в плоскости 2D. Возможно ли у них это реализовать. Так вот там встал вопрос в том, что изначально это было не предусмотрено. А сейчас за даром вряд ли кто возьмется.

Ну не знаю надо подумать...

видимо вы описали монорепозитарий git для своего проекта. Когда все ведут работу в одном и том же проекте. Но тут будет уже сложности, когда будут меняться api и между компонентами будет возникать проблема с поддержкой различных версий приложения

> Как минимум 30-50% думаю можно сделать без нормальной архитектуры
и еще на эту тему. Зачем тратить ресурсы ПК на то, что кому-то это не надо. Но так как все в куче, то подгружается и занимает и использует русурсы .