The Build Novel Project preview may be stale

[johnblommers]

Suppose you've done a Build Novel Project and then realize you need to make a change. So you dismiss the Build Novel Project dialog box and make changes. Then you return to the Build Novel Project dialog and do a Save As. Oops. You're not capturing the changes you just made.

This is too easy a mistake to make. May I suggest that the Build Novel Project dialog box be tweaked to make it clear it's not current?

• Perhaps the Build Project button should be relabeled as Rebuild Project (The Preview is Stale) and colored red.
• Or perhaps novelWriter should automatically rebuild the project if a change was made since it was last invoked
• Or perhaps the preview itself should be covered with a diagonal watermark reading "Stale."
• Or add a little box labeled "Automatically Rebuild Project" next to the Build Project button. Every time

From what I can see, novelWriter can build a project so damned fast that I think the last suggestion might be the best one.

Now I realize that the writer can have the Build Novel Project dialog open alongside novelWriter's main window. This means they can be making edits in novelWriter and expect to see a live preview in the Build Novel Project windows. And that's a good thing.

[vkbo]

I'm aware of this shortcoming, but thanks for the suggestions. I agree there should be some way of alerting the user that the content isn't built automatically. The text that is displayed when you open the tool is just the last build data from the project cache folder.

I don't want it to be automatically rebuilt, because on a big project it can take a bit of time and give the impression that the GUI freezes. But novelWriter has a time stamp on the age of the index, which is updated each time a file change is saved. I can easily use this to pop up a message in the preview window that states that the content has changed since last build.

I think that is the best solution. I'll add it for next release. Thanks for the suggestion!

[vkbo]

Looking at the source code now, I realise a few things I didn't consider when I responded this morning.

While there are three timestamps in the index that track changes (when the last novel file was changed, last note file was changed, and last file of any kind was changed), these are also updated on auto-saves, and they don't actually record if any data was altered. Any call to save is assumed to be an edited file.

What this effectively means, is that the build tool document would always be flagged as stale, regardless of whether it actually is or not, max 30 seconds after it was generated.

I think, instead, a more useful and perhaps less dramatic way of telling the user of the state of the document, is to just add a time stamp for when it was generated and put that above the document itself like a notice.

As for the suggestion to automatically build, I have been tinkering with a way of running all HTML conversion in the background, and if I do come up with a good implementation, there wouldn't be an issue with running the whole build on a timer in the background here either. It wouldn't make the main GUI thread freeze for the second or two it takes to run.

You're also right that the build tool is not in a modal dialog, so it doesn't block the main GUI. That is intentional as it gives you the option to quickly make fixes without having to close and re-open it.

[vkbo]

Ok, so in PR #336 I've added a label (as a header bar like in the document editor and viewer) that spans the top of the document in the build tool where the age of the build document is stated, including a fuzzy time string to make it easier to spot its age at a glance. It uses the background and text colours for the tooltip so it stands out a bit more.

Of course, as there hasn't been a time stamp yet, the first time this is used it will just say "Build Time: Unknown".

[johnblommers]

This does the trick.

[vkbo]

Great! I think we can close this now then.