Suggestions before releasing version 1.0 - Page 4

odamizu · 12-11-2019, 02:24 AM

Quote:

Originally Posted by KevinH

FWIW, a just pushed a quick and dirty submenu version a New menu so people can test it.

I gave the new submenu a whirl. My default in General Settings is epub3.

When I use submenu to create new epub2 then try to save it, my 10.13.6 Mac hangs and I end up having to force quit.

When I tested this on 10.15.1, Sigil actually crashed!

I emailed you crash reports and hang reports.

ETA: Playing with this some more and I am getting all sorts of warnings plus a crash when trying to create, save, and/or re-open epub2 on macOS 10.13.6:

When trying to save: "Changing package version inside Sigil is not supported. Use an appropriate output plugin to make the initial conversion."
When trying to re-open saved epub2: "Files exist in epub that are not listed in the manifest, they will be ignored. OEPBPS/toc.ncx"
When trying to re-open saved epub2: Opening this EPUB generated warnings. The OPF file does not contain an NCX file. Sigil has created a new one for you.

I apologize for this jumbled report. I am confusing myself on the steps to reproduce these warnings as the results are inconsistent, but using submenu to create epub2 when General Settings is set to epub3 is clearly problematic on my Mac

KevinH · 12-11-2019, 09:07 AM

Yes, definite bug. It seems somehow the version of the empty opf is not being properly determined when it is filled. So the new version must be passed along to the OPF constructor as well, at the very least.

As I said, this change is more than a bit invasive at least on macOS. I am on it.

Thanks for the testing and bug report!

KevinH

Quote:

Originally Posted by odamizu

I gave the new submenu a whirl. My default in General Settings is epub3.

When I use submenu to create new epub2 then try to save it, my 10.13.6 Mac hangs and I end up having to force quit.

When I tested this on 10.15.1, Sigil actually crashed!

I emailed you crash reports and hang reports.

ETA: Playing with this some more and I am getting all sorts of warnings plus a crash when trying to create, save, and/or re-open epub2 on macOS 10.13.6:

When trying to save: "Changing package version inside Sigil is not supported. Use an appropriate output plugin to make the initial conversion."
When trying to re-open saved epub2: "Files exist in epub that are not listed in the manifest, they will be ignored. OEPBPS/toc.ncx"
When trying to re-open saved epub2: Opening this EPUB generated warnings. The OPF file does not contain an NCX file. Sigil has created a new one for you.

I apologize for this jumbled report. I am confusing myself on the steps to reproduce these warnings as the results are inconsistent, but using submenu to create epub2 when General Settings is set to epub3 is clearly problematic on my Mac

DiapDealer · 12-11-2019, 09:32 AM

It's not just on the Mac. I get identical results on Windows when following odamizu's steps. If you wind up having to go much further down the rabbit hole to fix it, I'd say consider bailing on the whole thing/reverting and going with the plan you originally had.

KevinH · 12-11-2019, 10:05 AM

Okay, I have taken a shot at fixing the creation of empty OPF and NCX files by passing along version info.

I just pushed all of the changes to master.

And everyone should give a big "Thank you!" to BeckyEbook as she has designed/created all of the new icons for case-changing and for the New ePub2 and New ePub3 menus and toolbars!

Thank you Becky!

KevinH

KevinH · 12-11-2019, 10:09 AM

Hi Odamizu,

The crash reports you sent look identical to the same bug you had previously reported after running any PluginRunner dialog and then trying to open and use a new Window.

For some reason Qt 5.12.6 seems to tickle that bug more than Qt 5.12.3 did.

I have tried to fix the underlying problem with create New ePub2 and ePub3 so that this problem will hopefully go away.

But please grab the latest build form Travis (please wait for the any current build to complete first) and see if you can get it to crash with this or your earlier approach to generating crashes.

I can not on my macOS machine but tickling that bug on my machine has always been hard.

Hope this does the trick.

KevinH

Quote:

Originally Posted by odamizu

I gave the new submenu a whirl. My default in General Settings is epub3.

