Bug: Tabs Closing While Link Stylesheets - Page 2

KevinH · 01-14-2019, 07:49 PM

Or just close the open BV tabs.

KevinH · 01-14-2019, 08:58 PM

So instead of blindly closing all open tabs, we instead call the tab manger to get a list of content tabs and try qobject casting them to FlowTabs and if they are a flow tab, then we call getviewstate and if and only if that tab is in BookView do we close that tab.

DiapDealer · 01-14-2019, 09:04 PM

Just closing the open BV tabs sounds fine to me.

Can you think of why BV would overwrite the new link data, though? I'm tempted to comment out the tab closure and test to see if I can still get it to mess up.

KevinH · 01-14-2019, 09:08 PM

No idea. That old commit messagewas not associated with any other detail. Your idea is worth testing just in case th original problem no longer exists.

DiapDealer · 01-14-2019, 09:33 PM

I think I will, just in case. Don't we ever make changes to the underlying html while the Book View tab is open in other routines?

KevinH · 01-14-2019, 10:01 PM

Yes but do we change external resources like a css stylesheet from inside BV or does that require reloading the new xhtml source so that it pulls in its newly linked stylesheet.

Not sure what else could be an issue.

DiapDealer · 01-15-2019, 05:54 PM

I can't see any issues with linking the stylesheets with BV (or CV, for that matter) left open during the process. Not on Linux at least.

Unfortunately, my testing seems to have exposed some ugly rendering issues I'm experiencing with Qt5.12.0. It appears to be similar to the recent issue reported on github that manifests immediately after BV/CV loses focus.

With an html tab open in Book View, click on Help->About. After dismissing the resulting About dialog, immediately change to CodeView. Before scrolling or doing anything else: clicking in CodeView to reposition the cursor introduces weird highlighting and missing/doubled lines of text. It's quite atrocious. Scrolling far enough up or down (with either the mousewheel or the vertical scrollbar) seems to remedy the problem.

It doesn't have to be the Help dialog. Any sort of focus activity (like the LinkStylesheets dialog) with BookView open will manifest the issue when first switching to CodeView.

Qt5.12.0 appears to be disaster for Sigil's CodeView.

At least it's not destructive.

KevinH · 01-15-2019, 06:28 PM

I will try building Qt 5.12.1 from source when it is released to test the syntax highlighting fixes. Until then I am sticking with Qt 5.11.2 as it appears to be a safe release.

KevinH · 01-16-2019, 09:59 AM

Instead I built Qt 5.12.0 in macOS last night and it built out of the box. Unfortunately the new webkit will NOT build against Qt 5.12.0 on Macs with the latest tool chain. So I have been unable to complete a Sigil build to start looking at it.

DiapDealer · 01-16-2019, 10:08 AM

I've been thinking about trying with Windows (I was able to build QtWebKit against Qt5.12.0 using my usual procedure), but the Qt bug-report mentioned in the recent github issue indicates that it's an X11 issue. As such, I assumed it wouldn't manifest in Windows. I'll try to do a build tonight to verify.

KevinH · 01-16-2019, 08:07 PM

Quote:

Originally Posted by DiapDealer

Unfortunately, my testing seems to have exposed some ugly rendering issues I'm experiencing with Qt5.12.0. It appears to be similar to the recent issue reported on github that manifests immediately after BV/CV loses focus.

With an html tab open in Book View, click on Help->About. After dismissing the resulting About dialog, immediately change to CodeView. Before scrolling or doing anything else: clicking in CodeView to reposition the cursor introduces weird highlighting and missing/doubled lines of text. It's quite atrocious. Scrolling far enough up or down (with either the mousewheel or the vertical scrollbar) seems to remedy the problem.

It doesn't have to be the Help dialog. Any sort of focus activity (like the LinkStylesheets dialog) with BookView open will manifest the issue when first switching to CodeView.

Qt5.12.0 appears to be disaster for Sigil's CodeView.

At least it's not destructive.

FWIW, I finally got qtwebkit to build with Qt 5.12.0 by disabling the building of qtwebkit test code. The test code is severely broken on macOS under XCode 10.

Interestingly, the late change to qsyntaxhighlighter.cpp did make it into Qt 5.11.3 but NOT into the official Qt 5.12.0 source archive. With official Qt 5.12.0 on macOS, I am not seeing any issues with CodeView at all. So whatever the problem, it appears to be Linux only.

DiapDealer · 01-16-2019, 09:05 PM

It's happening on Windows built against 5.12.0, too. I'd have been really suprised if it didn't. Qt bugs seem to affect either all three platforms, or Linux and Windows.

