Bug 436078

Trying to reproduce, but have troubles what you mean with Step 2.
What is "the Custom plus button" ? Can you provide a screenshot, please ?
Also what happens after CTRL+C ?
What do you mean with "become unresponsive." ? Can't you work with kolourpaint any longer or is it just slow or what happens ?

(In reply to Martin Koller from comment #1)
> Trying to reproduce, but have troubles what you mean with Step 2.
> What is "the Custom plus button" ? Can you provide a screenshot, please ?
> Also what happens after CTRL+C ?
> What do you mean with "become unresponsive." ? Can't you work with
> kolourpaint any longer or is it just slow or what happens ?

This is the Custom button:
https://i.imgur.com/hvJj0d4.png

After I press Ctrl+C the application becomes unresponsive and I can no longer click on it. I don't have any response from the program if I click on any buttons.

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

Created attachment 138970 [details]
select color dialog

This is the dialog I get when I double click on a color. There is no "+" Button.
How does the complete dialog look on your side ?

Created attachment 139217 [details]
KolourPaint

This is how it looks like for me in its entirety.
OS: Pop!_OS 20.10 x86_64
DE: GNOME 3.38.3
WM: Mutter
WM Theme: Pop
For you it might be the HTML field then. Can you try step 3 and 4 from above in your Select Color window? Try double clicking the HTML field content to select and then copy it into your clipboard.

Of course I did that already in the std. Color Selector Dialog without any problem.
Since the dialog you show is neither the std. Qt Dialog nor any std. KDE dialog AFAIK, I can only imagine that the issue stems from whatever Pop!_OS provides here.
Try asking on their support channel, please.
There is nothing I can do about it here.

(In reply to Martin Koller from comment #6)
> Of course I did that already in the std. Color Selector Dialog without any
> problem.
> Since the dialog you show is neither the std. Qt Dialog nor any std. KDE
> dialog AFAIK, I can only imagine that the issue stems from whatever Pop!_OS
> provides here.
> Try asking on their support channel, please.
> There is nothing I can do about it here.

Actually, I'm 90% sure it's not a POP!OS problem either. I've been having this problem for 5 months now and initially I thought it was a Kolourpaint problem, so I created another report about it here (I didn't know there was a previous report, until now). However, after reporting the problem to Cinnamon as well (because I noticed that this freezing happens in all non-Plasma desktops) and seeing some of the comments there, that led me to the conclusion that the problem is most probably GTK3. As you probably know, there's this package named qt5ct which allows non-Plasma users to set dark themes for the qt5 programs they use and Kolourpaint is such a program. By default Kolourpaint comes with qt5 dialogs and there are no freezing problems with them but if you have qt5ct, you can choose GTK3 dialogs. And this is where the problem comes: choosing GTK3 dialogs leads to Kolourpaint freezing after copying an HTML color code. So I have reported the problem on their issue tracker and whoever is having this problem can keep an eye on it: https://gitlab.gnome.org/GNOME/gtk/-/issues/5167

I can't see an edit button here.
Since I reported the problem to the GTK team, one of their developers, Luca Bacci, said:
"Looks like Kolourpaint connects to the QClipboard::changed signal (frame 12, 13) and retrieves the contents of the clipboard. I don't know much about the X11 clipboard, but what happens is pretty clear: a deadlock because QClipboard waits for "data arrived" to be signaled, but since it goes into a wait state, GTK3 cannot provide any (if not by doing that from a worker thread).

Anyway I don't know if it's possible to have X event loops in multiple threads. The only solution I see is to have Kolourpaint use async operations with QClipboard, that way Qt spins the main loop (and thus X events)."

Hopefully this helps to fix the issue.