When I use submenu to create new epub2 then try to save it, my 10.13.6 Mac hangs and I end up having to force quit.

When I tested this on 10.15.1, Sigil actually crashed!

I emailed you crash reports and hang reports.

ETA: Playing with this some more and I am getting all sorts of warnings plus a crash when trying to create, save, and/or re-open epub2 on macOS 10.13.6:

When trying to save: "Changing package version inside Sigil is not supported. Use an appropriate output plugin to make the initial conversion."
When trying to re-open saved epub2: "Files exist in epub that are not listed in the manifest, they will be ignored. OEPBPS/toc.ncx"
When trying to re-open saved epub2: Opening this EPUB generated warnings. The OPF file does not contain an NCX file. Sigil has created a new one for you.

I apologize for this jumbled report. I am confusing myself on the steps to reproduce these warnings as the results are inconsistent, but using submenu to create epub2 when General Settings is set to epub3 is clearly problematic on my Mac

KevinH · 12-11-2019, 10:24 AM

I am wondering, if we should remove New Default from the File *toolbar* as the number of icons there has grown considerably since we expanded the plugin icons to 10.

I seem to be running out of screen room quite quickly on my laptop.

If you are going to press an icon instead of use the menu, knowing if you want a new ePub2 or new ePub3 side by side would seem to trump any need for a new Default icon doesn't it?

Thoughts?

Kevin

ps, You can assign shortcut keys to "New ePub2" and "New ePub3" in Sigil Preferences.

DiapDealer · 12-11-2019, 10:37 AM

Quote:

Originally Posted by KevinH

If you are going to press an icon instead of use the menu, knowing if you want a new ePub2 or new ePub3 side by side would seem to trump any need for a new Default icon doesn't it?

Thoughts?

Kevin

ps, You can assign shortcut keys to "New ePub2" and "New ePub3" in Sigil Preferences.

Makes perfect sense to me. With the new abilities, the default "New" is always going to essentially be a duplicate of one of the other two.

KevinH · 12-11-2019, 11:24 AM

Quote:

Originally Posted by DiapDealer

Makes perfect sense to me. With the new abilities, the default "New" is always going to essentially be a duplicate of one of the other two.

Just pushed it to master.

KevinH · 12-11-2019, 12:17 PM

That is good to know. We will have to somehow detect when the system changes its mode and completely repaint everything.

And we must detect this on all platforms as well.

Thanks for your testing, screen shots, and reporting back!

Kevin

Quote:

Originally Posted by odamizu

Okay, this is with Sigil-master-cb20306-build_num-292 on macOS Catalina 10.15.1.

Most of Sigil picks up Dark Mode. Some text is hard to read as it's dark-on-dark.

Preview does not pick up Dark Mode and remains white. Same with plugin panels (but not plugin runner box).

When in Dark Mode and go to Light Mode, Sigil does not fully return to normal — Code View remains dark but Book Browser turns light (Preview is always light, even in Dark Mode); however, the panel title bar remains dark. Switching back to Dark Mode turns Book Browser dark, but Code view remains light. Again the panel title bar is off. However restarting Sigil fixes everything.

I attach a bunch of screenshots

DiapDealer · 12-11-2019, 12:17 PM

Everything's working fine so far, by the way. After the fix to odamizu's initial report.

odamizu · 12-11-2019, 02:41 PM

Ran a couple really quick tests and build295 working fine for me, too (in terms of using the new toolbar buttons to create an epub2 when General Settings is set to epub3). Will run more thorough tests later today, but wanted you to know initial results looking good!

odamizu · 12-12-2019, 01:37 AM

Sadly, I succeeded in crashing Sigil. But the steps to reproducing it are so obscure I doubt most users would run into it. I report this only because you asked

I am running Sigil-master-431cd35-build_num-295 on macOS 10.13.6

Steps to crashing ... <snip> ...

I have emailed you 6 crash reports, 3 per method above.

P.S. I am happy to continue testing for you, but please don't chase this bug on my behalf as it's so obscure. Only chase it if you feel the need to for your own satisfaction.

Quote:

