Created attachment 120997 [details] pic of the error box after Krita crash SUMMARY Hello, I encounter a issue with the zoom function that I use through the shortcut: CTRL + Space + pan my stylus on screen. I can use the zoom/dezoom but as soon as I come back to my brush and I put my stylus to paint again, Krita crash as soon as I put the stylus on the screen in brush mode (almost every time, 8 to 9 times on 10). This problem is not encountered when rotating the canvas. I'm on Windows 10, my tablet is a Cintiq pro 24 but I had the same problem with my old wacom intuos 3. I use the express remote with the corresponding shortcut but still the problem remains. The problem does not occur when I go through the zoom button in the toolbar. OpenGL is enabled, anti-aliasing as well as selection edges. the version I'm using is 4.2.0 STEPS TO REPRODUCE 1. open a canvas 2. use the shortcut CTRL+Space+Pan your stylus on the screen to zoom in or zoom out 3. choose a paint brush with B 4. if it's works, back to step 1 and do it few times to see krita crash. OBSERVED RESULT Krita crash 8 or 9 times on 10 EXPECTED RESULT That this great shortcut works because this kind of shortcut very effective for a fluid workflow in paint work SOFTWARE/OS VERSIONS Windows: 10 macOS: no Linux/KDE Plasma: no (available in About System) KDE Plasma Version: no KDE Frameworks Version: no Qt Version: no ADDITIONAL INFORMATION -The issue is still there even when I don't use OPen GL but Direct3D 11 via ANGLE. -The issue is still there when I use the mouse rather than the stylus for pan up or down with the shortcut. -Drivers of my 2 SLI graphic cards : NVIDIA Corporation, GeForce GTX 960/PCIe/SSE2, 4.6.0 NVIDIA 430.86
I don't get this at all with krita 4.2.0 on Windows 10 after trying many times in various ways. I have an Intuos Art and tried it with mouse as well. You're very specific about opening a canvas, then immediately doing the zoom and then pressing the 'B' key and then painting. I did all that and other variations. Is using a freshly opened canvas an essential step to inducing the crash? Does it happen with a canvas you've been working on for some time? Is pressing the 'B' key an essential step to inducing the crash? (You don't need to press the 'B' key to use the paintbrush since it's the default tool.) Did this happen with version 4.1.7?
Sorry - I did the wrong status selection there.
I also cannot reproduce it; the 'B' key press cannot be necessary, since it won't do anything, because the freehand tool is still active when using the zoom shortcut. Would it be possible for you to get the latest nightly build zips and follow https://docs.krita.org/en/reference_manual/dr_minw_debugger.html#dr-minw to get us a crash log? See https://binary-factory.kde.org/job/Krita_Nightly_Windows_Build/ -- just unzip the krita zip somewhere, then copy the contents of the dbg zip into the krita folder.
Hello Boudewijn and Ahab, Thx for your help guys but I'm in the same unconfortable position. I have no kritacrash.log actually. And sadly, I don't understand how to make it appear. The only thing readable that I have in %LocalAppData% is a text file only named "krita" I have extracted the bin and the lib as you told me to do but it changes nothing that I can see. For information the last version where I don't find this issue is the 4.0.3 And I find the same issue even on the 4.2.1, then I stepped back on the 4.2.0. I also test without tapping B after doing the "Ctrl+Space+Pan with stylus" shortcut and it crash in anyway. Is there a conflict problem with the Ctrl + Space shortcut? In order, I always type 'ctrl' before 'space' and then use the stylus to zoom in or out. Maybe by typing 'space' before 'ctrl' .. (In reply to Boudewijn Rempt from comment #3) > I also cannot reproduce it; the 'B' key press cannot be necessary, since it > won't do anything, because the freehand tool is still active when using the > zoom shortcut. > > Would it be possible for you to get the latest nightly build zips and follow > https://docs.krita.org/en/reference_manual/dr_minw_debugger.html#dr-minw to > get us a crash log? > > See https://binary-factory.kde.org/job/Krita_Nightly_Windows_Build/ -- just > unzip the krita zip somewhere, then copy the contents of the dbg zip into > the krita folder.
As I expected, if I start typing 'Space' before 'Ctrl', Krita don't crash and I can continue to work. If I start by typing 'ctrl' before 'space' it crash. The problem is that I can't insert the shortcut in my wacom Express key remote by starting with 'space' because it don't want to accept 'ctrl' after it. I don't understand what's going on.. I hope this clarification will help you. Do you need the 'krita' file available in %LocalAppData% (not 'kritacrash.log' file that is still not exist)?
I found this but I don't know which one of my programs can be the cause of this particular issue with Krita (if my problem is the same) : https://forums.tomshardware.com/threads/control-space-not-working-but-space-control-works-solved.2779604/
Do you have any other applications running at the same time as krita (such as Spotify, a browser, e-mail client, a local music player, etc)? If so, close them down and try again. Have you installed any kind of permanently running 'utility' software (such as an on-screen clock, local weather report display, screen colour temperature adjuster, etc)? If so, stop them and try again. When krita is not running, does pressing your Ctrl key have any effect that you can see? (Some utility applications are affected by the Ctrl key.)
Yes I stopped every running app like F.lux (as a screen colour temperature adjuster). No music, no navigator, no nvidia things etc.. The issue is still here. The weird thing is , sometimes (not everytime) the zoom shortcut following by a rush stroke can work 4 or 5 times but it finally crashes in anyway. I'm losing the only track I thought I'd found in the order I'm doing the shortcut :/ You guys, did you type the shortcut in the same way that I do? I mean by pressing 'ctrl' before 'space bar' and finally drag the stylus or the mouse up or down on the screen? I have no more clues.
Yes, ctrl, then space, then drag.
I don't understand what refuses to make the shortcuts in this order, and especially not in a systematic way. I feel helpless and sorry :(
The problem is that Qt cannot see space as a modifier key, so you need to first press the modifiers (ctrl, shift etc.) and then the other keys. But that's not the reason Krita crashes for you. The krita.log file could be useful, but I don't understand how there cannot be a kritacrash file if Krita crashes :-(
Created attachment 121047 [details] krita.log it's odd because if I hit 'Space' first an then 'ctrl' in this order, it works very well. It's just not my habit at all, so I'm exposed to many crash during my painting and it's pretty annoying, especiallly for pro works. I need to test it if I can this afternoon on MacOS at my studio. I just shared the only file that I think it can help us. But it's not named "kritacrash.log" but just "krita" and it's a text file, so I doubt it's the right one, :( I feel cursed.
At least I can see that your drivers are up to date, which is good...
Looking at the krita.log file, you're running the installed version of krita. I think you need to run the 'portable' .zip version with the debug package unzipped into it to get the crash log? For me, Ctrl+Space and Space+Ctrl work fine for mouse/stylus zooming with the magnifying glass icon showing. If I do Ctrl first, the colour picker icon comes up first. If I do Space first, the hand/pan icon comes up first, as I'd expect.
Hi, Bouss! Could you please generate us a crash log, as described in this manual: https://docs.krita.org/en/reference_manual/dr_minw_debugger.html#dr-minw It might also be helpful if you get a log from DebugView as well: 1) Download DebugView and run it https://docs.microsoft.com/en-us/sysinternals/downloads/debugview 2) Run Krita and make it crash by using Ctrl+Space shortcut 3) Save the generated log in DebugView, and attach it to this bug :) I'll mark the report as waiting-for-info. Please change it back to "Reported" after you generate the log.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Hi I'm sorry for the non response. Unfortunately, I do not have access to my home computer for over a month due to an overworked work and family schedule. I left your email knowingly in my mailbox to not forget it but I did not know there was a delay. I would launch the proposed procedure at the earliest, sorry for this time, I'm just exhausted. (In reply to Bug Janitor Service from comment #16) > Dear Bug Submitter, > > This bug has been in NEEDSINFO status with no change for at least > 15 days. Please provide the requested information as soon as > possible and set the bug status as REPORTED. Due to regular bug > tracker maintenance, if the bug is still in NEEDSINFO status with > no change in 30 days the bug will be closed as RESOLVED > WORKSFORME > due to lack of needed information. > > For more information about our bug triaging procedures please read the > wiki located here: > https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging > > If you have already provided the requested information, please > mark the bug as REPORTED so that the KDE team knows that the bug is > ready to be confirmed. > > Thank you for helping us make KDE software even better for everyone! (In reply to Bug Janitor Service from comment #16) > Dear Bug Submitter, > > This bug has been in NEEDSINFO status with no change for at least > 15 days. Please provide the requested information as soon as > possible and set the bug status as REPORTED. Due to regular bug > tracker maintenance, if the bug is still in NEEDSINFO status with > no change in 30 days the bug will be closed as RESOLVED > WORKSFORME > due to lack of needed information. > > For more information about our bug triaging procedures please read the > wiki located here: > https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging > > If you have already provided the requested information, please > mark the bug as REPORTED so that the KDE team knows that the bug is > ready to be confirmed. > > Thank you for helping us make KDE software even better for everyone!
Hi Dmitry, my apologies for the long delay without responding as I said sooner to the janitor. I'll do this as soon as possible. Thank you for not having forgotten me ;)
Hello to all, after a try just now with the 4.2.6 that I've just download, I'm glad to see that there's no more problem with the hit order between Ctrl and Space. I really don't know why I was the only one with this particular issue. By the way, I'm sorry to have made you wait when you wanted to deepen the research. Actually, as a young dad (and changing job) free time is infinitely hard to release but, by respect, I had to re-inject you quickly into my priorities. Thank deeply to all, keep up the great work guys! Art digital world need to know Krita ;) PS : If the issue reappear, do I need to open a new thread? Just in case?
Hello Bouss, I'm glad to hear that it's fixed for you. Good luck with the new job. If this issue reappears, you can reopen this report by changing the status to REPORTED so that the history is there for people to read.
Sorry, I mean REOPENED.
Thanks for the precision Ahab. Have a good day.