Bug 256561

- how do you define a paragraph? everything in one line?
- do you have dynamic word wrap enabled?
- is it the same if you scroll with the scroll bar?

By "paragraph" I mean "line" which looks like a paragraph because I have dynamic wrap enabled. It's the same if I scroll with the bar but not with the arrows located at the top and bottom of the bar area which scroll as expected.

The problem persists in KDE 4.6 RC1. I've noticed that scrolling works as expected by clicking on the scrollbar arrows which causes the document to scroll one "screen line" at a time. This is not true when scrolling by the by the scrollbar or the trackpad.

Ok, this is by design: Kate scrolls based on the amount of real lines in the document and not the amount of lines needed if all are dynamically wrapped.

As background: In order to scroll correctly for dynamically wrapped lines, Kate would need to layout ALL lines in the document to know the scrollbar parameters.
Layouting takes a lot of time, since the length of all lines needs to be calculated through Qt. This may be very slow, especially if not using a fixed font or other bidi-languages.

This issue has come up several times now. But we decided to not change the behavior, given the arguments above.

Too bad, since this is not the behavior of scrolling in any non-kpart application (e.g. dynamically wrapped text boxes in firefox, chrome, other text editors, etc.) This also deviates from the behavior of every text editor I've encountered on other popular platforms such as OS X (e.g. TeXShop) and Windows 7 (e.g. TeXnicCenter).

