Description: Using KDE5 VCL, it's very difficult to scroll up using two-finger mouse pad scroll since several releases. Scrolling downwards works, even though much faster than in other applications, while scrolling upwards shows very erratic scroll behaviour and is barely usable only, if at all. This sounds like a similar problem as the following issue (or possibly a regression): https://bugs.documentfoundation.org/show_bug.cgi?id=97288 The first release where this happened was *not* 6.2.5.2, but earlier, but I don't really know which release. In any case it does happen with 6.2.5.2. It affects at least Writer and Calc, I did not test Draw and Impress so far. Steps to Reproduce: 1. Start LibreOffice under KDE5 (or with KDE 5 VCL) 2. Open a Writer document with more than one page or any Calc sheet 3. Scroll down a bit using touchpad, mouse or keyboard 4. Try to scroll upwards again using two-finger scroll on the mouse pad. Actual Results: Erratic, "jumpy" scrolling behaviour at step 4. Depending on the scrolling / finger speed on the mouse pad, LibreOffice will actually scroll even further down on in the document instead of up. Expected Results: Smooth upwards scrolling as in every other application, and comparable to downwards scrolling behaviour in every application including LibreOffice. Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: Version: 6.2.5.2 Build-ID: 1:6.2.5-0ubuntu0.18.04.1~lo1 CPU-Threads: 8; BS: Linux 4.18; UI-Render: GL; VCL: kde5; Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE Calc: threaded
Hmm, I get confused with scrolling 'direction' (stupid macOS) anyhow is this a dupe of bug 125201 and fixed now with https://gerrit.libreoffice.org/#/c/73614/
(In reply to V Stuart Foote from comment #1) >... and fixed now with https://gerrit.libreoffice.org/#/c/73614/ oops, of course not that is QT5 vcl--is similar handling needed for KDE5 vcl?
(In reply to V Stuart Foote from comment #2) > (In reply to V Stuart Foote from comment #1) > >... and fixed now with https://gerrit.libreoffice.org/#/c/73614/ > > oops, of course not that is QT5 vcl--is similar handling needed for KDE5 vcl? $ LANG=C wc -l vcl/unx/kf5/* 210 vcl/unx/kf5/KF5FilePicker.cxx 65 vcl/unx/kf5/KF5FilePicker.hxx 252 vcl/unx/kf5/KF5SalFrame.cxx 49 vcl/unx/kf5/KF5SalFrame.hxx 123 vcl/unx/kf5/KF5SalInstance.cxx 48 vcl/unx/kf5/KF5SalInstance.hxx 747 total For fun I also ran: $ cloc vcl/unx/kf5/ 6 text files. 6 unique files. 0 files ignored. github.com/AlDanial/cloc v 1.81 T=0.01 s (408.3 files/s, 50833.9 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- C++ 3 101 126 358 C/C++ Header 3 34 62 66 ------------------------------------------------------------------------------- SUM: 6 135 188 424 ------------------------------------------------------------------------------- In comparison to: $ wc -l vcl/qt5/* vcl/inc/qt5/* ... 13137 total $ $ cloc vcl/qt5/ vcl/inc/qt5/ 60 text files. 60 unique files. 0 files ignored. github.com/AlDanial/cloc v 1.81 T=0.09 s (682.3 files/s, 149390.8 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- C++ 31 1409 829 8427 C/C++ Header 29 458 582 1432 ------------------------------------------------------------------------------- SUM: 60 1867 1411 9859 ------------------------------------------------------------------------------- So you can basically assume to almost never find a "real" kde5 / kf5 bug, but a bug in the underlying qt5 plugin. Most of the code in kf5 is just boilerplate. /me also tried sloccount, but that doesn't seem to account header files... So I very much assume you're right and this is a dup of bug 125201, so I'm closing is as that. (In reply to Gunter Ohrner from comment #0) > Expected Results: > Smooth upwards scrolling as in every other application, and comparable to > downwards scrolling behaviour in every application including LibreOffice. Smooth scrolling isn't yet implemented, nevertheless current scrolling implementation in 6.3 should fix the erratic behavior you reported in this bug. *** This bug has been marked as a duplicate of bug 125201 ***