История изменений

Да, является. Но всё никак не дойдут руки/мозги на подумать и вообще взвесить все «за» и «против» такого решения. Тем более, что в прямой реализации такого подхода есть и жирный минус: файлы через такие превдо-цели попадают в кодовую модель и... могут сломать парсинг. В заметке, что ты привёл, это упомянуто.

Как минимум, используя подход «проект - все файлы» уже длительное время, я вижу и его минусы: при большом количестве файлов становится труднее в них ориентироваться. Кроме того, засоряется и выхлоп Locator'а в QtC, особенно когда где-то завалялся вывод Doxygen, где файлов много, названия их частично совпадают с исходниками, сам выхлоп под игнорированием VCS, но впиливать подобные игнорирования в плагин, тоже костыль. Хотя стоит изучить возможности API QtC в этой части.

В общем, я склоняюсь, что нужна возможность добавления новых, добавления существующих файлов, их переименование в отображение проекта. Что бы это отображение можно было сохранять как дополнение к информации из CMakeLists.txt. Добавление файлов же в CMakeLists.txt оставить так же на плечах разработчика. Тем более, что сейчас уже существует возможность выделить файлы которые пришли из CMakeLists.txt и из других источников, которые закреплены за определёнными целями, а которые - нет. При первом же запуске, при отсутствии информации о дополнительных файлах, чистая основа будет взята именно из CMakeLists.txt. Есть ещё нюансы синхронизации: кто-то может работать вне QtC с проектом и что-то, что есть в общем, пусть будет CMakeLists.txt.qtc, может уже отсутвовать в файловой системе. Хотя, к примеру, в VS на это забивают, максимум к иконке дорисовывают восклицательный знак, типа файла на диске нет.

Вторым вариантом видится: оставить существующий подход со сканированием дерева, но настраиваемым фильтром, что (маска/mime) и по каким путям брать и отображать в проекте. Но тоже куча вопросов остаётся, типа где хранить настройку фильтра: если в CMakeLists.txt.user, то тогда придётся его настраивать при каждой новой загрузке проекта из репозитория.

Да, является. Но всё никак не дойдут руки/мозги на подумать и вообще взвесить все «за» и «против» такого решения.

Как минимум, используя подход «проект - все файлы» уже длительное время, я вижу и его минусы: при большом количестве файлов становится труднее в них ориентироваться. Кроме того, засоряется и выхлоп Locator'а в QtC, особенно когда где-то завалялся вывод Doxygen, где файлов много, названия их частично совпадают с исходниками, сам выхлоп под игнорированием VCS, но впиливать подобные игнорирования в плагин, тоже костыль. Хотя стоит изучить возможности API QtC в этой части.

В общем, я склоняюсь, что нужна возможность добавления новых, добавления существующих файлов, их переименование в отображение проекта. Что бы это отображение можно было сохранять как дополнение к информации из CMakeLists.txt. Добавление файлов же в CMakeLists.txt оставить так же на плечах разработчика. Тем более, что сейчас уже существует возможность выделить файлы которые пришли из CMakeLists.txt и из других источников, которые закреплены за определёнными целями, а которые - нет. При первом же запуске, при отсутствии информации о дополнительных файлах, чистая основа будет взята именно из CMakeLists.txt. Есть ещё нюансы синхронизации: кто-то может работать вне QtC с проектом и что-то, что есть в общем, пусть будет CMakeLists.txt.qtc, может уже отсутвовать в файловой системе. Хотя, к примеру, в VS на это забивают, максимум к иконке дорисовывают восклицательный знак, типа файла на диске нет.

Вторым вариантом видится: оставить существующий подход со сканированием дерева, но настраиваемым фильтром, что (маска/mime) и по каким путям брать и отображать в проекте. Но тоже куча вопросов остаётся, типа где хранить настройку фильтра: если в CMakeLists.txt.user, то тогда придётся его настраивать при каждой новой загрузке проекта из репозитория.