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.
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...
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?
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.
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.
> I'm thinking this is CANTFIX. you'd know better than i on that one, so i'll leave that call up to you =)
What about having custom window flags which can be passed to dialogs and widgets?
*** Bug 222849 has been marked as a duplicate of this bug. ***
Maybe simply add the button "suspend composing/resume composing" on eyedropper/kcolorchooser window?
(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)
We can check tha wm, if it is kwin - add composing button, if compiz - add compiz switcher, if unknown - don't add anything.
(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)?
*** Bug 288151 has been marked as a duplicate of this bug. ***
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?
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.
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.)
> 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.
*** Bug 363537 has been marked as a duplicate of this bug. ***
*** Bug 399165 has been marked as a duplicate of this bug. ***
This issue report is quite old. Can you please confirm, that it still persists with KDE 5.23?
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.
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.
*** Bug 475685 has been marked as a duplicate of this bug. ***
*** Bug 483470 has been marked as a duplicate of this bug. ***
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.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5596
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