Sigil-0.9.991 (1.0 Pre-release) - Page 7

KevinH · 11-13-2019, 11:03 AM

Yes that did the trick. I have pushed a fix to "too fast closing tabs" to master. With these changes, I can not get Sigil to crash anymore.

We should probably re-enable drag and drop of tabs full time again, and see if that is now stable enough. I would guess that is probably is now.

KevinH

DiapDealer · 11-13-2019, 11:38 AM

I'm OK with that (Drag 'n Drop).

Thanks for the fix. And thanks @snarkophilus for putting the bug back on our radar TO fix!

KevinH · 11-13-2019, 12:20 PM

FYI: just pushed re-enabling of drag and drop in master so we can test to see if the last commit "fixes" things there as well.

I have my fingers crossed!

Tex2002ans · 11-13-2019, 12:33 PM

Quote:

Originally Posted by KevinH

FYI: just pushed re-enabling of drag and drop in master so we can test to see if the last commit "fixes" things there as well.

Fantastic choice. Drag-and-dropping tabs is so helpful for organization.

DiapDealer · 11-13-2019, 12:46 PM

Quote:

Originally Posted by Tex2002ans

Fantastic choice. Drag-and-dropping tabs is so helpful for organization.

It was always available. One just had to set an environment variable in order to enable it "at your own risk". But hopefully we can leave it enabled by default now, if there's no reports of it crashing.

Tex2002ans · 11-13-2019, 12:50 PM

Quote:

Originally Posted by DiapDealer

It was always available. One just had to set an environment variable in order to enable it "at your own risk". But hopefully we can leave it enabled by default now, if there's no reports of it crashing.

If an advanced user such as I—the greatest and best Sigil user of all time—hadn't gone out of his way to use that environment variable... I shudder to think how many typical users enabled that.

DiapDealer · 11-13-2019, 12:53 PM

For as handy as many say that it is; we only ever had a handful of people ask about it the whole time it was disabled by default.

snarkophilus · 11-13-2019, 05:22 PM

Quote:

Originally Posted by KevinH

So you are closing a whole bunch of CodeView Tabs who have tab sizes of about the same and after your mouse once after positioning it once over a tab close x, and repeatedly and quickly closing the tabs. Is that right?

Hi Kevin. That's almost right. Yes, closing CodeView tabs, but tab size doesn't really matter since I'm closing them all from the top right hand corner. I have a lot more tabs open than fit in my CodeView window.

I also forgot to mention that I'm on Windows 10.