KevinH · 01-28-2019, 03:46 PM

A "fix" for this has just been pushed to master. Sigil will now close only impacted open tabs that are in BookView mode when linking in a stylesheet.

For safety sake, we still will close impacted open tabs that are in BookView to keep the BookView's contents from overwriting the inserted style sheet link info (effectively losing the link).

01-15-2019, 05:54 PM	#22
DiapDealer Grand Sorcerer Posts: 27,549 Karma: 193191846 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	I can't see any issues with linking the stylesheets with BV (or CV, for that matter) left open during the process. Not on Linux at least. Unfortunately, my testing seems to have exposed some ugly rendering issues I'm experiencing with Qt5.12.0. It appears to be similar to the recent issue reported on github that manifests immediately after BV/CV loses focus. With an html tab open in Book View, click on Help->About. After dismissing the resulting About dialog, immediately change to CodeView. Before scrolling or doing anything else: clicking in CodeView to reposition the cursor introduces weird highlighting and missing/doubled lines of text. It's quite atrocious. Scrolling far enough up or down (with either the mousewheel or the vertical scrollbar) seems to remedy the problem. It doesn't have to be the Help dialog. Any sort of focus activity (like the LinkStylesheets dialog) with BookView open will manifest the issue when first switching to CodeView. Qt5.12.0 appears to be disaster for Sigil's CodeView. At least it's not destructive. Last edited by DiapDealer; 01-15-2019 at 05:56 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Unifying stylesheets	roger64	ePub	6	08-22-2016 06:29 PM
Help with stylesheets in Calibre	hikerguy	Editor	8	04-01-2015 02:30 AM
Stylesheets	Phylis Sophical	Sigil	10	10-28-2014 03:56 PM
Alternate stylesheets	Jellby	ePub	1	08-19-2011 06:44 PM

01-14-2019, 07:49 PM	#16
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	Or just close the open BV tabs.

01-14-2019, 08:58 PM	#17
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	So instead of blindly closing all open tabs, we instead call the tab manger to get a list of content tabs and try qobject casting them to FlowTabs and if they are a flow tab, then we call getviewstate and if and only if that tab is in BookView do we close that tab.

01-14-2019, 09:04 PM	#18
DiapDealer Grand Sorcerer Posts: 27,549 Karma: 193191846 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	Just closing the open BV tabs sounds fine to me. Can you think of why BV would overwrite the new link data, though? I'm tempted to comment out the tab closure and test to see if I can still get it to mess up.

01-14-2019, 09:08 PM	#19
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	No idea. That old commit messagewas not associated with any other detail. Your idea is worth testing just in case th original problem no longer exists.

01-14-2019, 09:33 PM	#20
DiapDealer Grand Sorcerer Posts: 27,549 Karma: 193191846 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	I think I will, just in case. Don't we ever make changes to the underlying html while the Book View tab is open in other routines?

01-14-2019, 10:01 PM	#21
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	Yes but do we change external resources like a css stylesheet from inside BV or does that require reloading the new xhtml source so that it pulls in its newly linked stylesheet. Not sure what else could be an issue.

01-15-2019, 06:28 PM	#23
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	I will try building Qt 5.12.1 from source when it is released to test the syntax highlighting fixes. Until then I am sticking with Qt 5.11.2 as it appears to be a safe release.

01-16-2019, 09:59 AM	#24
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	Instead I built Qt 5.12.0 in macOS last night and it built out of the box. Unfortunately the new webkit will NOT build against Qt 5.12.0 on Macs with the latest tool chain. So I have been unable to complete a Sigil build to start looking at it.

01-16-2019, 10:08 AM	#25
DiapDealer Grand Sorcerer Posts: 27,549 Karma: 193191846 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	I've been thinking about trying with Windows (I was able to build QtWebKit against Qt5.12.0 using my usual procedure), but the Qt bug-report mentioned in the recent github issue indicates that it's an X11 issue. As such, I assumed it wouldn't manifest in Windows. I'll try to do a build tonight to verify.

01-16-2019, 09:05 PM	#27
DiapDealer Grand Sorcerer Posts: 27,549 Karma: 193191846 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	It's happening on Windows built against 5.12.0, too. I'd have been really suprised if it didn't. Qt bugs seem to affect either all three platforms, or Linux and Windows.

Advert

Advert

01-28-2019, 03:46 PM	#28
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	A "fix" for this has just been pushed to master. Sigil will now close only impacted open tabs that are in BookView mode when linking in a stylesheet. For safety sake, we still will close impacted open tabs that are in BookView to keep the BookView's contents from overwriting the inserted style sheet link info (effectively losing the link).