Book Browser issue

[KevinH]

I just recreated it on MacOS once.

1. Open Sigil Users guide epub
2. slightly shrink Sigil Main UI height.
3. scroll down about 1/3 the way in BookBrowser
4. double click the last visible chapter
5. then try double clicking the chapter near the top that you can see without scrolling

6. repeat as needed alternating top and bottom and one chapter will eventually get dragged along by the centering scroll unless I double-click super fast.

I am going to try changing BookBrowser to use EnsureVisible in its scroll to and run the same tests again.

[KevinH]

So with this patch, since the scrolling is prevented (you can only double-click on something already visible in BookBrowser), no matter how slow or fast I double-click nothing is ever moved (ie. the scroll repositioning can no longer pull your chapter you are opening along with it).

Here is the diff of the one line change:

diff --git a/src/MainUI/BookBrowser.cpp b/src/MainUI/BookBrowser.cpp
index 24aab8b37..ffab68d94 100644
--- a/src/MainUI/BookBrowser.cpp
+++ b/src/MainUI/BookBrowser.cpp
@@ -265,7 +265,7 @@ void BookBrowser::UpdateSelection(Resource *resource)
 
     if ((item_rect.top() < MIN_SPACE) || ((tv_rect.bottom() - item_rect.bottom()) < MIN_SPACE)) {
         // Too close to the top or bottom
-        m_TreeView->scrollTo(index, QAbstractItemView::PositionAtCenter);
+        m_TreeView->scrollTo(index, QAbstractItemView::EnsureVisible);
     }
 }

If anyone else can recreate this with Sigil master, please try this patch.

Luckily it is a single line internal change so no new translations are needed.

Remember, you are not trying to drag and drop. You are only doubleclicking on chapters that would force the internal BookBrowser to reposition itself and that somehow causes the drag. Since the repositioning can be quite far, it exceeds most drag distance tweak settings. I had it move one chapter by 5 or six chapters!

[DiapDealer]

I've not been able to repeat it on Windows with the above steps yet. (Leaving SIGIL_DRAG_DISTANCE_TWEAK unset for now). I've even tried slowing down my double-click considerably and varying my speed when going from the bottom to the top of BookBrowser.

I can't make it happen without actually dragging the mouse a bit during the double-click. Nothing I've done makes it happen with the automatic BookBrowser reposition alone. I've even tried with an epub that has more chapters that the Sigil guide.

I'll try on Linux when I get home.

[Siggy15]

Thanks for looking into this, it happens a lot. Usually I don't notice until later because I'm not staring at the list. Luckily I have a naming convention that lets me put things back where they belong.

[KevinH]

The only help I can provide is to try and skip step 2 (maybe even grow it slightly), and for step 3 scroll down in the list of chapters so that there is plenty of chapters above the top of BookBrowser and plenty of chapters below the bottom of BookBrowser so the potential for centering scrolling is maximized.

Then try alternating by first double clicking a chapter near the bottom of BookBrowser, then near the top of BookBrowser so that lots of centering scrolling happens.

It took me 3 attempts before the chapter I was double clicking was dragged away by the scroll and the wrong line in BookBrowser ended up being selected.

I literally had to look just below the top one I was double-clicking to verify whether it moved or not. And look just above the bottom one to see moves.

Maybe to create a test epub, I should just number the chapters to make bad drags more apparent.

[DiapDealer]

I've got lots of center scrolling happening and I've got tons of chapters above and below BookBrowser. I've got about 20+ minutes of trying with no double-clicking being dragged away by the center scrolling yet.

Has the OP's OS been confirmed yet?

[DiapDealer]

Is there a possibility of graphics artifacts with this happening '"a lot" for the OP? Just wondering if disabling hardware graphics acceleration (in Sigil's preferences) would make a difference? I'm finding it hard to believe that this is a widespread problem for users. I would think we'd have already had tons of user complaints if this was happening all the time.

[KevinH]

Originally Posted by Siggy15

Thanks for looking into this, it happens a lot. Usually I don't notice until later because I'm not staring at the list. Luckily I have a naming convention that lets me put things back where they belong.

We are tying to recreate this on Windows to no avail. To recreate this on Mac OS is very very hard.

What platform/OS version are you using?

[DiapDealer]

I've gotten it to happen a few times on Linux using the appimage, but I have to try for long time before it happens. I had it happen maybe 3 times in 15 minutes worth of clicking.

I'll try the patch later tonight it see if it changes things.

[KevinH]

Whew ... I was beginning to worry I was the only one who could recreate this.

[DNSB]

I spend 30 minutes playing with this under Windows and Linux. After 15 minutes, without touching the SIGIL_DRAG_DISTANCE_TWEAK, I managed to get the file move under Linux twice but did not see it under Windows. I set the tweak to 8 and after 15 minutes, did not see it again on either.

[KevinH]

Interesting. On a Mac the default drag distance is quite large but I still had one chapter get moved by 5 places, which exceeds even that higher native drag distance.

With the patch, no auto scroll happens since the chapter you are double clicking on must already be visible in order to select it. So the patch works. When having long lists of chapters, with the patch, everything is faster as no scrolling is needed.

[DiapDealer]

Originally Posted by KevinH

Maybe to create a test epub, I should just number the chapters to make bad drags more apparent.

With an epub that has all changes saved, I just look at the title bar and wait for the modified indicator (*) to appear. Then I know the file got moved.

[DiapDealer]

Originally Posted by KevinH

With the patch, no auto scroll happens since the chapter you are double clicking on must already be visible in order to select it. So the patch works. When having long lists of chapters, with the patch, everything is faster as no scrolling is needed.

I'm trying to remember why we were scrolling to the center in the first place. Why was being "too close" to the top or bottom deemed undesirable? Was it for selecting files that were only partially visible?

[KevinH]

That is what EnsureVisible will fix, but never a big move. To tell you the truth, I do not remember why we use PositionAtCenter. It may have been something we inherited that was never changed. I will look in github to see when and why it was added.