Hi, System: Krita nightly appimage krita-3.0.1-Alpha-4c91a18-x86_64.appimage on Kubuntu LTS 18.04.1, Azerty keyboard, French alternative layout, US local, US language. Issue: ====== If I try to type a number with numpad when I rename a layer; the numpad act like if the 'num lock' wasn't activated. To reproduce: ============= 1. Add a new paint layer. 2. Rename this layer 2. Name it "eyes_2" and type the '2' with numpad on keyboard. Result: ======= Instead of having a layer named 'eyes_2'; the layer stack switched to the layer bellow the renamed layer, (the numpad triggered and arrow ↓ action), the layer stop being edited, the name is "eyes_". Further infos: ============== It makes renaming layers difficult on Azerty French keyboard that use numlock+numpad to type numbers (the number are not easy to access as on a Qwerty keyboard. Numpad is often prefered.) I hope this one will be reproducible without a Azerty keyboard and affect also the Qwerty numpad :)
Note: typo on the version; krita-4.2.0-alpha-2e8bd70-x86_64.appimage (← copy paste issue in the report, I can't edit)
Something like this has been reported before: https://bugs.kde.org/show_bug.cgi?id=405717 -- but I couldn't reproduce it back then. That report talked about all input fields in Krita.
Thank you @boud. I confirm I'm affected by that in, I presume, all Krita field now: (hard to test it at first glance, I rarely type on other field, I mostly drag-and-drop when they are sliders) I tested and the bug happens in: - Top bar (Size/Opacity/Flow) - Tool option (eg. Stabilizer) - Brush editor (eg. Diameter) - Filters (eg. Pixelize) - Settings (eg. General>Misc>Number of Undo)
Does it work in, for instance the image name field in the new image dialog?
In Create a New document → Custom Document → Content (tab) → Name: No, it doesn't, I can reproduce the bug here too.
There's one bit of code that's a bit suspicious. I can comment that out and make a new nightly appimage; could you test that when done?
Git commit 89de24c01b57756a8a59d1e6136b97c78dd438a4 by Boudewijn Rempt. Committed on 10/05/2019 at 07:45. Pushed by rempt into branch 'master'. Temporarily comment out the widget tweaker so we can do a test build M +1 -1 krita/main.cc https://invent.kde.org/kde/krita/commit/89de24c01b57756a8a59d1e6136b97c78dd438a4
That'll be https://binary-factory.kde.org/job/Krita_Nightly_Appimage_Build/476/
Sure! I'll test it as soon as available. Thank you for the link to the appimage; that's super.
The build is done.
Sorry for late reply; my ISP today break packages and I had many download errors. I can reproduce in the latest build (krita-4.2.0-alpha-89de24c-x86_64.appimage). While painting this morning I also saw numpad4 and numpad6 to rotate canvas were not working anymore. Same for numpad5 to reset canvas rotation. Same for numpad0 to reset zoom. They all act as if my numlock wasn't activated, Krita-wide.
Okay, so that's nothing to do with this event handler.
Git commit e3421f0b37fb5db5b7e8665944c3cf4d9cec2c31 by Boudewijn Rempt. Committed on 10/05/2019 at 12:26. Pushed by rempt into branch 'master'. Restore the event handler This had nothing to do with M +1 -1 krita/main.cc https://invent.kde.org/kde/krita/commit/e3421f0b37fb5db5b7e8665944c3cf4d9cec2c31
Okay, I remembered I had dmitry's sprint keyboard upstairs, which has a numpad. I set Plasma to french, switched to a french keyboard layout and set the locale to fr -- and still the numpad worked.
I also tried with everything set to French with the 4.1.7 appimage, and no problems either.
Thank you for doing this deep test and sorry you can't reproduce. It might be something special with my configuration file maybe or keyboard layout. I'll run the test as root/another guest/in another D.E. asap. On Krita 4.1.x no issue, I confirm.
Hi, I tried: * Vanilla preferences → reproduced * New user (Vanilla Plasma) with various US-Qwerty/FR-Azerty layout + various region + various system lang with login/logout between each changes → reproduced everytime. * New user with another D.E.(Openbox) → reproduced. Could it be because the appimage can't read the "numlock" status from my computer? It sounds like it is always OFF here for Krita, whatever layout I use. Maybe my system is too old to transmit this infos? (Kubuntu 18.04.1; I probably have an old Plasma/Qt on this computer). Because Krita could understand when I switched Qwerty or Azerty layout for the letters, but numlock ON or OFF result always into the same here.
(after reading previous comments; precision: this affect only Krita 4.2-alpha appimage and nightly appimage up to that. I don't have this issue with none of the 4.1.x appimage I used so far).
Maybe also try https://binary-factory.kde.org/job/Krita_Stable_Appimage_Build/ -- that is 4.1.8 with the same version of Qt as the the alpha appimage. If that also shows the brokenness, it's probably Qt's new xcb implementation. You don't have a setup where you can build master anymore, right?
Touché! I can indeed reproduce with krita-4.1.8-47f3cd3-x86_64.appimage too. When I do my own build of git~master; I can't reproduce anymore.
Which version of Qt do you have for your own build (qmake -v)?
Hi Boud, I couldn't find the version of Qt installed; here is what I tried: https://www.peppercarrot.com/extras/temp/2019-05-11_screenshot_162141_net.jpg
Um... What distribution are you on these days?
Okay, this is a bug in Qt for reals: https://bugs.kde.org/show_bug.cgi?id=407381
Please test build 481 when it's done (https://binary-factory.kde.org/job/Krita_Nightly_Appimage_Build/). That has a Qt rebuilt on an image with that dev package installed.
@Boud: I confirm the bug is fixed since krita-4.2.0-alpha-ca5aeb7-x86_64.appimage, a big big thank you for your guidance during all the investigation of this bug!
I swear Qt is driving me crazy...
The right link: https://bugreports.qt.io/browse/QTBUG-75523