-
Notifications
You must be signed in to change notification settings - Fork 276
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix #948: Cannot scroll down the window in calendar view #1097
Conversation
renderer/classes/MonthCalendar.js
Outdated
if (this.children.length > 5) | ||
{ | ||
this.scrollLeft -= (delta * 30); | ||
e.preventDefault(); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like how this improves the current solution, but I don't like the fact that it is being tied to the number of cells. If the user resizes down the app window such that they need horizontal scrolling even with 5 or less entries, they won't be able anymore.
I think based on my comment on the original issue:
switch to horizontal scrolling, but if it reaches the edges of horizontal scrolling (leftmost or rightmost scroll position) then start scrolling vertically.
This one is a better solution. I've tested and I think it works smoothly, let me know what you think
const currentScroll = this.scrollLeft;
this.scrollLeft -= (delta * 30);
if (currentScroll != this.scrollLeft)
{
e.preventDefault()
}
(scrollLeft
stops getting updated when it gets to the bounds, which are 0 and a given max value)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that makes total sense.
I've tested it with your solution and it seems to work quite nicely 👌
I've pushed the code changes and updated the PR, including the screen capture.
… horizontal left is reached rather than relying on a fixed number of cells to determine scroll direction.
\changelog-update |
Related issue
Closes #948
Context / Background
Horizontal scrolling features locks vertical scrolling in the calendar view, even when horizontal scrolling is not necessary/possible. This creates an unintuitive scroll lock.
What change is being introduced by this PR?
How did you approach this problem?
I looked into the mechanism that was blocking vertical scrolling to see how it was blocked, and what could be done to unblock it under conditions where it wasn't appropriate.
What changes did you make to achieve the goal?
I wrapped the logic that changes vertical scrolling to horizontal scrolling in a condition that
limited this to only cases where the element in question had enough data ( more than the default 5 child elements ).re-enables vertical scrolling over the row once scrolling has reached the end in the horizontal direction.What are the indirect and direct consequences of the change?
Direct consequences: You can now scroll vertically while hovering the cursor on any element that is not a row with excess data. These rows still maintain their horizontal scrolling functionality as before.
There are no apparent indirect consequences.
How will this be tested?
Open the app in month view.
Make sure you have at least one row that has enough data to necessitate sideways scrolling.
Place the cursor over empty rows and check that vertical scrolling works.
Place the cursor over a row with extra (off-screen) data and check that horizontal scrolling still works, allowing you to still access all data in that row.
Updated screen recording 👇
time-to-leave-no-scroll.mov