S-Pen: Multiple small improvements
So I recently got a S9+, and it's time for some S-Pen fixes! I noticed that everything pretty much works out of the box, which is nice. I added this info into the UI that this device is supported.
Before | After |
---|---|
However when playing around with it, I had a hard time wrapping around in my head about how S-Pen actions in Krita works - this is hoping to mitigate some of that. In short:
- We need to define actions ahead of time for Samsung to expose this in their UI. For multiple reasons, that's an insane ask and will never happen. What the original implementer did was smart, and simply plug in the existing buttons/gestures and let those be configured inside of Krita.
- This wasn't clear to me in the settings UI, so I added a new sentence to make sure users don't try to configure the S-Pen actions on a system level. They must correspond to the actions we set by default (so our settings UI still makes sense, you don't try to configure "Swipe Down" when you're actually doing "Swipe Up" etc.) As far as I know, there's no way to disable this configuration
😬 - To this end, there is one thing we could do. We can force the "button" actions to only be assigned to the buttons, and the "gesture" actions only to the gestures. This is what the first commit does. I guess it's something...
- The previously named "Click" and "Double click" is not what Samsung uses in their UI, so that's been changed to "Press" and "Double Press". This only affects the UI strings, I didn't touch the underlying settings keys and whatnot.
- Some small wording changes.
The S Pen configuration on a system level for Krita, if you need reference:
Test Plan
- Test on a real Android device (no idea if you can even get a S-Pen-compatible emulator)
- I only have a S9+ on hand, but according to the S-Pen docs it should really work for all devices.
- Ensure the two buttons and gestures work.
Formalities Checklist
-
I confirmed this builds. -
I confirmed Krita ran and the relevant functions work. -
I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!) -
I made sure my commits build individually and have good descriptions as per KDE guidelines. -
I made sure my code conforms to the standards set in the HACKING file. -
I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy. -
Does the patch add a user-visible feature? If yes, is there a documentation MR ready for it at Krita Documentation Repository?
Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build. If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.