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.

[philja]

Back to my MacBook this morning and further checking shows that the Create HTML Table of Contents is completely broken in Tahoe 26.5.1.

The dialog which opens (with the busy cursor) and asks whether to overwrite or not the existing ToC has the 'No' button highlighted by default. No matter where you click, Sigil always generates a new TOC.xhtml file. (You still have to manually close the dialog).

I'm not sure changing the cursor will improve that.

[KevinH]

If dropping the busy cursor does not help on Tahoe, then you should see that same problem in all the yes/no dialogs used throughout Sigil. Are other yes/no Sigil dialogs broken under Tahoe?

If not, then that fix should be enough. If so, then we still need to get some sort of changed yes/no message box working for Tahoe.

[KevinH]

According to a websearch. Tahoe on Qt 6.10+ has broken native modal message dialogs in Qt. I will look to see if on MacOS we can always default to non-native modal dialog boxes for MacOS. We use non-native dialog boxes in most places in Sigil anyway. A few more places won't hurt.

And it looks like this breakage happens for any mondal native dialog. So Qt recommends never using modal dialogs, which of course makes no sense whatsoever in many cases. That was the whole point of modal dialogs.

I will push changes to move completely away from native dialogs on macOS as completely rewriting the flow in Sigil just to make asynchronous message dialogs just for Tahoe is for the birds.