buggy behaviour generating htmlToC - Page 2

DiapDealer · Yesterday, 09:43 AM

Quote:

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 · Yesterday, 09:44 AM

Quote:

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 · Yesterday, 10:20 AM

Quote:

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 · Yesterday, 10:40 AM

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

Quote:

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 · Today, 03:17 AM

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 · Today, 07:15 AM

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 · Today, 09:39 AM

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 · Today, 12:20 PM

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 · Today, 12:41 PM

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!

Today, 09:39 AM	#22
KevinH Sigil Developer Posts: 9,770 Karma: 7000000 Join Date: Nov 2009 Device: many	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. Last edited by KevinH; Today at 10:49 AM.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Touch Kobo updated, now buggy	Cyclops	Kobo Reader	7	04-08-2016 08:25 PM
Is 0.8.4 buggy?	Gregg Bell	Sigil	47	10-16-2015 02:28 PM
PW 2 a little buggy?	Strether	Amazon Kindle	14	11-01-2013 11:49 AM
Test behaviour different to Calibre behaviour	louwin	Library Management	2	04-12-2012 07:34 PM
MyLibrary 0.14 = buggy	jhempel24	Barnes & Noble NOOK	2	01-30-2011 07:47 AM

Today, 03:17 AM	#20
philja Addict Posts: 379 Karma: 518 Join Date: Nov 2015 Location: Europe EEC Device: Kindle Fire HD6 & HD8	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.

Today, 07:15 AM	#21
KevinH Sigil Developer Posts: 9,770 Karma: 7000000 Join Date: Nov 2009 Device: many	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.

Today, 12:20 PM	#23
KevinH Sigil Developer Posts: 9,770 Karma: 7000000 Join Date: Nov 2009 Device: many	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.

Today, 12:41 PM	#24
KevinH Sigil Developer Posts: 9,770 Karma: 7000000 Join Date: Nov 2009 Device: many	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!

Advert

Advert