Keep stats for the word count over time

[ByteOfBrie]

It seems pretty trivial to write the current word count every time the project saves, which is really all the information that's needed. The total word count is a pretty trivial amount of data, and then it can be graphed somewhere.

There are probably also some interesting stats that could be extracted once the revisions are more stable, but just the word counts are easy to do for now.

[obw]

@ByteOfBrie Trivial, is relative! My biggest project which I handle with Manuskript, is round about 1 million Words and more than 300 chapters. You can see it like a web-novel.
I will also have five iterations, at least, for every chapter, before it is in the final State. As long, when I click on the root, Manuskript need a little more than half an hour, so I can work again, everything, which could further decrease the performance, is something, I don't think is a good Idea.

I can see where the wish comes from to have some statistics, which show the progress, if Manuskript could handle this concurrent, it would be nice and cool, but as long, it runs only with one thread, not so.

[TheJackiMonster]

I think the problem with word counts as pre-stored metadata (only calculated at specific operations to be stored) is that Manuskript essentially uses human readable files that can be edited with other applications in between different sessions using Manuskript. So it's not always certain a word count would be accurate.

I assume it would need to be verified at least during initial load.

[TheJackiMonster]

I should also add that we technically have a solution to improve word counting on the GTK branch which effectively makes the calculation asynchronous. So the project can load before calculating all word counts. Then if the application goes idle, it starts the routine to processes each scene and chapter, updating the UI dynamically.

[ByteOfBrie]

Those are fair points, my "trivial" comment was based on the assumption that we already have that data, since Manuskript displays word counts in a lot of places. I somehow didn't think about the fact that files could be edited in another application, even though that's one of the main reasons I'm using Manuskript in the first place...

There are ways around that (store the metadata for all the files along with modtime, and then only re-index the files if the modtime has changed), but I would need to look more into the exact ways that Manuskript handles loading files to really have an answer there.

[TheJackiMonster]

[...] but I would need to look more into the exact ways that Manuskript handles loading files to really have an answer there.

It's also important to note that I have rewritten how Manuskript loads files in the GTK branch. But I wasn't able to port those changes into the current Qt code base yet. Because Qt handles a lot via model-view-controller approach while I personally think it just makes the whole source code extremely bloated... so I tried to reduce complexity while rewriting it.

For example the new idea is to have different file formats handles in different functions rather than merging all parts into one IO handling function. Also allowing to load and write different files of one project completely separate which the current main branch does not allow. Everything gets managed as one big pile which isn't great and I think this is an older approach which made sense when everything was coming from one archive (single file per project approach).

So the rewrite solves this single-file approach by extracting the single-archive file into a temporary directory on your system and treats it as a regular project afterwards. Only during a write process, it gets compressed to an archive again and the new file replaces the old one. That way it can't mess up your project file during incomplete IO operations.