Two Monitors and Preview

Turtle91 · 12-30-2019, 11:54 AM

I got a new monitor - yay Christmas! - and thought I'd see if Sigil (v1.0.0) still had it's second monitor crashing issue....and yes, it does.

Both monitors are the same model (3840x2160) running on Windows 10 (latest version). I have the desktop extended in the vertical direction - secondary monitor above primary. Although, the crash still occurs whether its extended vertically or horizontally; and it crashes even when I reduce the resolution on both monitors down to 1024x768 (talk about unnatural!

).

The problem happens when I try and instantiate the undocked Preview Pane (PP) on the secondary monitor. This can be done either by:
1 - having Sigil main window on the secondary monitor and then double clicking the PP to undock it

or

2 - closing Sigil with the PP undocked on the secondary monitor - the next time I run Sigil the PP tries to reopen on the secondary monitor

It's important to note that undocking the PP on the primary monitor then moving it to the secondary works just fine - it only crashes when the PP is initialized on the secondary.

Once Sigil crashes the work-around is to delete (or rename) the Sigil.ini file and then Sigil opens with the PP re-docked. However - I went back and did some testing with the .ini file. I copied pieces of the original .ini into the newly generated .ini and tested by opening Sigil. It opened just fine every time. ie, It eventually opened just fine with all the original .ini information.

I've attached my .ini files (created after closing with PP undocked on the primary monitor - which works fine, and another one after closing with PP undocked on the secondary monitor - which crashes) in case that helps. I've also attached an image with the two files compared showing the small changes in the "[mainwindow] toolbars" section.

FYI - I also left the Saved Searches and the Special Character windows open on the secondary monitor when I closed Sigil. Those windows were closed when Sigil restarted, as they should be, so I think this is specific to the PP.

Does anyone have an idea? Is there an .ini setting that tells Sigil to have the PP docked on open??

Turtle91 · 12-30-2019, 12:08 PM

Quote:

Originally Posted by Turtle91

...

FYI - I also left the Saved Searches and the Special Character windows open on the secondary monitor when I closed Sigil. Those windows were closed when Sigil restarted, as they should be, so I think this is specific to the PP.

...

I didn't mean to imply that having these windows closed automatically was a desirable solution. It's just the way Sigil normally works.

It would be preferable for Sigil to keep the configuration/position of the previous work environment - including Saved Searches and Special Characters windows.

DiapDealer · 12-30-2019, 01:25 PM

I've done my level best to try and recreate this crash. I can't (when the version of Qt shipping with Sigil was 5.12.3). No matter what dockwidgets I undock and leave on the secondary monitor when closing Sigil (Windows 10 latest version), I can't get it to do anything but start up normally (with the widgets opening on the second monitor like they are supposed to). Old INIs, new INIs, same resolution monitors, different resolution monitors. I'm drawing a complete blank here.

DiapDealer · 12-30-2019, 01:35 PM

Quote:

Originally Posted by Turtle91

It would be preferable for Sigil to keep the configuration/position of the previous work environment - including Saved Searches and Special Characters windows.

And the Metadata editor and the Index editor, and the Toc Editor, and the Preferences dialog, and the Spellcheck dialog, and the Reports dialog--heck! Let's just restore 'em all!

