Bug 470071 - Scroll locking due to day highlight
Summary: Scroll locking due to day highlight
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Digital Clock (show other bugs)
Version: 5.27.5
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2023-05-21 00:26 UTC by old486whizz
Modified: 2023-10-27 16:52 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 6.0


Attachments
Widget with error (35.91 KB, image/png)
2023-05-21 00:26 UTC, old486whizz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description old486whizz 2023-05-21 00:26:03 UTC
Created attachment 159159 [details]
Widget with error

SUMMARY
***
Moving cursor over the days of the pop-up widget and attempting to scroll using the touchpad causes the widget to lose functionality and the window to stutter/judder. Meaning the next few months cannot be scrolled through as it should.
Done when using the Wayland compositor in KWIN/plasma.
***

STEPS TO REPRODUCE
1. Click on clock to get pop-up
2. Move laptop mouse cursor over a day so it's highlight (don't click), and attempt to scroll.. The expected scrolling of days+months does not occur - it "bounces"/judders/stutters as if the highlighted day is "locked" to the mouse cursor (unless a big scroll is attempted in which case it jumps several months and locks there).
3. Attempting to click left/right (next month/previous month) doesn't change the display either - although "today" does.
4. In order to scroll correctly, the mouse can be placed in the ~5 pixels just to the left of the calendar layout but within the pop-up and a scroll WILL work as expected (doing this will then allow the left+right arrows to work as expected).
5. This can sometimes effect the "days/months/years" selector at the top of the window - although it's very hit/miss.. Sometimes it's broken - sometimes not (screenshot attached).

OBSERVED RESULT
The scrolling is getting "locked" on the current month by the cursor highlighting a day.
The monthly elastic-lock/magnetic-lock (such a bad idea anyway) is probably a contributor to this.
This also affects the left/right arrows and also the days/months/years selectors.

EXPECTED RESULT
The widget should be scrollable (although the bad elastic/magnetic-lock on the months would take effect).
The widget should also switch between days/months/years when desired.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Fedora 38
(available in About System)
KDE Plasma Version: (I selected this in the 'version' above): 5.27.5
KDE Frameworks Version: 5.106.0
Qt Version: 5.15.9

ADDITIONAL INFORMATION
Haven't tested with a mouse - as I don't have one. This is all being done with a laptop trackpad + 2 finger scrolling (although I would expect the 2-finger scrolling to still simulate a scrollwheel as expected, and the reaction to be the same as every other application).
Comment 1 old486whizz 2023-05-21 03:10:45 UTC
Just spent a couple of hours looking through the widget .qml files and attempting to make sense of them with my limited knowledge.

... If I am reading this right, this is coming from the "org.kde.plasma.workspace.calendar" widget.
The 2 qml files which seem to apply are:
MonthView.qml + DaysCalendar.qml

Both seem to indicate that a scroll would act similarly to 1 "mouse click" (eg, a scroll down would cause it to skip a whole month!!!).

I have a touchscreen, and can "drag" the month up and down smoothly (although the awful magnetic-lock kicks in).
And moving my mouse to that sweet spot at the left allows me to scroll the view smoothly too (again within un-reason).

So, I am kind of concluding that:
1) Mouse scrolling is conflicting with the qml code which wants it to jump from month to month.. Possibly the "120" delta in the qml is bad for Wayland and is tuned only for X11? Possibly the scrolling of the window and the attempt to move in hard units is conflicting in some other way? Could also be something to do with my trackpad sensitivity (again in relation to this delta).
2) This kind of matches with me using my touchscreen to drag the month (as it's a drag movement not a scroll), and also with my mouse in the sweet spot (scrolling the background or something like that - immitating the scrolling of the contents and not sending the scroll event through to a specific function call).
3) Not quite sure why the contents aren't always updated - like the "<" and ">" buttons (as well as the days/months/years tabs not working... I can't see any reason why the code would lock up and prevent those.

... Really not sure why this was ever put against a strict scroll event rather than letting a person scroll the contents as they want.

I may see if I can comment out the event code to allow just normal scrolling - but it's very late here so I will check back in tomorrow.
Comment 2 Nate Graham 2023-05-22 21:35:58 UTC
Can confirm. If your code spelunking ultimately yields something that fixes the issue, please do feel free to submit it upstream in the form of a merge request! See https://community.kde.org/Infrastructure/GitLab for details.
Comment 3 Fushan Wen 2023-10-27 16:52:03 UTC
Git commit 42bcd75bfb7324e2e3da828a58f6184970800687 by Fushan Wen.
Committed on 27/10/2023 at 18:27.
Pushed by fusionfuture into branch 'master'.

components/calendar: avoid creating (42+12+12)*3 MouseArea in MonthView

Before this each DayDelegate had one MouseArea, which is unnecessary
since DayDelegate itself is a PC3.AbstractButton. The wheel event is
handled in WheelHandler in SwipeView in MonthView.
FIXED-IN: 6.0

M  +2    -27   components/calendar/qml/DaysCalendar.qml
M  +21   -6    components/calendar/qml/MonthView.qml

https://invent.kde.org/plasma/plasma-workspace/-/commit/42bcd75bfb7324e2e3da828a58f6184970800687