Bug 256561 - Katepart scrolls per paragraph rather than respecting the input device's scroll preference (i.e. n lines for a mouse wheel, pixel-by-pixel for touchpad)
Summary: Katepart scrolls per paragraph rather than respecting the input device's scro...
Status: RESOLVED FIXED
Alias: None
Product: frameworks-ktexteditor
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.44.0
Platform: Ubuntu Linux
: HI normal
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords: usability
: 393258 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-11-10 23:01 UTC by niburu1
Modified: 2018-08-16 10:02 UTC (History)
18 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description niburu1 2010-11-10 23:01:11 UTC
Version:           unspecified (using KDE 4.5.3) 
OS:                Linux

When I scroll using my touchpad, both Kate and Kile (so I imagine any embedded katepart application) scrolls by paragraph rather than my system setting, which is 3 lines. It didn't always do this and I'm not sure what caused it.

Reproducible: Always

Steps to Reproduce:
1. Open a document with numerous paragraphs that requires scrolling to move from beginning to end.
2. Scroll up or down using the touchpad.

Actual Results:  
Document scrolls by/per paragraph

Expected Results:  
Document scroll by x lines, where x is set globally under Mouse Settings -> Advanced -> Mouse wheel scrolls by.

Kate version 3.5.3.
Comment 1 Dominik Haumann 2010-11-10 23:17:37 UTC
- 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?
Comment 2 niburu1 2010-11-11 00:05:49 UTC
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.
Comment 3 niburu1 2011-01-02 14:49:19 UTC
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.
Comment 4 Dominik Haumann 2011-06-25 19:16:57 UTC
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.
Comment 5 niburu1 2011-06-25 19:49:13 UTC
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).
Comment 6 leonhardeuler1707 2011-09-16 21:56:16 UTC
(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.
Comment 7 sahmes 2011-11-01 10:25:24 UTC
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!
Comment 8 niburu1 2011-11-02 16:43:30 UTC
This is some crazy behavior, isn't it? Would love to see it reopened and fixed.
Comment 9 Dominik Haumann 2011-11-03 08:23:21 UTC
Maybe we can redirect the scroll whell to a scroll up event in order to have a better behavior here? Needs to be tested.
Comment 10 Dominik Haumann 2011-11-09 20:29:42 UTC
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
Comment 11 Gregor Tätzner 2012-05-25 10:58:30 UTC
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 ;-)
Comment 12 Dominik Haumann 2012-05-25 13:06:10 UTC
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();
Comment 13 Michael D 2015-08-30 19:56:11 UTC
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.
Comment 14 Michael D 2015-08-31 07:04:22 UTC
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.
Comment 15 Dominik Haumann 2015-09-01 10:43:50 UTC
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
Comment 16 Michael D 2015-09-28 08:47:40 UTC
Can we get your fixes back in, then?
Comment 17 Christoph Cullmann 2015-10-07 21:16:50 UTC
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.
Comment 18 Michael D 2015-10-12 08:44:36 UTC
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?
Comment 19 Michael D 2016-01-08 11:11:48 UTC
Any status on this?
Comment 20 Randy Kramer 2016-08-24 12:32:48 UTC
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?
Comment 21 Christoph Cullmann 2016-09-05 10:22:05 UTC
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
Comment 22 Christoph Cullmann 2016-09-05 12:34:09 UTC
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 :/
Comment 23 RJVB 2016-09-23 08:25:05 UTC
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 .
Comment 24 Haro de Grauw 2016-10-02 22:57:41 UTC
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.
Comment 25 Michael D 2017-06-08 21:13:40 UTC
Years later and I still wish this were fixed...
Comment 26 Askar Safin 2017-08-13 23:39:47 UTC
[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
Comment 27 Michael D 2017-12-24 03:49:17 UTC
A fix for 2018? Still my favorite worst editor the year. Great to use until you have to scroll....
Comment 28 Nate Graham 2018-03-22 15:49:12 UTC
*** Bug 378275 has been marked as a duplicate of this bug. ***
Comment 29 Nate Graham 2018-03-22 16:01:13 UTC
(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! :-)
Comment 30 Nate Graham 2018-03-22 16:01:46 UTC
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.
Comment 31 Dominik Haumann 2018-04-10 17:58:24 UTC
Possible fix should be tried similar to what is done here: https://phabricator.kde.org/D7744
Comment 32 Nate Graham 2018-04-18 17:14:24 UTC
*** Bug 393258 has been marked as a duplicate of this bug. ***
Comment 33 Dominik Haumann 2018-08-12 14:17:46 UTC
New proposed patch: https://phabricator.kde.org/D14758
Comment 34 Sven Brauch 2018-08-13 08:47:16 UTC
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
Comment 35 Till Schäfer 2018-08-16 10:02:05 UTC
The scrollbars preview behavior is related to this fix/bug: see Bug 392926