In all seriousness though, none of those are dock widgets (and won't be). We'll remember their size next time those tools' dialogs are used, but that's about it.

theducks · 12-30-2019, 02:39 PM

FWIW I have a pair of 1080 monitors Over/under like Turtle91, but no crash. although, the last position of child windows is not always remembered.

Turtle91 · 12-30-2019, 02:46 PM

Quote:

Originally Posted by DiapDealer

And the Metadata editor and the Index editor, and the Toc Editor, and the Preferences dialog, and the Spellcheck dialog, and the Reports dialog--heck! Let's just restore 'em all! ...

Now you got it!!!

KevinH · 12-30-2019, 09:58 PM

From your ini file it shows that in both cases the Sigil app is Maximized.

Does this crash happen if you do not have Sigil maximized?

KevinH

Quote:

Originally Posted by Turtle91

I got a new monitor - yay Christmas! - and thought I'd see if Sigil (v1.0.0) still had it's second monitor crashing issue....and yes, it does.

Both monitors are the same model (3840x2160) running on Windows 10 (latest version). I have the desktop extended in the vertical direction - secondary monitor above primary. Although, the crash still occurs whether its extended vertically or horizontally; and it crashes even when I reduce the resolution on both monitors down to 1024x768 (talk about unnatural!

).

The problem happens when I try and instantiate the undocked Preview Pane (PP) on the secondary monitor. This can be done either by:
1 - having Sigil main window on the secondary monitor and then double clicking the PP to undock it

or

2 - closing Sigil with the PP undocked on the secondary monitor - the next time I run Sigil the PP tries to reopen on the secondary monitor

It's important to note that undocking the PP on the primary monitor then moving it to the secondary works just fine - it only crashes when the PP is initialized on the secondary.

Once Sigil crashes the work-around is to delete (or rename) the Sigil.ini file and then Sigil opens with the PP re-docked. However - I went back and did some testing with the .ini file. I copied pieces of the original .ini into the newly generated .ini and tested by opening Sigil. It opened just fine every time. ie, It eventually opened just fine with all the original .ini information.

I've attached my .ini files (created after closing with PP undocked on the primary monitor - which works fine, and another one after closing with PP undocked on the secondary monitor - which crashes) in case that helps. I've also attached an image with the two files compared showing the small changes in the "[mainwindow] toolbars" section.

FYI - I also left the Saved Searches and the Special Character windows open on the secondary monitor when I closed Sigil. Those windows were closed when Sigil restarted, as they should be, so I think this is specific to the PP.

Does anyone have an idea? Is there an .ini setting that tells Sigil to have the PP docked on open??

Turtle91 · 12-30-2019, 10:29 PM

Yes, it does.

I will test this out on a couple of other computers tomorrow to confirm the issue. Although it would be weird since I've gone through several upgrades - including completely fresh installs - on this computer. I think I posited the idea that having QT/python installed may have corrupted this machine, but was told that it doesn't.

DiapDealer · 12-31-2019, 08:36 AM

Quote:

Originally Posted by Turtle91

Yes, it does.

I will test this out on a couple of other computers tomorrow to confirm the issue. Although it would be weird since I've gone through several upgrades - including completely fresh installs - on this computer. I think I posited the idea that having QT/python installed may have corrupted this machine, but was told that it doesn't.

I do my best to sanitize all system environment variables that could potentially affect Sigil's Qt/Python, but they add new ones constantly. It's possible there's a leak somewhere (though I also have system versions of Qt and Python installed on my Sigil build/test machines). A formatted printout of your environment on the crashy machine(s) could prove useful. but why that kind of interference would only happen when there's a QDockWidget on a secondary monitor makes no sense to me.I

If you close preview on the second monitor before closing Sigil, does it open again on the secondary monitor after restarting Sigil (and subsequently opening Preview)?

Turtle91 · 12-31-2019, 08:44 AM

Quote:

Originally Posted by DiapDealer

I do my best to sanitize all system environment variables that could potentially affect Sigil's Qt/Python, but they add new ones constantly. It's possible there's a leak somewhere (though I also have system versions of Qt and Python installed on my Sigil build/test machines). A formatted printout of your environment on the crashy machine(s) could prove useful.

OK, how do I get a formatted printout?

DiapDealer · 12-31-2019, 08:58 AM

Quote:

Originally Posted by Turtle91

OK, how do I get a formatted printout?

I just knew that was going to be the next question when I posted it.

The unhelpful answer is that I would use python.

You can use SET (with no parameters) at a command prompt to get an unformatted dump of all variables. You can also redirect the output to a text file

SET > output.txt

You could also use Powershell and do something like:

Get-ChildItem Env: | Format-Table -Wrap -AutoSize

KevinH · 12-31-2019, 10:13 AM

The problem may be related to this Qt Bug:

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

It seems when a floating Window is restored, it should only appear on its main monitor, but the code in question does not do that for some configurations of displays and the floating window is either unaccessible or possibly crash?

DiapDealer · 12-31-2019, 01:46 PM

That's the one Kovid works around in calibre, right? I saw that, but I was under the impression that was related to problems when the second monitor is unavailable. The documentation implies that geometry of restoreGeometry will modified to be within the available geometry if it is deemed to be offscreen. I don't think the reporters of that bug are having issues when all monitors and requested geometries are available.

I suppose it could be related, though. Could we implement the work around very easily? We're using restoreState rather than restoreGeometry on QDockWidgets.

KevinH · 12-31-2019, 02:23 PM

Yes that is the one. We can apply Kovid's fix in MainWindow. We use both restoreGeometry and restoreState and the workaround provided in that Qt issue did as well but only the restoreGeometry call need be fixed.

I now have a new external monitor from Santa as well, so I should be able to test this as the lost floating qdockwidget is an issue on macOS as well.

I take a peak at it tomorrow.

Kevin

Quote:

Originally Posted by DiapDealer

That's the one Kovid works around in calibre, right? I saw that, but I was under the impression that was related to problems when the second monitor is unavailable. The documentation implies that geometry of restoreGeometry will modified to be within the available geometry if it is deemed to be offscreen. I don't think the reporters of that bug are having issues when all monitors and requested geometries are available.

I suppose it could be related, though. Could we implement the work around very easily? We're using restoreState rather than restoreGeometry on QDockWidgets.

Turtle91 · 01-03-2020, 08:05 PM

Sorry for not getting back...my testing led to further testing...

So, I tried two other computers in my house - both Windows 10 - and neither of them showed this problem

Neither of them had Sigil installed before, it was a fresh install of 1.0.0 and it worked as advertised.

I went into my computer and removed QT, and python 3.7 - restarted the computer and Sigil crashes.

The QTBUG-77385 you referenced does sound similar-ish. Hopefully it works - I don't relish wiping the hard drive and doing a fresh install!

Thanks for checking into it again.

12-30-2019, 01:25 PM	#3
DiapDealer Grand Sorcerer Posts: 28,574 Karma: 204127028 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	I've done my level best to try and recreate this crash. I can't (when the version of Qt shipping with Sigil was 5.12.3). No matter what dockwidgets I undock and leave on the secondary monitor when closing Sigil (Windows 10 latest version), I can't get it to do anything but start up normally (with the widgets opening on the second monitor like they are supposed to). Old INIs, new INIs, same resolution monitors, different resolution monitors. I'm drawing a complete blank here. Last edited by DiapDealer; 12-30-2019 at 01:27 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Display on UHD (4k) monitors	Edwin49	Sigil	6	06-18-2018 07:12 PM
Any monitors with E Ink Vizplex technology?	drtom	News	32	05-04-2014 10:26 PM
Calibre Interface on large monitors	Maxx900	Calibre	6	09-18-2012 01:18 PM
Rude monitors	jswinden	Feedback	20	09-27-2009 07:08 PM
Kindle Monitors All Activity?	DavidH13	Amazon Kindle	34	08-18-2008 03:01 PM

12-30-2019, 02:39 PM	#5
theducks Well trained by Cats Posts: 31,062 Karma: 60358908 Join Date: Aug 2009 Location: The Central Coast of California Device: Kobo Libra2,Kobo Aura2v1, K4NT(Fixed: New Bat.), Galaxy Tab A	FWIW I have a pair of 1080 monitors Over/under like Turtle91, but no crash. although, the last position of child windows is not always remembered.

12-30-2019, 10:29 PM	#8
Turtle91 A Hairy Wizard Posts: 3,355 Karma: 20171571 Join Date: Dec 2012 Location: Charleston, SC today Device: iPhone 15/11/X/6/iPad 1,2,Air & Air Pro/Surface Pro/Kindle PW & Fire	Yes, it does. I will test this out on a couple of other computers tomorrow to confirm the issue. Although it would be weird since I've gone through several upgrades - including completely fresh installs - on this computer. I think I posited the idea that having QT/python installed may have corrupted this machine, but was told that it doesn't.

12-31-2019, 10:13 AM	#12
KevinH Sigil Developer Posts: 8,766 Karma: 6000000 Join Date: Nov 2009 Device: many	The problem may be related to this Qt Bug: https://bugreports.qt.io/browse/QTBUG-77385 It seems when a floating Window is restored, it should only appear on its main monitor, but the code in question does not do that for some configurations of displays and the floating window is either unaccessible or possibly crash?

12-31-2019, 01:46 PM	#13
DiapDealer Grand Sorcerer Posts: 28,574 Karma: 204127028 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	That's the one Kovid works around in calibre, right? I saw that, but I was under the impression that was related to problems when the second monitor is unavailable. The documentation implies that geometry of restoreGeometry will modified to be within the available geometry if it is deemed to be offscreen. I don't think the reporters of that bug are having issues when all monitors and requested geometries are available. I suppose it could be related, though. Could we implement the work around very easily? We're using restoreState rather than restoreGeometry on QDockWidgets.

01-03-2020, 08:05 PM	#15
Turtle91 A Hairy Wizard Posts: 3,355 Karma: 20171571 Join Date: Dec 2012 Location: Charleston, SC today Device: iPhone 15/11/X/6/iPad 1,2,Air & Air Pro/Surface Pro/Kindle PW & Fire	Sorry for not getting back...my testing led to further testing... So, I tried two other computers in my house - both Windows 10 - and neither of them showed this problem Neither of them had Sigil installed before, it was a fresh install of 1.0.0 and it worked as advertised. I went into my computer and removed QT, and python 3.7 - restarted the computer and Sigil crashes. The QTBUG-77385 you referenced does sound similar-ish. Hopefully it works - I don't relish wiping the hard drive and doing a fresh install! Thanks for checking into it again.