Originally Posted by KevinH

Hi Odamizu,

The crash reports you sent look identical to the same bug you had previously reported after running any PluginRunner dialog and then trying to open and use a new Window.

For some reason Qt 5.12.6 seems to tickle that bug more than Qt 5.12.3 did.

I have tried to fix the underlying problem with create New ePub2 and ePub3 so that this problem will hopefully go away.

But please grab the latest build form Travis (please wait for the any current build to complete first) and see if you can get it to crash with this or your earlier approach to generating crashes.

I can not on my macOS machine but tickling that bug on my machine has always been hard.

Hope this does the trick.

KevinH

KevinH · 12-12-2019, 08:00 AM

Thanks. Yes that is the exact same macOS specific bug we chased earlier. It can only impact macOS with its multiple main windows. The problem it seems is that using windowActivate is no longer a sufficient workaround.

The issue has to do with searching to see if a Window is modal or blocked by an earlier modal window and Qt keeps a modal window list internally that has stale data due to a race between when a window is deleted and when it is removed from the list. Unfortunately focus and the cursor are being reported as being in the just deleted main window as the cursor position is needed to determine the modal ancestry of the Window.. This causes the segfault.

I can not reproduce the problem in a standalone test case so reporting it to Qt would be worthless. It is definitely a race though. The current cursor should not be reporting itself to still be in a deleted window but sometimes that will happen.

So all I can say is try to avoid the problem by changing focus or swapping between multiple windows before bringing up New and trying to open another modal dialog.

This one is going to take a long time to track down.

DiapDealer · 12-12-2019, 09:00 AM

Make sure I didn't affect the plugin-related bug with my removal of the m_pluginMapper QSignalMap strategy. You were specifically deleting m_PluginMapper on the MacOS in MainWindow for modal dialog reasons (according to the comments in the code). But m_pluginMapper no longer exists, so I removed the code to delete it on MacOS. Perhaps there's something else that needs deleting instead RE plugin actions/objects? All connects/disconnects are still done as before, the QSignalMap object just went away.

EDIT: Oops. it appears the m_pluginMapper object is still defined in MainWindow.h. I'll need to get rid of that, but I can't imagine it would cause any problems as is?

KevinH · 12-12-2019, 11:09 AM

DiapDealer,

From searching, I do not think it is anything Sigil is doing per-se. Although please remove that m_pluginMapper from MainWindow.h and from the macOS specific delete in the destructor, just to be safe.

Based on a long search of bug reports, I think the bug that shows it happening is here:

https://bugreports.qt.io/browse/QTBUG-75326

I have tested a number of Qt patches and only one seems to help but it was abandoned by Qt due to potential other difficulties it may cause.

That said the clear platfromWindow pointer early in destroy() patch seems to prevent the problem with that issue's test case that the earlier workaround did not really fix, it just prevented a a specific type of crash. We are seeing other crashes in different areas related to modal dialogs and mainwindows being deleted when they had focus causing focus to get "lost" and things start to mess up.

This only impacts macOS and it is hard to hit as well and can be recreated even in Qt 5.12.3 and earlier Sigil builds.

KevinH

12-11-2019, 02:41 PM	#56
odamizu just an egg Posts: 1,586 Karma: 4300000 Join Date: Mar 2015 Device: Kindle, iOS	Ran a couple really quick tests and build295 working fine for me, too (in terms of using the new toolbar buttons to create an epub2 when General Settings is set to epub3). Will run more thorough tests later today, but wanted you to know initial results looking good! Last edited by odamizu; 12-12-2019 at 01:38 AM. Reason: clarity

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Feature Suggestions for Future Version	Authorspeak	Sigil	12	03-13-2014 12:21 PM
Releasing a chapter at a time?	jhempel24	Writers' Corner	24	03-15-2013 08:11 AM
Releasing updated eBooks	jhempel24	General Discussions	26	02-20-2013 07:26 AM
PRS 650 releasing on 09/16	sachinwalia	Sony Reader	6	09-09-2010 10:45 AM
Releasing Out of Print Books?	KindleKid	Reading Recommendations	6	12-05-2008 03:24 PM

