fix(new study screen): finish current stroke before changing pen color

[Amitesh-exp]

new.study.screen.fix.issue.19236.mp4

Purpose / Description

When drawing, if the user tapped with another finger to change the brush color, the stroke would continue instead of ending. This caused unexpected merging of strokes with the wrong color.

Fixes

• Fixes [Whiteboard] While drawing, it’s possible to press the buttons. #19236

Approach

• Added handling for ACTION_POINTER_DOWN in onTouchEvent
• Now, whenever a second finger touches the screen while drawing, the current stroke is finalized (drawFinish()), isCurrentlyDrawing is reset, and the brush change is applied cleanly.
• This ensures multi-touch interactions stop the ongoing stroke before switching brush color.

How Has This Been Tested?

• Tested on Physical Device
• Drew with one finger, then tapped another finger to change color.
• Verified that the stroke ended before color switch.
• Confirmed new strokes started fresh with the new brush color.

Checklist

Please, go through these checks before submitting the PR.

• You have a descriptive commit message with a short title (first line, max 50 chars).
• You have commented your code, particularly in hard-to-understand areas
• You have performed a self-review of your own code
• UI changes: include screenshots of all affected screens (in particular showing any new or changed strings)
• UI Changes: You have tested your change using the Google Accessibility Scanner

[BrayanDSO]

The screen is already complex, and the fix makes it even more complex, and doesn't fix it well.

A simpler fix is just to track whether the user is drawing in WhiteboardView, then not allowing to change tools if the user is drawing.

[ZornHadNoChoice]

not allowing to change tools if the user is drawing.

Currently, you can also press other buttons (like the answer buttons) while drawing. Consider whether to disallow that too.

[BrayanDSO]

Currently, you can also press other buttons (like the answer buttons) while drawing. Consider whether to disallow that too.

For now, disable only the whiteboard buttons. Disabling the others will be more complex, and I prefer to stabilize the screen first.

[Amitesh-exp]

The commits got a bit messy
Let me know if this will work or do I need to create a new pr with a new branch with single commit

[BrayanDSO]

Please don't create a new PR. Rebase it

[sanjaysargam]

e: file:///D:/a/Anki-Android/Anki-Android/AnkiDroid/src/main/java/com/ichi2/anki/ui/windows/reviewer/whiteboard/WhiteboardFragment.kt:86:24 Unresolved reference 'isDrawing'.

Test fails

[sanjaysargam]

@Amitesh-exp rebase it

[Amitesh-exp]

Screenrecorder-2025-09-28-17-44-43-628.mp4

New Fix: Restricts the user from changing color while drawing

[thedroiddiv]

Adding an extra layer to block inputs seems much of a hack. A better approach would be disable inputs from the toolbar when user is drawing.

This could be something like if(isDrawing) disableButtons() else enableButtons()

[Amitesh-exp]

Wouldn't it be even better if the button are not even visible while drawing?
Instead of disabling or enabling them I can make them invisible or visible

[thedroiddiv]

Sure, feel free to go ahead. I do not see any conflicting behaviour.

if(isDrawing) showToolbar() else hideToolbar(). Which I believe already exists inside overflowMenuButton.setOnClickListener
@BrayanDSO Any comments?

A plus point from UX pov would be if you can implement slide in/out the toolbar from screen edge (requires more changes + animations)

[BrayanDSO]

Don't hide the toolbars while drawing. That's unusual and unexpected

[Amitesh-exp]

I have done two commits.
In the first, toolbar doesn't hide and in the second, it does.
Is first commit the correct fix?

[Amitesh-exp]

Screenrecorder-2025-10-09-14-17-35-151.mp4

This type of feature where toolbar disappears is available in many apps where drawing screen is present. Doesn't look unusual too.
@BrayanDSO @thedroiddiv

[thedroiddiv]

Hey, sorry for the long waiting, I was away the time. I think it's a totally subjective choice
My comment was mostly was around how the the disabling was being handled earlier seemed a bit of place. Which looks good to me now.

Will let @BrayanDSO to tak the call here.

This could be something like if(isDrawing) disableButtons() else enableButtons()

or

if(isDrawing) showToolbar() else hideToolbar()