Prior to the 5.3/6.0 I could Rotate my canvas with the horizontal scroll wheel on the MX Master 3 mouse, now it does not work.
These can still be bound, and I can bind them in the Canvas Input Settings, however whatever they are bound to will not actually work on the canvas.
Currently on Arch Linux.
I tried this on X11 and Wayland, with both arch’s build and the flatpak.
Hello @oct2pus, and welcome to the forum!
If you want to try out if it works with other versions, then always use the AppImage, because it is the only official Krita for Linux, anything else, snap, Flatpak, repo, etc., are unofficial community projects. And far to often these implement additional issues.
Although with your issue I’m not sure if it is an already known bug or a first report, but I’m unable to find it.
Michelist
Maybe this one is related: 5.3.1 Bug: Shift+Space to Rotate Canvas fails with crash
Hi @Michelist, glad to be here.
This would be a seperate issue, but KDE currently verifies Krita on Flathub, making it look like a supported release. Might be worth someone bringing this up with the KDE’s flathub team if it is not considered official by the Krita team!
I tried the appimage versions, both still could not use any action bound to the scroll wheel in the canvas input settings. I had also tried the 6.0.0 nightly to see if this was still the case and it is.
@AhabGreybeard I don’t believe it to be related, the scroll wheel also does not invoke anything when I bind it to any other action (but it can still be bound in canvas input settings). I still tried the solution provided in that bug (remove the kritadefault.profile, and reload krita), to no success.
Edit: Partially rewritten, added to, or deleted.
Anyone can grab and (mis-)use it.
So, now that I’m fully awake and had time to inspect the Flathub pages again, this is what that button says and that does in no way say or mean it is approved by KDE, and anyone who is able to read and understand written texts sees it is not approved by KDE, but the flathub team has checked the assigned ID at KDE Gitlab. And “checked from flathub” is not “Approved by KDE”:
Therefore, I can not rule out that those responsible at Flathub put it there on their own behalf, similar to what they did for a very long time (in years) → create the impression their build was a build by the Krita devs, which just a week ago was stopped through their new maintainer. Here, too, it seems that they’re once again just playing with appearances → Looks like “KDE Approved.” Before it looked like made by Krita devs. But at least it’s true that Krita falls under the broader umbrella of KDE, even though Krita is highly independent. But before they put only the addresses of official Krita as contact address and this forum as the responsible support address on their pages, and pretended to act as if they had nothing to do with it while it is solely based upon their own initiative, by the way similar to snap who didn’t stop acting like they were official right now! Only that their version of Krita is highly outdated.
Currently, although I might be wrong, I guess they are only bold and that is a remaining sign of it, because I never heard they got that approval. Now, that I looked deeper, we know it does NOT MEAN "KDE Approved!"
That does not mean Krita is against these projects offering their own builds of Krita, the license absolutely allows it, Krita even allows them a link on Krita’s download page but there it is made clear that these are community projects, nothing more!
Ultimately, it’s just another piece of the puzzle in Flathub’s attempt to convince (or trick?) users that its supposedly secure package system is a safe haven. You can also say, they only want “to sell” their product better.
My personal opinion on this:
I seriously doubt I should trust anyone who acts like this. Because safety isn’t based upon deception, but technology. But so many users these days like to believe more in words like “It is more secure!”, without the technical knowledge behind, knowledge that you need to understand what is sold to you. Linux security isn’t based upon obscurity, but on open source code, codebase monitoring, and other things.
Michelist
Add/Edit: @oct2pus, I have updated my post.
Alright, it looks like this hasn’t been reported. I’ll try and find some time tomorrow to report this.