12-11-2019, 09:32 AM	#48
DiapDealer Grand Sorcerer Posts: 27,549 Karma: 193191846 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	It's not just on the Mac. I get identical results on Windows when following odamizu's steps. If you wind up having to go much further down the rabbit hole to fix it, I'd say consider bailing on the whole thing/reverting and going with the plan you originally had.

12-11-2019, 10:05 AM	#49
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	Okay, I have taken a shot at fixing the creation of empty OPF and NCX files by passing along version info. I just pushed all of the changes to master. And everyone should give a big "Thank you!" to BeckyEbook as she has designed/created all of the new icons for case-changing and for the New ePub2 and New ePub3 menus and toolbars! Thank you Becky! KevinH

12-11-2019, 10:24 AM	#51
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	I am wondering, if we should remove New Default from the File toolbar as the number of icons there has grown considerably since we expanded the plugin icons to 10. I seem to be running out of screen room quite quickly on my laptop. If you are going to press an icon instead of use the menu, knowing if you want a new ePub2 or new ePub3 side by side would seem to trump any need for a new Default icon doesn't it? Thoughts? Kevin ps, You can assign shortcut keys to "New ePub2" and "New ePub3" in Sigil Preferences.

12-11-2019, 12:17 PM	#55
DiapDealer Grand Sorcerer Posts: 27,549 Karma: 193191846 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	Everything's working fine so far, by the way. After the fix to odamizu's initial report.

12-12-2019, 08:00 AM	#58
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	Thanks. Yes that is the exact same macOS specific bug we chased earlier. It can only impact macOS with its multiple main windows. The problem it seems is that using windowActivate is no longer a sufficient workaround. The issue has to do with searching to see if a Window is modal or blocked by an earlier modal window and Qt keeps a modal window list internally that has stale data due to a race between when a window is deleted and when it is removed from the list. Unfortunately focus and the cursor are being reported as being in the just deleted main window as the cursor position is needed to determine the modal ancestry of the Window.. This causes the segfault. I can not reproduce the problem in a standalone test case so reporting it to Qt would be worthless. It is definitely a race though. The current cursor should not be reporting itself to still be in a deleted window but sometimes that will happen. So all I can say is try to avoid the problem by changing focus or swapping between multiple windows before bringing up New and trying to open another modal dialog. This one is going to take a long time to track down.

12-12-2019, 09:00 AM	#59
DiapDealer Grand Sorcerer Posts: 27,549 Karma: 193191846 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	Make sure I didn't affect the plugin-related bug with my removal of the m_pluginMapper QSignalMap strategy. You were specifically deleting m_PluginMapper on the MacOS in MainWindow for modal dialog reasons (according to the comments in the code). But m_pluginMapper no longer exists, so I removed the code to delete it on MacOS. Perhaps there's something else that needs deleting instead RE plugin actions/objects? All connects/disconnects are still done as before, the QSignalMap object just went away. EDIT: Oops. it appears the m_pluginMapper object is still defined in MainWindow.h. I'll need to get rid of that, but I can't imagine it would cause any problems as is?

12-12-2019, 11:09 AM	#60
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	DiapDealer, From searching, I do not think it is anything Sigil is doing per-se. Although please remove that m_pluginMapper from MainWindow.h and from the macOS specific delete in the destructor, just to be safe. Based on a long search of bug reports, I think the bug that shows it happening is here: https://bugreports.qt.io/browse/QTBUG-75326 I have tested a number of Qt patches and only one seems to help but it was abandoned by Qt due to potential other difficulties it may cause. That said the clear platfromWindow pointer early in destroy() patch seems to prevent the problem with that issue's test case that the earlier workaround did not really fix, it just prevented a a specific type of crash. We are seeing other crashes in different areas related to modal dialogs and mainwindows being deleted when they had focus causing focus to get "lost" and things start to mess up. This only impacts macOS and it is hard to hit as well and can be recreated even in Qt 5.12.3 and earlier Sigil builds. KevinH