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.

[KevinH]

Okay, it took a bit of fiddling in Utility.cpp to map the proper QMessageBox standard dialogs (warning, question, information, critical) to be native on all platforms *but* macOS where they are now non-native with my latest push.

This should completely workaround the Tahoe stupidity that Apple introduced just to get their huge rounded corner Liquid gui theme going that no one ever asked for or wanted. And to think it is 8 months after the Tahoe first release and Qt is still really broken in this regard! And to make matters worse a new MacOS version was announced back in the June in the MacOS dev conference that will go live sometime in early October.

The macOS OS update schedule is really and truly broken but no one at Apple seems to care. Steve Jobs is probably turning over in his grave.

When the ci builds are done I will post an arm64 build for you to try and Tahoe just to confirm the changes do in fact help.

Thanks for your bug report.

[KevinH]

Okay, I have used our Sigil CI actions to create a Sigil.app-2.8.1-Beta-Mac-arm64.tar.xz build that I properly code signed (but have not notarized).

Your should be able to download that build from here:

https://github.com/kevinhendricks/Bu...nMac/releases/


Please download and install that build on your Tahoe machine. It has all of the bug fixes to date so if it works you can keep using it.

Please try your creation of a Html TOC and let me know if the non-native message box with the Yes or No works as expected even on Tahoe.

If it works, great, we will keep it. If not, I will revert all those change as all it really adds is a bit of code bloat for no gain.

There is a way to set a Mac Apps Info.plist to force it to use the previous gui for your App. If the changes I made did not help, we can try adding that to Sigil next.

Hope this does the trick.

Thanks!

[philja]

Originally Posted by 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.

I'd never come across that problem before on the MacBook on any dialogs.

To be honest, I've never previously used the tool to generate an htmlTOC. All my books have author made Contents. On this occasion I was verifying what happened before helping another author with her htmlToC.

Just now, I've checked all the 'tools' including epub3 tools on the MacBook and the only one which has this dialog problem is the generate htmlTOC tool.

[philja]

Originally Posted by KevinH

Your should be able to download that build from here:

https://github.com/kevinhendricks/Bu...nMac/releases/


Please download and install that build on your Tahoe machine. It has all of the bug fixes to date so if it works you can keep using it.

Please try your creation of a Html TOC and let me know if the non-native message box with the Yes or No works as expected even on Tahoe.

If it works, great, we will keep it. If not, I will revert all those change as all it really adds is a bit of code bloat for no gain.

There is a way to set a Mac Apps Info.plist to force it to use the previous gui for your App. If the changes I made did not help, we can try adding that to Sigil next.

Hope this does the trick.

Thanks!

I've downloaded the 2.8.1-beta build. Mac protests about being a download from the internet and says "Sigil2.app" not opened. Only 2 choices - Done and move to Bin

Got around that - testing now.

[philja]

Well, Kevin, it looks like good news. The create htmlTOC dialog now works like any other. Normal cursor, 'No' selected by default, 'Yes' is selectable. When either button is selected, the dialog closes and the action is completed.

Code View and Preview line up well.

Just one comment. If the tool is selected and you decide not to go ahead and then click the red dot to close the dialog, a new TOC.xhtml file gets generated by default. Even if, having mistakenly opened that dialog, you use the esc key to get out of it, it still creates another TOC file.

Is it possible not to have a button selected by default when that dialog is opened?

[KevinH]

The code Sigil has and uses in the TOCHTML creation routine only looks for a binary result, yes or no.

The default of no, will create something new, not overwriting anything so it is safer. Simply selecting the newly generated file in BookBrowser and using the pop up delete function will get you back to the exact same state you began with. No harm, no foul.

So changing the default to nothing or yes is not something we will be adding for safety reasons.

Also, users of Sigil should very quickly learn to use its Checkpoint features. It is what it was created for.

[philja]

Originally Posted by KevinH

The code Sigil has and uses in the TOCHTML creation routine only looks for a binary result, yes or no.

The default of no, will create something new, not overwriting anything so it is safer. Simply selecting the newly generated file in BookBrowser and using the pop up delete function will get you back to the exact same state you began with. No harm, no foul.

So changing the default to nothing or yes is not something we will be adding for safety reasons.

Also, users of Sigil should very quickly learn to use its Checkpoint features. It is what it was created for.

OK, that's fine. Thanks for the rapid fix.