buggy behaviour generating htmlToC

[DiapDealer]

Originally Posted by philja

After making the new htmlToC file, the <?xml version....>and <!DOCTYPE....> are both written to the same line whereas they were not in the original htlmlToC file. The act of overwriting it caused that corruption. see attached image.

When I create a new html toc (nothing to be overwritten) both the <?xml version....>and <!DOCTYPE....> are both written to the same line as well.

So I don't think it's the overwriting that's the problem. It's the creation of the html toc code period. And like Kevin mentioned, this has probably been around forever. It's just that most people used pretty print at some point (which fixed it). You're only noticing it because of a) the cursor bug, and b) the existing toc that already had those two elements on different lines for you to compare to.

Start with an empty epub and create an html toc. You'll see the the <?xml version....>and <!DOCTYPE....> on the same line. It's been that way for a long time.

[philja]

Originally Posted by KevinH

But as I already said, I can drop the busy icon right before the message box and restore it, so that this works on Tahoe too. It has been that way for over 5 years with no issues on any of my Macs. So it is only a Tahoe thing.

Will removing the busy icon then make the dialog close automatically after clicking on Yes or No? If so, that would be fine.

[philja]

Originally Posted by DiapDealer

When I create a new html toc (nothing to be overwritten) both the <?xml version....>and <!DOCTYPE....> are both written to the same line as well.

So I don't think it's the overwriting that's the problem. It's the creation of the html toc code period. And like Kevin mentioned, this has probably been around forever. It's just that most people used pretty print at some point (which fixed it). You're only noticing it because of a) the cursor bug, and b) the existing toc that already had those two elements on different lines for you to compare to.

Start with an empty epub and create an html toc. You'll see the the <?xml version....>and <!DOCTYPE....> on the same line. It's been that way for a long time.

I see what you mean. That's something I never did before.

All my work has a Contents page before converting to epub. And if I edit a text page with a new header, I update the htmlToC manually in Code View - never been a problem. I noticed it this time because I was explaining to someone who wasn't happy editing directly in Code View.

From Kevin and Becky's posts, it looks like that won't happen in future. No more misalignment between Preview and Code View. I was more worried about Mac giving the impression that Sigil had stalled.

[KevinH]

With BeckyEbook's latest PR merged and my change to the use of the busy cursor, this should now be fixed.

Will removing the busy icon then make the dialog close automatically after clicking on Yes or No? If so, that would be fine.

The problem is I purposefully have no macOS Tahoe machines to test it with. But all works okay on macOS Sequoia and earlier. Hitting Yes or No does close the message box automatically on all of my machines, just like everyplace else it is used in Sigil.

Again, official Qt support for Tahoe is just being released now in later Qt versions. So when we update Qt versions, we will get those fixes if you still are having trouble after our next release.