CMake project reloading.

[Olivier J. G.]

> No, if the items where ref-counted the second file wouldn't be deleted by
> reloading the model. Instead it would be deleted once the code that
> actually tries to remove it from the model lets its handle go. This may
> cause duplicated items during the whole update-operation, but thats ok
> IMHO.

I totally failed to think that one through.

>
> I never was fond of that reload method, IMHO the project managers should be
> able to better keep track of things. So if a file X is deleted and removed
> from the cmakelists.txt, they wouldn't just drop the whole folder from the
> model. Instead they'd parse the updated file and generate some kind of
> "difference" between the old and the new state and apply the necessary
> deletions/additions of subitems only. Yes this is more complex than a
> complete reload, but its (IMHO) also the "right way" to do it.

Ref-counted or not, it seems dreadfully obvious now that these items
shouldn't be tied to the TreeView.
That is, the ProjectItem should be it's own entity, not a
QStandardItem derivative. In this way, the "right way" isn't so far
off, just the "diffing" would happen on a different level.
When CMakeLists is changed, the manager could generate a new set of
ProjectItems based on it, and compare that with the existing set.
Changing the references, deleting and adding as needed. The tree would
then become a client of the project model instead of the master of it.
At the very least, the reload could then happen in the background.

-Olivier JG