In this case, not so automatically and not so repeatedly, only when a js file were added and linked (unlinked) because the property "scripted" must be added (or removed) to the respective item in content.opf. How much time can waste Sigil running that command? One second, two perhaps? :) And that ONLY when a .js file is added (or removed). Of that way, the linking (unlinking) process will be completed because the property "scripted" will have been written (deleted) also in content.opf.

Adding any svg or adding an link to an external resource, adding an inline script even moving code via copy and paste may require updating manifest properties but there is no way for Sigil to determine that since they were introduced by text editing.

So if you are editing epub3s, there really is a good reason to use the Update Manifest Properties tool last, right before running epubcheck and doing the final save. Having link javascript do it is no guarantee is has been done properly until after all text editing is done.

Sorry but this is not a good idea as it may lead the user into thinking their manifest properties are correct when they are actually not.

As I explained you can not remove the script manifest property just because you unlinked a javascript. There can still be mathml scripts, inline javascripts in head, and links to external javascripts inside the body.

It is important for epub3 devs to get into the habit of running it once before the final run of epubcheck and final save as it could be needed due to other text edits/changes.

All that said ... the actual change in Sigil's code to do this is quite easy to do.

It is basically a one line change in MainWindow.cpp in the routine to link/unlink javascripts to call the opf's UpdateManifestProperties routine with the list of impacted resources.

I would be happy to post a diff with that small change if you do build your own.

No problem Kevin :) I just wanted to be free from the worry of updating the .opf file. But as you say, it just a couple of mouse clicks or a key shortcut.

Okay, I see that in other places in the Sigil source code I already call:

on a limited set of resources.

So I was being a big hypocrite saying "we should not" when we already do in two other places in the source code. I had forgotten about them. And I hate being a hypocrite.

So I have decided to run UpdateManifestProperties on just the resources touched by linking of the javascripts in that routine.

**BUT** [climbs back on to my soapbox!]
I still think it is really really important to run UpdateManifestProperties on *all* xhtml resources as one of the final steps since just text editing can create the need for it and there is no way for Sigil to easily tell if it is needed.

Of course Kevin and thanks a lot, thanks a lot! :thanks:

Seeing Flightcrew in this list: I've often encountering errors from flightcrew coming from non-sigil-structured ebboks where FC has problems of finding the file. Its present, but i guess FC has some hardcoded paths where it assumes the files but the structure of the ebook does not contain the folder FC is trying to look at. Restructering the epug to Sigils default structure resolves those error.

I will try to create a sample. Or is FC more or less dead and will not be maintained any more?

More likely FC is detecting an incorrect case in a path that just seems to work due to testing on case insensitive file system. If you have a testcase that shows the error with FC please post it.