Strange bug editing in BookView

[AlanHK]

Originally Posted by DiapDealer

I'm afraid I don't follow. There's no difference in how Book View renders compared to Preview. Other than being able to edit, there's no difference between the two. They use the exact same QtWebKit renderer.

Except that sometimes Preview fails to scroll and is stuck at the top of the file, not in sync with the code window. So I often do a quick F2 .... F2 after entering some code to confirm it worked as expected.

[KevinH]

Not unless the cursor is not inside a local element, it reverts to its parent being the body tag which is the top of the file. So simply move the cursor to a local element and click.

[DiapDealer]

AlanHK always forgets to mention that he's using the Windows Legacy version of Sigil that's still built with Qt5.6.2, Community WebKit, and Python 3.4.x. Not to say that the same thing won't happen in the official latest version of Sigil, but until it's verified that it does ... apples and oranges.

Besides ... "Preview sometimes doesn't scroll" is hardly relevant to the portion of my post he quoted where I talked about how Preview and Book View both render the same code the same (because they use the same rendering engine).

[AlanHK]

Originally Posted by DiapDealer

Not to say that the same thing won't happen in the official latest version of Sigil, but until it's verified that it does ... apples and oranges.

All I know is what happens on my PC. I'd be rather surprised if this was something that depended on the version of Qt.

Originally Posted by DiapDealer

Besides ... "Preview sometimes doesn't scroll" is hardly relevant to the portion of my post he quoted where I talked about how Preview and Book View both render the same code the same (because they use the same rendering engine).

I didn't say they don't render the same, it's how they react.

But actually, now I know that it syncs up with the cursor, and not the visible code which is what I expected, it's more explicable, though still rather frustrating, for me at least.

When I am editing in codeview, my cursor is usually in the para I'm editing and want to preview so the Bookview will sync (and so will the preview).

But if I'm scrolling through the code (using mousewheel or scrollbar), the preview does not move, and if I switch over to it, it jumps back to the start; if I click in it it pulls the code page back to the start and I lose my position there too. So I blamed the preview, when it actually affects both "views".

Now I know it's all about the cursor, a workaround is always click in the text to put the cursor where you want to preview. If I use pageup/down to jump the cursor, it does sync, but not smoothly, a lag of a second. So here bookview is preferable: I can scroll through it smoothly, put the cursor in the text, F2 and be in the code. Disclaimer: maybe this is due to my own setup, YMMV.

Not that my preference matters, but I think it would be more intuitive if the preview display synced with the visible code screen, not wherever the cursor is, which is usually at the top of the file if you scrolled without clicking in the page.

[theducks]

Alan
Your jump is caused by not having the cursor insert point move with the scroll. If you just click in the text area (before clicking on the preview) , the preview syncs to that point

[BetterRed]

If you scroll the Codeview or Preview window with the mouse wheel you can bring the other one into sync by clicking in the window you're scrolling - that's simple enough. If you're scrolling by clicking in a scroll bar (does anyone actually do that) or sliding a scroll button it's the same, click in the window you were scrolling to bring the other window into synch.

But if you use the up/down Arrow or Page up/down keys to scroll you have to grab the mouse and click in the window in which you were using up/down Arrow or Page up/down keys - not as simple, and its easy to click in the wrong one and 'lose' your place. I'm keyboard centric, so this happens to me quite often.

---

It maybe worth noting how the calibre editor behaves in this regard.

If its Codeview or Preview windows are scrolled with the mouse wheel the other one is not kept in sync - i.e it's the same as Sigil, as is the scroll bar behaviour.

However, the Preview window never seems to retain keyboard focus. even if one clicks in it, i.e. the Codeview window always retains keyboard focus. So, the up/down Arrow or Page up/down keys always operate on the Codeview window, and in this instance the Preview window is kept in synch with the Codeview window.

Not being able scroll the Preview window via the keyboard is a negative for me, and it's not compensated by the fact that the Preview window does sync with Codeview if the up/down keys are used. In fact I find it quite irritating; a page of code is often a lot more than a page of content. So, when I press Page down the Preview window may sit there like stunned mullet, or it may move by some apparently arbitrary amount.

BR

[DiapDealer]

Originally Posted by AlanHK

I didn't say they don't render the same, it's how they react.

Which makes it even odder that you quoted my post that was addressing rendering. If you weren't responding to the conversation about rendering, why did you quote my content which was dealing solely with how the two render?