For the past weeks I’ve been pulling my hair over a bug on Android, which resulted in Krita’s UI freezing, locking or even crashing. This was all due to the way input handling and window management was being done within Qt.
Due to the nature of the bug, I had to spend quite some time testing to see if my solution didn’t break anything or didn’t slow anything down. And because I was changing the way input is handled I thought it would be a good idea to make some other things simpler too, which resulted in rewriting a few things (even though I’ve kept them almost as original but are now in C++ not in Java).
What I’m getting at is, this change resulted in an entirely different way of handling the input events (exception is keyboard based events). On paper, things should work exactly like they did before [1] and if anything doesn’t it is likely a bug.
Testing
Pretty much everything related to input requires testing. Some things that come to my mind:
Basic tests, if things like tablet tilt, multi-touch handling, mouse clicks work like they did before.
Test if keyboard modifiers work with tablet/mouse events like they did before.
Check if long-press-to-right-click works like it used to.
If you have touch painting enabled, those “dots” on canvas when performing gestures shouldn’t appear now (or they shouldn’t be as sensitive as they once were).
Check if swifting through context menu, windows, changing focus works, with multiple input devices.
If you have external tablet, test if things work like it did with previous versions. I’d greatly appreciate if you have a display tablet available to test using it with Krita (and all its functionality (pressure, tilt etc) works, i.e it is same as the previous version of Krita).
Compare in split view with Play Store version of Krita if you see any significant difference with strokes etc.
I’m testing 5.1.1 git efc5b67 (Krita debug) against 5.1.1 from the Playstore on an ONN tablet running Android 11 Go. My tablet has no pressure sensitivity so I don’t know how valuable this info will be… In both versions I turned off HiDPI and turned on touch painting.
I was very interested to try out the gestures.
One finger tap gives me problems in both versions - (actually 1 finger tap is a long 1 finger press on my tablet - I don’t know if that matters). At first it brings up the Popup Widget, but after a few minutes of painting the 1 finger tap gesture does not work at all until I touch another part of Krita that is off the canvas. Then it works again for a few minutes. I was unable to get 1 finger tap to work in previous 5.x versions as well so it was my habit to change the Popup Widget to 3 finger tap (after deleting redo as the default for 3 finger tap).
Playstore version: I changed the Popup Widget to 3 finger tap and it works beautifully. All the other gestures work well. I was unable to get it to break.
Debug version: After about 20-30 minutes the debug version gave up the ghost and wouldn’t let me paint at all with a brush, line or shape (vector pen and vector shapes continued to work). The brush cursor was on the screen but would not paint. The cursor would not follow my finger. I uninstalled the app and all its config files and reinstalled it fresh.
Krita Debug - 2nd install: One finger tap consistently behaved as described - the popup widget would be called up successfully a few times but then would stop working until I tapped some other off-canvas area. I was unable to freak it out this time. It continued to work well even if I changed layers repeatedly and painted really fast and used the gestures and different tools often. I changed the gestures around and still couldn’t get it to break.
Touch Docker
There are 2 icons that don’t work: Open Image and Save Image (these are the icons on either side of the Save icon). Pressing either of these makes the entire screen go white. Using the tablet’s back button restores the screen and there are no problems created.
You’re doing great work with the Android app. Let me know if I can test anything else for you.
Ah, yes, the way gestures and longpress work are kind of different and they’re not very related (longpress is detected by the OS, but gestures are detected by us). I’ve noted the bug, thanks!
Just to confirm, the app, menus, dockers etc didn’t lock up? Just that some tools stopped working the first time you tried the debug version?
On my tablet for a couple of milliseconds something is rendered and then it is hidden behind a white background. Could be a problem with QML. Touch docker is a component which is waiting for someone to clean it up (but that’s probably after we port to newer version of Qt)
yes, the nightly has been broken because it had a bad fix in it. But today’s nightly build (which will be built in a few hours from now) should work properly like the playstore/debug build.
While I’m thinking about it. What controls the naming of the Jenkins artifacts? It’s been stuck on 5.1.0 unsigned for a while. They’ve been signed and are on 5.2.0 prealpha. Actually confused me when it started getting signed as I was still used to signing it myself.
Able to reproduce this on Play store stable, debug, and nightly
Trying to select a tool with the stylus has a high chance of just scrolling the list without actually selecting the item. Takes three or four tries for it to actually take effect.
I attempted to reproduce on samsung s22 ultra, on nightly version and i do not have this issue. I set up my tool box to be horizontal and near toobar. Works fine
If it happens with 5.1.2, it being a regression is out of the way. Have you tried moving the toolbox to a different location and checking if the same behavior is exhibited? I have seen some Samsung Styluses act weird around the screen edges.
Can anyone test this. I use to be able to scroll with toolbox just by swiping it. It no longer works. Did something change recently? Because if so i need to revert back to 924 or earlier, too tedious to tap the scroll buttons on toolbox Because the tool is either far bottom or top.
Okay, so the issue is that, click to scroll messes with the selection of frames in animation docker. If i choose touch scroll the selection of frames is great but then the toolbox cannot scroll unless i use touch. If i choose middle button well thats not optimal either. Why must click to scroll (inverse kinematic) control the animation docker too and toolbox different at the same time!? They must both have their own settings!
