Invoking the Color Selector, Show Common Colors, or Show Color History widgets disables (temporarily) the keybord and all Krita shortcuts, until moving the focus from Krita main window to any other place and returning back. It seems to be related to this particular type of Qt widget, which is different than the normal modal dialogs. It would seem as if the widget is not destroyed/exited properly or somehow doesn't return the focus properly until we perform one of the actions listed below, after which the shorcuts and keyboard work again. IMPORTANT: This problem happens in the Xfce window manager, and it does NOT happen in KDE (or at least I can't reproduce it there). The problem would appear to me to be related to the infamous "Qt in GTK" or "GTK in Qt" troubles; I wonder if it would also happen in other GTK environments. Please note that this bug is somewhat similar to Bug 366353, but I am opening it new here, because that one is not very well documented, no answer was ever provided to developer's question, it's old and seems dead. Krita 3.3.1 (appimage) in Kubuntu 16.04 running Xfce (system details below). Reproducible: Always Steps to reproduce: 0. Use Xfce window manager. (In my KDE system this problem does NOT exist.) 1. Open a krita file and paint some stroke. 2. Invoke the the Color Selector widget (e.g. Shift + I in my case). When it shows up, select a color. Note: The same problem will happen if you invoke the Show Common Colors or the Show Color History widgets. 3. Paint some stroke. From this moment on, shortcuts stop working, i.e. krita does not respond to any keyboard shortcut at all, e.g. Shift + I, ctrl + Z, U, etc. 4. Try any krita shortcuts, for example undo with ctrl + Z or any others. Krita does not react to any keyboard shortcuts. 5. To get the shortcuts working again, changing the focus from the main Krita window and then focus back again to Krita will "fix it". For example, doing any of the following actions works: a) Press <Alt>+<Tab> and release it. After this, the shortcuts work again. OR: b) Click on any other window that is open on your Desktop, to change the focus to that window, and immediately click back on Krita's window to get the focus on Krita again. OR: c) Minimize the Krita main window, and then restore it back. OR: d) Open any krita dialog by clicking menus, and then close that dialog. Examples: Click Settings > Configure Krita and just press Cancel to close the dialog. OR: Click File > New, then click Cancel or hit the Esc key to close the dialog. OR: ....Probably opening and closing any dialog would do. The shortcuts work again, but opening any of the mentioned widgets again, the problem reproduces again: it works, but then shortcuts stop working until you change focus of the window or open and cancel any dialog. Expected Results: Invoking and using any widget or tool should not cause any blockage of shortcuts or any other usability impairments. Additional notes: Although I'm not 100% sure these are related, I thought I should mention: The following error is shown on console output around the time we select Shift + I (Color Selector shortcut) for the first time, (but not necessarily anymore): QLayout: Attempting to add QLayout "" to QWidget "KritaShape/KisToolLine", which already has a layout In my .shotcuts file, 'KritaShape/KisToolLine' is set to 'none'. The following warning (and/or other similar ones) is also show during this time: krita.general: WARNING: The following shortcuts are not registered in the collection, they might have wrong shortcuts in the end: krita.general: "add_new_colorize_mask" krita.general: "show_tool_options" krita.general: "detailed_debug_paragraphs" krita.general: "file_print" krita.general: "file_print_preview" krita.general: "options_configure_keybinding" krita.general: "file_export_pdf" krita.general: "detailed_debug_styles" krita.general: "KritaShape/KisToolLazyBrush" krita.general: === end === ---- System Information: Krita Version: 3.3.1 OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 4.4.0-97-generic Pretty Productname: Ubuntu 16.04.3 LTS Product Type: ubuntu Product Version: 16.04 OpenGL Info Vendor: NVIDIA Corporation Renderer: "GeForce GTX 1050 Ti/PCIe/SSE2" Version: "4.5.0 NVIDIA 384.90" Shading language: 4.50 NVIDIA Requested format: QSurfaceFormat(version 3.0, options QFlags(0x4), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples -1, swapBehavior 2, swapInterval 0, profile 2) Current format: QSurfaceFormat(version 4.5, options QFlags(0x4), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 0, stencilBufferSize 8, samples -1, swapBehavior 2, swapInterval 0, profile 2) Version: 4.5 Supports deprecated functions true is OpenGL ES: false
Sorry, but this just is a duplicate of 366353 -- and since the version of xfce that comes with opensuse doesn't show the problem, I am pretty sure that it's their bug... *** This bug has been marked as a duplicate of bug 366353 ***
Thank you for ultra-quick reply. However it's a bit ultra-short too. By "their" I suppose you mean the ubuntu Xfce packagers? Could you please provide some hint of how could this be pursued: I am painfully guessing that if I file a bug in Xfce or Ubuntu saying that three of the Krita widgets don't work they will also 'resolve' the ticket as "their (Krita) problem". Could you please provide some pointers of how to phrase or put the problem so that it's of interest of "them"? How could I get an Xfce developer's attention to three Krita widgets not working as intended in one of their flavors. I wouldn't like to let this die out of lack of direction or frustration. I also couldn't agree in having this bug 'resolved', as it's misleading someone else who is running krita in similar conditions as I am. Although I do have a KDE system where this issue is not there, anyone who sees this thread might conclude (I am close to that) that there will be no solution for this issue, or there is no issue, which is not true. Thank you
Oh, I forgot to say, that I run krita in Xfce, not KDE for a reason. It would be very sad if I have to assume that krita won't run in Xfce unless it's opensuse, which is not a distribution I am going to use any time soon. My point is, that ultimately, the fact is krita won't work in -at least- the ubuntu flavor of xfce. If that's what it is, too bad, but then it should be stated somewhere, and this thread is a good start.
I don't mean the Ubuntu packagers, I mean the xcfe developers. I suspect that their window manager -- and I don't know which it is -- just doesn't follow the spec correctly when it comes to popup widgets. Plasma's kwin and Gnome's mutter seem to be fine. But I'm not an xfce user, I only installed it to test the duplicate bug, and I couldn't reproduce it. But since it's not a bug in Krita itself it would be wrong to keep this bug open; we could add a faq entry, but in the first place, the faq is pretty long already, and in the second place, the issue is quite obscure -- and finally, nobody ever seems to read the faq before reporting a bug, in my experience.
(In reply to Boudewijn Rempt from comment #4) > I don't mean the Ubuntu packagers, I mean the xcfe developers. > > I suspect that their window manager -- and I don't know which it is -- just > doesn't follow the spec correctly when it comes to popup widgets. Plasma's > kwin and Gnome's mutter seem to be fine. But I'm not an xfce user, I only > installed it to test the duplicate bug, and I couldn't reproduce it. > > But since it's not a bug in Krita itself it would be wrong to keep this bug > open; we could add a faq entry, but in the first place, the faq is pretty > long already, and in the second place, the issue is quite obscure -- and > finally, nobody ever seems to read the faq before reporting a bug, in my > experience. Thanks. I appreciate your comments and quick reply. I understand your point; still, I just think that "resolved" is not the correct status for this. It would seem that there was an issue and it was fixed, which is not true. Wouldn't it be more accurate something like "Won't fix"? I mean, that's what it is: an issue affecting Krita that its devs won't get into fixing it. If you were not able to reproduce it, you could say "can't reproduce", but not before actually testing on xfce on ubuntu -unless some other user would say "me too". If you, a Krita authority, qualify the issue as obscure: how do you think a Xfce dev will qualify it when he might not even have a clue of what Krita is, let alone reading a description of how to use it? My chances of getting this ever looked at are zero. If it is only me, then that's OK, only one guy with who know what strange constellation of variables that not even me would care about. But what if it's more people too? I have read that high profile users like David Revoy uses (or have used) Xfce, in his blog. I would be curious to know if it's only me. In any case, I do have difficulty in searching for information on googling for a legitimate issue in Krita and find that is has been "resolved", when it's not. It's not a matter of who to blame, it's a matter of document that there is an issue, fixable or not, that tells me that I better quit on using Krita in such context and choose instead another one. This strikes me as very uncomfortable, because when I write some JavaScript code that works in Firefox but it doesn't in e.g. Chrome, and I get a complaint from someone who uses Chrome, I cannot just go ahead and 'resolve' the complaint as a Chrome's problem. Why? Different browsers have different flavors of JavaScript. If I don't care about Chrome users, then I can say "sorry we don't support Chrome, please follow the instructions, you must use Firefox." Done. But if I do need to support Chrome users, I could never suggest 'hey, file a bug with Google to fix Chrome so that my code works in it'. It is me who have to ensure my code is compatible with whatever browsers I want to support, not the other way around. And those that I don't, I have to inform users about it: please don't run it on XYZ because it won't work! That's why browsers suck (not JavaScript). I can say here window managers suck too. Sorry for long post. I like so much Krita, I hope I can help somehow.
Bugzilla is a tool for developers; Bugzilla is about stuff that I can do something about: if I cannot do something about it, I don't want it to clutter the list of open issues. If you think "resolved" is wrong, I'll mark it "closed", even though we don't use that status normally.