Bug 172921 - Dialog Parent effect renders Color picker dialog useless if the color you want to pick is in the now-darkened window
Summary: Dialog Parent effect renders Color picker dialog useless if the color you wan...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: effects-various (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: HI normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 222849 288151 363537 399165 475685 483470 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-10-16 07:35 UTC by David Dempster
Modified: 2024-04-13 05:28 UTC (History)
15 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.1
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Dempster 2008-10-16 07:35:44 UTC
Version:            (using KDE 4.1.2)
OS:                Linux
Installed from:    Ubuntu Packages

The Dialogue Parent effect for the KDE 4 desktop conflicts with the eyedropper tool that one can find in (for example) the dialogue that selects the frame colour for the Picture Frame plasmoid.

With Dialogue Parent effect dims the screen, thus making any eyedropper tool useless, as the colour selected ends up being lower in brightness and saturation than desired.

You could make it so that the Dialogue Parent effect detects the presence of an active eyedropper tool.  At the very least, your own eyedropper tool should not be rendered useless.
Comment 1 Sebastian Sauer 2008-12-16 04:49:52 UTC
confirmed through I don't think that to try to work around this in KWin would be a good solution. Well, maybe on activating the eyedropper the eyedropper itself could ask KWin to disable that effect till the wanted color was choosen...
Comment 2 Aaron J. Seigo 2008-12-16 05:20:13 UTC
CC:Lucas master-of-compositing Murray on this one.

Lucas: is there a way you could suggest that would cleanly address this issue in some way? e.g. temporarily suppressing such effects via d-bus or something along those lines?
Comment 3 lucas 2008-12-16 05:39:11 UTC
Someone also wanted to manually override wobbly windows for select applications as well but I do not know what the best way to go about it would be. I don't think that 1) having something KWin-specific would be best as Compiz has similar effects, and 2) manually blacklisting effects is the right way to go about it.

I think I saw someone talking about a possible NET hint on freedesktop.org that could be added in the future that would disabled all window-specific effects on a particular window. That's Lubos's field though.
Comment 4 lucas 2008-12-16 05:57:41 UTC
Just realised that even if there was a hint to disable effects on a window it wouldn't make a difference to the eyedropper. I'm thinking this is CANTFIX.
Comment 5 Aaron J. Seigo 2008-12-16 06:12:47 UTC
> I'm thinking this is CANTFIX. 

you'd know better than i on that one, so i'll leave that call up to you =)
Comment 6 Mathias Soeken 2008-12-16 10:28:40 UTC
What about having custom window flags which can be passed to dialogs and widgets?
Comment 7 Martin Flöser 2010-01-15 19:50:50 UTC
*** Bug 222849 has been marked as a duplicate of this bug. ***
Comment 8 Murz 2010-01-16 07:24:46 UTC
Maybe simply add the button "suspend composing/resume composing" on eyedropper/kcolorchooser window?
Comment 9 Martin Flöser 2010-01-16 10:15:44 UTC
(In reply to comment #8)
> Maybe simply add the button "suspend composing/resume composing" on
> eyedropper/kcolorchooser window?
No, as that would only work with kwin and not with any other composited window manager such as Compiz and Mutter and for the other plattforms like Mac OS and Windows it would be completely useless.

If we want a solution it has to work with all window managers. But I have no idea how to do it (see comment #4)
Comment 10 Murz 2010-01-16 13:17:27 UTC
We can check tha wm, if it is kwin - add composing button, if compiz - add compiz switcher, if unknown - don't add anything.
Comment 11 Thomas Lübking 2010-01-16 14:07:08 UTC
(In reply to comment #9)
> If we want a solution it has to work with all window managers. But I have no
> idea how to do it (see comment #4)

Like ksnapshot - add a(n optional) delay?!
(So the user has some time before the mouse is grabbed.)

Btw:
i don't know about eyedropper and inspected the kcolochooser code last in KDE3 times, but isn't that stuff X11 dependent anyway (anymore)?
Comment 12 Christoph Feck 2014-10-27 00:30:24 UTC
*** Bug 288151 has been marked as a duplicate of this bug. ***
Comment 13 Thomas Lübking 2014-10-27 14:51:24 UTC
Broad statement: this is not a bug, but "undesired behavior".

It's hardly possible to fix this by KWin (just press Shift+Alt+F12, btw.), a KWin "fix" would be no solution in
- mutter
- xfce
- compiz
- random other compositor, let alone wayland.

It would also not allow to pick colors when the desired screen/window state would require to pass on focus or hover a button etc.

So, for KWin I'd vote for resolving this "WONTFIX".

Since KColorDialog is kde4support, this would mean to have a bug against QColorDialog to add a delay (and state that's not available on native pickers, like half the reqst of the QColorDialog functionality)

Opinions?
Comment 14 Martin Flöser 2014-10-27 15:31:23 UTC
for wayland there might be a spec to handle color pickers. Which would allow us to implement support for it. On X11, though, I agree it's a WONTFIX.
Comment 15 Thomas Lübking 2014-10-27 15:40:10 UTC
Got a link?

(I doubt a checkbox "pick actual window" (what does it look like "actually"?) would be an ultimate help - and even if it would allow me to hover and alt+tab etc., I could still not pick the color of anything I can only reach by clicking it, eg. because I need to focus a widget which is not in the windows tab order or the tabfocus is "locked" in a QTextEdit etc.)
Comment 16 Martin Flöser 2014-10-27 16:46:35 UTC
> Got a link?

nah not yet. It's just that currently a kind of EWMH spec list for Wayland is 
going to be created and colorpicker was one of the examples on why such a list 
is needed.
Comment 17 Martin Flöser 2016-05-31 15:13:56 UTC
*** Bug 363537 has been marked as a duplicate of this bug. ***
Comment 18 Martin Flöser 2018-10-04 16:26:42 UTC
*** Bug 399165 has been marked as a duplicate of this bug. ***
Comment 19 kde.org 2021-11-06 21:51:24 UTC
This issue report is quite old. Can you please confirm, that it still persists with KDE 5.23?
Comment 20 Tyson Tan 2021-11-07 01:22:38 UTC
No, I can confirm this issue still happens in KolourPaint and KColorSchemeEditor. 

To simple KDE art-related apps, notably in KolourPaint, our MSPaint equivalent, this bug still cause the app's color picker (which is a core function) to be basically useless. Users of this kind of simple MSPaint equivalent rely heavily on picking color on canvas, this bug makes it impossible to do so, and on that note, greatly reduced the usability of the app.

It once affected Krita's color picker, which makes this bug even more important in my opinion. Disabling Dialogue Parent effect has been the first-to-do after installing a system for years now. However in today's test, I found out that Krita now seems to have implemented some kind of workaround to this. When I use Krita's Palette color picker, it doesn't darken the main window anymore.

For a bug that causes KDE apps to lose a core function ONLY on KDE's own platform, I think this needs to be fixed or Dialogue Parent effect should be disabled by default. It makes no sense to break a core function for some superfluous visual effect.
Comment 21 kde.org 2021-11-07 09:04:42 UTC
thank you for your feedback! We'll see what the developers can do about this. If it can easily be fixed, maybe the effect should be disabled by default.
Comment 22 Nate Graham 2023-12-20 23:10:12 UTC
*** Bug 475685 has been marked as a duplicate of this bug. ***
Comment 23 Nate Graham 2024-03-14 19:32:40 UTC
*** Bug 483470 has been marked as a duplicate of this bug. ***
Comment 24 ratijas 2024-03-26 13:50:51 UTC
I've played enough with color panels/dialogs, Krita & KolourPaint. I don't see any way to fix Dialog Parent effect globally.

- The KWin script only checks for the modal window flag;
- KDE/Plasma platform theme integration does not provide any custom color dialog, and even if it were, changing the modality on behalf of client code would be inappropriate (as in: source of bugs and complaints);

Clients should be ported from blocking QDialog::exec to the non-blocking slots + QWidget::show() in order to accommodate non-modal color panels, à la Krita style. However, that would involve at least ~+10 lines of code, which is doable but highly custom ever time. QColorDialog API sucks, primarily because it is too busy being a dialog (instead of a panel): its both open() method overloads mess with modality (they hardcode it to WindowModal) even it it were explicitly disabled beforehand, and one overload is the only way to conveniently set receiver/slot pair — otherwise you'd have to perform some bookkeeping for a Connection object (if the dialog is shared/recycled which it really should be, to prevent multiple non-modal dialogs from being opened simultaneously for different controls). Also, disabling modality *after* a dialog is open completely softlocks application's main window and event handling in Qt, which is most likely a Qt bug.

Technically, we *could* match on window caption being equal to or starting with `QColorDialog::tr("Select Color")`, but that would be sloppy at best (besides adding a dozen or conditionals and connections to the effect's code, and requiring API to get a translated string from Qt catalogue in pure JS).

We *could* implement a custom X11 _NET_WM_STATE atom and a Wayland protocol. But that's way too overkill for a problem which should be solved on a conceptually different level anyway (i.e. by porting color dialogs to non-blocking panels).

As unfortunate as it is, the bug report probably better be closed as #resolved #intentional, and efforts spent on an actual porting rather than searching for clever workarounds.
Comment 25 Bug Janitor Service 2024-04-10 20:18:54 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5596
Comment 26 ratijas 2024-04-12 17:02:21 UTC
Git commit 344e56dd77e90476023e434e48382b566def13a2 by ivan tkachenko.
Committed on 12/04/2024 at 16:39.
Pushed by ratijas into branch 'master'.

plugins/dialogparent: Disable darkening while picking colors

Integrate with colorpicker effect to disable window darkening while
color picker effect is active. Unfortunately, this solution has couple
of limitations:
- active state of effects is not an observable property, so a new
  property had to be added to the effects singleton;
- consequently, list of active effects is not an observable property, so
  the whole thing could not be implemented in pure QML in the dialog
  parent effects;
- actual isActive() state of the color picker for whatever reason
  required that m_scheduledPosition is not an invalid point,
  effectively making it always inactive except for a brief moment
  between addRepaintFull() call and paintScreen() callback. That check
  had to be removed.
- QColorDialog windows are still modal and darkened by default;
- QColorDialog on X11 does not use portals/KWin, so this trick does not
  apply at all;
- effects->isScreenLocked() which isActive() depends on is not an
  observable property either.

M  +5    -0    src/effect/effecthandler.cpp
M  +9    -1    src/effect/effecthandler.h
M  +16   -5    src/plugins/colorpicker/colorpicker.cpp
M  +1    -0    src/plugins/colorpicker/colorpicker.h
M  +23   -23   src/plugins/dialogparent/package/contents/code/main.js

https://invent.kde.org/plasma/kwin/-/commit/344e56dd77e90476023e434e48382b566def13a2