Created attachment 115281 [details] Unable to pick screen color correctly in Text Color dialogue because of canvas greys-out SUMMARY Krita's Text Color selector is unable to pick from screen color correctly, because opening its Add/Remove Color sub dialogue greys out Krita's UI. This greatly undermines Krita's ability to carry out graphics typography tasks. STEPS TO REPRODUCE 1. Start text tool, click the right-most droplist triangle on the toolbar on the right of the text color square. 2. Click [Add/ Remove Colors...] 3. Click [+] 4. Click [Pick Screen Color] OBSERVED RESULT Krita's main window greys out after STEP 2. This makes it impossible to pick correct color from screen. EXPECTED RESULT Anything that makes it possible to pick screen color without *4* STEPS and stop that grey-out screen at the end. I think it would be nice to have a dedicated button for Pick Screen Color (with a color picker icon) on the right-side of Text Color icon on Text dialogue's toolbar. SOFTWARE VERSIONS (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
The graying out seems to be activated by a desktop effect in the windows manager, because the text editor is a modal window. Do you have the same graying out with Filter dialog? I guess there is no fading, right?
(In reply to Dmitry Kazakov from comment #1) > The graying out seems to be activated by a desktop effect in the windows > manager, because the text editor is a modal window. Do you have the same > graying out with Filter dialog? I guess there is no fading, right? I've found the setting you said in: KDE > System Settings > Desktop Behavior > Desktop Effects > [X] Dialogue Parent By KDE Plasma 5's default, this setting is ON. On Windows, this problem does not exist. Actually, KDE Plasma 5 has a handful of settings I know that goes against Krita's UI design, most of them are hidden in some dialogue maze with cryptic names like this one. Is it possible to avoid these conflicts? Krita is a KDE application after all, and it feels wrong that it could not function properly only under KDE Plasma of all places. FYI, the worse KDE conflict of all: KDE > System Settings > Window Management > Window Behavior > [Tab] Windows Actions > [Section] Inner Window, Titlebar & Frame > [Droplist] Modifier Key This setting by default is "Alt", which takes away Krita's Alt key short cuts that are so important in many actions. It's so hard to find too. We don't have this problem on other platforms. P.S. We should probably change the bug's title into: Krita and KDE Plasma 5 default Window Management settings conflicts
SUMMARY OF THE MAJOR PROBLEMS SO FAR: # Krita main window greys-out when using "Pick color from screen" from Text dialogue Conflicts with: KDE > System Settings > Desktop Behavior > Desktop Effects > [X] Dialogue Parent (Defaults to ON) # Krita's alt key is not functional Conflicts with: KDE > System Settings > Window Management > Window Behavior > [Tab] Windows Actions > [Section] Inner Window, Titlebar & Frame > [Droplist] Modifier Key (Defaults to Alt)
The drag the window by empty areas is a nasty one as well, especially when you're using a pen. I've checked the Window-Specific Settings in kwin, but there's no options to change any of these things per-application. It really is something that should be solved in kwin, though, we cannot work around that.
Lets keep it to one bug per report. I will turn this into colour picking and Dialogue Parent. If there are others (like this alt thing) please file new reports.
Most obvious solution that springs to mind: - we make colour picker a full screen effect - we make dialogParentEffect disable on full screen effects The alternate approach of changing colourpicker to pick from the source texture rather than final FBO seems like a route we probably don't want to go down.
@boud RE: other drags https://phabricator.kde.org/D15942
(In reply to David Edmundson from comment #6) > Most obvious solution that springs to mind: > - we make colour picker a full screen effect > - we make dialogParentEffect disable on full screen effects In fact, that's what we have to do (disable the dialog parent effect while there is an active full screen effect). What if the Desktop Cube effect is active while one wants to pick a color? (Please notice that we would need to force blur and background contrast) Another potential solution is to emit a signal like (colorPickerActivated), then in the Dim Inactive and the Dialog Parent effect we would listen for those effects. If we receive the signal, we cancel existing animations.
s/those effects/that signal/
That also assumes krita is using the Kwin colour picker DBus API, which you'd need for wayland...but probably isn't the current state.
This particular dialog is the default color dialog from Qt: that is sort of legacy for us. We also have our own screen color picker implementation for our own color dialog: https://phabricator.kde.org/source/krita/browse/master/libs/ui/widgets/KisScreenColorPicker.cpp. It first checks whether the point is in our canvas, and then gets the color from the canvas itself, otherwise it will get the color from the screen.
(In reply to David Edmundson from comment #5) > Lets keep it to one bug per report. > > I will turn this into colour picking and Dialogue Parent. > If there are others (like this alt thing) please file new reports. Should I report the ALT conflict on a new report now?
Yes please
That whole dialog is going to create an very interesting wayland challenge :/ But sticking with X for now both you and Qt are using: const QPixmap pixmap = QGuiApplication::primaryScreen()->grabWindow(desktop->winId(), p.x(), p.y(), 1, 1); and taking it from X's FB. Proposed plan above won't help.
*** This bug has been marked as a duplicate of bug 172921 ***