(In reply to comment #4)
> Ok, this is by design: Kate scrolls based on the amount of real lines in the
> document and not the amount of lines needed if all are dynamically wrapped.
> 
> As background: In order to scroll correctly for dynamically wrapped lines, Kate
> would need to layout ALL lines in the document to know the scrollbar
> parameters.
> Layouting takes a lot of time, since the length of all lines needs to be
> calculated through Qt. This may be very slow, especially if not using a fixed
> font or other bidi-languages.
> 
> This issue has come up several times now. But we decided to not change the
> behavior, given the arguments above.

Hi,

Your argument is strange since Control + DownKey scrolls one "line" down when dynamical word warp is on, which is the desired behavior. It seems all that needs to be done is to map the mouse scrolling to the same mechanism that scrolls with Control + Up/Down keys.

Please, reopen this bug. I often use large a display font, which requires dynamical word wrap. Thus, whenever I scroll down with the mouse I can find myself in the next paragraph, which is far far far beyond where I want to be... While if I just walk down with the arrow keys (with or without holding Control) everything is fine.

If indeed the arrow-key walking is too slow, at least add it as an option.

This is really annoying!!

Writing code in Kate is OK because the lines fit neatly in the screen. BUT working with text where there is a linebreak only after a paragraph is unbearable now.

Specifically, Kile is absolutely unusable with LaTeX...

Why does the mouse wheel scroll differently than clicking the arrow buttons on the scrollbar, or Ctrl+Up/Down?
The latter two function normally and this is the desired behavior for the mouse wheel.

Please change the status of this bug!

This is some crazy behavior, isn't it? Would love to see it reopened and fixed.

Maybe we can redirect the scroll whell to a scroll up event in order to have a better behavior here? Needs to be tested.

Git commit e34370bcea5cc78a665aa48b0beaf2505b4aaedc by Dominik Haumann.
Committed on 09/11/2011 at 21:28.
Pushed by dhaumann into branch 'master'.

scroll per view line with scroll wheel (please test)

CCMAIL: kwrite-devel@kde.org
BUG: 256561

M  +0    -8    part/view/kateviewhelpers.cpp
M  +0    -1    part/view/kateviewhelpers.h
M  +4    -2    part/view/kateviewinternal.cpp

http://commits.kde.org/kate/e34370bcea5cc78a665aa48b0beaf2505b4aaedc

Your last commit caused https://bugs.kde.org/show_bug.cgi?id=256561. Is is *not* a good idea to hard code the scroll speed ;-)

don't hard code amount of scroll lines

------------------------ part/view/kateviewinternal.cpp ------------------------
     } else {
-      scrollViewLines(e->delta() > 0 ? -3 : 3);
+      const int scrollLines = QApplication::wheelScrollLines();
+      scrollViewLines(e->delta() > 0 ? -scrollLines : scrollLines);
       e->accept();

Can this be reopened? Kate version 15.08.0 still scrolls per "real lines" rather than screen/view lines even when lines are dynamically wrapped. On the other hand, a KDE4 kpart app like Kile Version 2.1.3 does NOT.

I should also mention that the Qt5 build of TeXstudio scrolls as one expects, per view line, and performance seems not to suffer at all.

Right, once fixed for mouse wheel (see my commits linked in this report), this issue was silently reintroduced when removing all the special scrolling code, see commit
http://commits.kde.org/ktexteditor/a9f1d69e21c431b120c39969b2e1dba47d595638

Can we get your fixes back in, then?

We just tried at the kate sprint to revert my commit, that makes then scrolling on some touchpads like on a mac book just unusable fast. We can only revert back to the old behavior if we are able to replicate the behavior of the abstractslider.

I'm not a developer so I don't get the problem. But here is a naive thought: why not just replicate/copy/implement how scrolling works in qt5 apps like notepadqq or texstudio?

Any status on this?

Several comments:

   * I would like to echo the request that this be fixed, and that scrolling (in all circumstances) be one display line at a time.

   * The problem that I have (and I'm fairly sure is [related to | the same as] this problem is that when I'm typing in a multi-line dynamically wrapped paragraph near the bottom of a page, there are points in time when the insertion point and text jump and are no longer visible.  Yes, I can solve the problem by scrolling so the paragraph is higher on the page (if it is not the last paragraph of a document), but it is extremely annoying.

   * I agree with others that the behavior while scrolling either using <ctrl>down (or up) arrow or clicking on the up or down arrow on the scrollbar works (almost) as desired, so I have trouble understanding why this seems to be so difficult.  The "almost" is to mention one anomaly that I've noticed--see below.

   * If implementing a fix as alluded to above (making the scroll during editing the same as the <ctrl>arrow and scrollbar scroll) causes the mouse scroll speed to become so fast that it is unusable, couldn't a simple (and easily user adjustable) time delay be added to the mouse scroll function?

   * The one anomaly: In my documents, with dynamic word wrapped turned on, and with large paragraphs in the document, in a construct like the following, as I tried scrolling up or down, at times the scroll jumped by 3 lines at a time.  I don't know why, and haven't tried to dig into it.  Here's an example:

<quote>
++---

---++ set up a backup directory, git repository, and procedures

++---


morF
</quote>

I presume this would be repeatable for others.

   * I guess voting is no longer allowed for kate bugs?

Git commit 5a1d633587bf961f40d5b1da02ca5ebe55a25f3b by Christoph Cullmann.
Committed on 05/09/2016 at 10:21.
Pushed by cullmann into branch 'master'.

Revert "let QScrollBar handle the WheelEvents"

This reverts commit a9f1d69e21c431b120c39969b2e1dba47d595638.

seems to fix the bug I introduced by my change and we still have a working scrolling on e.g. mac it seems (tested locally)

cmath.h added to fix compile on arch

M  +2    -0    src/document/katedocument.cpp
M  +114  -27   src/view/kateviewinternal.cpp
M  +10   -0    src/view/kateviewinternal.h

http://commits.kde.org/ktexteditor/5a1d633587bf961f40d5b1da02ca5ebe55a25f3b

Git commit 4975173fb6d4142e2b774ae652fb9233bf4a8e50 by Christoph Cullmann.
Committed on 05/09/2016 at 12:32.
Pushed by cullmann into branch 'master'.

Revert "Revert "let QScrollBar handle the WheelEvents""

This reverts commit 5a1d633587bf961f40d5b1da02ca5ebe55a25f3b.

=> leads to asserts :/

Unrelated, but since someone is looking at scrolling behaviour: it would be very nice if Kate and Kate-based applications would stop zooming when one hits the Ctrl key to activate a shortcut when inertial scrolling events are still coming in. I think Qt already takes care of this on OS X with information that isn't available on X11.

Thomas Lübking and I designed a PoC class inheriting QTextBrowser and adding a relatively simple wheelEvent() override: http://github.com/RJVB/qtwheeltest .

Issue still present on Kate version 15.12.3 on KDE Frameworks 5.21.0 / Qt 5.5.1, but that is probably prior to Christoph's commit as above. +1 from me for fixing this.

Years later and I still wish this were fixed...

[Here is comment about ad-hoc fixing this bug for particular system, you can safely skip it]

I just made very simple patch based on https://bugs.kde.org/show_bug.cgi?id=256561#c21 . Here is my patch: https://zerobin.net/?0847ca5b9dec86f7#VxKX5KW7TUFqSD/yRddFQ8xitE3N2mP3yT37IrvA2bM= . It is obviously wrong (it doesn't handle "Shift" and pixel-based scrolling) and bad (hard-coded numeric constants).

The patch prepared by editing current "master", i. e. 9ef9669733138b46019882fc535d9fa5097a1d29, but I didn't test whether "master" with my patch really builds. I tested the patch by applying it to debian source package ktexteditor 5.28.0-2. And patch fixes the bug. Tested on debian stretch amd64.

Of course, don't pick the patch to upstream, it is just for people who want to patch their local kate

A fix for 2018? Still my favorite worst editor the year. Great to use until you have to scroll....

*** Bug 378275 has been marked as a duplicate of this bug. ***

(In reply to RJVB from comment #23)
> Unrelated, but since someone is looking at scrolling behaviour: it would be
> very nice if Kate and Kate-based applications would stop zooming when one
> hits the Ctrl key to activate a shortcut when inertial scrolling events are
> still coming in. I think Qt already takes care of this on OS X with
> information that isn't available on X11.

You would later fix that in Bug 377562! :-)

Letting QScrollBar handle the wheel events is probably the right approach. If that makes touchpad scrolling hypersensitive, that often needs to be fixed separately. Here's how we fixed that in Gwenview, for example: Bug 378584 Bug 307637 Bug 388353.

Possible fix should be tried similar to what is done here: https://phabricator.kde.org/D7744

*** Bug 393258 has been marked as a duplicate of this bug. ***

New proposed patch: https://phabricator.kde.org/D14758

Git commit 2815fea7854fae5ef45d8bb6d4ec61960576e5df by Sven Brauch.
Committed on 13/08/2018 at 08:44.
Pushed by brauch into branch 'master'.

Fix: Scroll view lines instead of real lines for wheel and touchpad scrolling

In documents with very long lines (think LaTeX files in case people don't
put linebreaks except for paragraphs) with dynwrap on, scrolling used
to be very difficult, since using the mouse wheel would always scroll one
real line at a time, which could be something like 10 view lines.

This patch instead scrolls by view lines if the mouse wheel is used.

Differential Revision: https://phabricator.kde.org/D14758

M  +17   -4    src/view/kateviewinternal.cpp
M  +1    -0    src/view/kateviewinternal.h

https://commits.kde.org/ktexteditor/2815fea7854fae5ef45d8bb6d4ec61960576e5df

The scrollbars preview behavior is related to this fix/bug: see Bug 392926