(I'm at work now, can post a screenshot when I get home if that helps.)

EDIT: Yeah, yeah, I should have read the rest of this thread before replying to the first message after mine to realise the bug had both been discussed and fixed

. Thanks guys!

DiapDealer · 11-13-2019, 05:24 PM

Quote:

Originally Posted by snarkophilus

Hi Kevin. That's almost right. Yes, closing CodeView tabs, but tab size doesn't really matter since I'm closing them all from the top right hand corner. I have a lot more tabs open than fit in my CodeView window.

I also forgot to mention that I'm on Windows 10.

(I'm at work now, can post a screenshot when I get home if that helps.)

i think Kevin already fixed it. Grab the latest build and see if it still crashes for you.

snarkophilus · 11-14-2019, 03:07 AM

Quote:

Originally Posted by DiapDealer

i think Kevin already fixed it. Grab the latest build and see if it still crashes for you.

Well bugger. I've installed 0.991-21 and I can still preproduce the problem. It's definitely harder to trigger, but is still crashable.

I can reproduce it sort of easily by edtting the attached epub, opening all 50 images (a "open all selected files in tabs" wishlist suggestion?

), then holding down ctrl-W to close windows. More often than not, when the last image is closed, a few seconds later Sigil crashes. I had a harder time getting it to crash with only 20 tabs open.

Doitsu · 11-14-2019, 03:36 AM

Quote:

Originally Posted by snarkophilus

Well bugger. I've installed 0.991-21 and I can still preproduce the problem. It's definitely harder to trigger, but is still crashable.

I haven't been able to reproduce this bug on my Windows 10 (1909) machine with 0.9.991-21.

I've opened and closed all 50 images twice by pressing CTRL+W and didn't get a crash. Have you installed the Windows 10 1909 update?

EDIT: I didn't get a crash with the latest version on my Linux machine either. However, I got the following warning in the terminal window:

Code:

Warning: QObject::connect: No such signal ImageResource::Deleted(Resource)

BeckyEbook · 11-14-2019, 03:55 AM

I have Windows 10 Pro 1909 and I confirm the problem.
Fresh build.

But - I admit - this does not happen every time.

snarkophilus · 11-14-2019, 05:03 AM

Quote:

Originally Posted by Doitsu

I haven't been able to reproduce this bug on my Windows 10 (1909) machine with 0.9.991-21.

I'm still on 1809. I had one patch reboot two days ago to install 1909, and then yesterday an update popped up saying reboot to install 1909.

Quote:

Originally Posted by BeckyEbook

I have Windows 10 Pro 1909 and I confirm the problem.
Fresh build.

But - I admit - this does not happen every time.

Thanks for confirming I'm not totally crazy!

Certainly Kevin's recent change made the problem a lot harder to trigger, but it seems that there's still some sort of timing or signal niggle in there somewhere.

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

Then the issue must be happening with some other qt signal someplace else in the code. The code sequence that caused the first crash can simply not happen anymore. So I will try once again using macOS but if I can not get it to happen the remaining bug must be Windows specific.

KevinH · 11-14-2019, 09:15 AM

BTW, closing the final tab should not be allowed as that will always cause the app to close in Windows and Linux but not on macOSX. The code should prevent the final tab from ever going away.

Are you sure you are actually closing the final tab before the crash, or is it the next to last tab?

11-13-2019, 12:53 PM	#97
DiapDealer Grand Sorcerer Posts: 28,525 Karma: 204127028 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	For as handy as many say that it is; we only ever had a handful of people ask about it the whole time it was disabled by default. Last edited by DiapDealer; 11-13-2019 at 01:05 PM.

11-14-2019, 03:55 AM	#102
BeckyEbook Guru Posts: 834 Karma: 2657572 Join Date: Jan 2017 Location: Poland Device: Various	I have Windows 10 Pro 1909 and I confirm the problem. Fresh build. But - I admit - this does not happen every time. Last edited by BeckyEbook; 11-14-2019 at 04:00 AM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
5.8.11 Pre=release	knc1	Kindle Developer's Corner	21	04-17-2018 08:42 PM
Overdrive - Search for Pre-Release	nynaevelan	General Discussions	11	11-24-2013 02:27 PM
Where are the pre-release purchase buttons?	Sydney's Mom	General Discussions	8	09-06-2012 10:57 PM
KF Android 4.0 Pre-Release Version	robertc88	Kindle Fire	22	01-22-2012 07:24 PM
PDF Viewer 0.3.0 pre-release	pruss	Android Devices	62	11-22-2011 11:18 AM

11-13-2019, 11:03 AM	#91
KevinH Sigil Developer Posts: 8,704 Karma: 5703586 Join Date: Nov 2009 Device: many	Yes that did the trick. I have pushed a fix to "too fast closing tabs" to master. With these changes, I can not get Sigil to crash anymore. We should probably re-enable drag and drop of tabs full time again, and see if that is now stable enough. I would guess that is probably is now. KevinH

11-13-2019, 11:38 AM	#92
DiapDealer Grand Sorcerer Posts: 28,525 Karma: 204127028 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	I'm OK with that (Drag 'n Drop). Thanks for the fix. And thanks @snarkophilus for putting the bug back on our radar TO fix!

11-13-2019, 12:20 PM	#93
KevinH Sigil Developer Posts: 8,704 Karma: 5703586 Join Date: Nov 2009 Device: many	FYI: just pushed re-enabling of drag and drop in master so we can test to see if the last commit "fixes" things there as well. I have my fingers crossed!

11-14-2019, 09:11 AM	#104
KevinH Sigil Developer Posts: 8,704 Karma: 5703586 Join Date: Nov 2009 Device: many	Then the issue must be happening with some other qt signal someplace else in the code. The code sequence that caused the first crash can simply not happen anymore. So I will try once again using macOS but if I can not get it to happen the remaining bug must be Windows specific.

11-14-2019, 09:15 AM	#105
KevinH Sigil Developer Posts: 8,704 Karma: 5703586 Join Date: Nov 2009 Device: many	BTW, closing the final tab should not be allowed as that will always cause the app to close in Windows and Linux but not on macOSX. The code should prevent the final tab from ever going away. Are you sure you are actually closing the final tab before the crash, or is it the next to last tab?

Advert

Advert