https://bugs.kde.org/show_bug.cgi?id=172921
ratijas <m...@ratijas.tk> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |m...@ratijas.tk
--- Comment #24 from ratijas <m...@ratijas.tk> ---
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.
--
You are receiving this mail because:
You are watching all bug changes.
