Bug 372009

Summary:	kcolorchooser - 'Add to Custom Colors' overwrites previous custom color
Product:	[Applications] kcoloredit	Reporter:	David Rankin <drankinatty>
Component:	general	Assignee:	Percy Camilo Triveño Aucahuasi <percy.camilo.ta>
Status:	RESOLVED UPSTREAM
Severity:	normal
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description David Rankin 2016-11-03 02:36:15 UTC

Version v2.0.0 on

KDE Frameworks 5.27.0
Qt 5.7.0 (built against 5.7.0)

'Add to Custom Colors' does not 'Add' it 'Wipes Out' any prior custom color unless an empty custom color slot is manually chosen. Attempting to set focus on an empty custom color slot destroys the current color selected replacing the current with #FFFFFF (this is completely broken and mimics the way M$ Win 95 color chooser worked) Color chooser has always added to the 'next available' custom color slot and the RBG values stored in .kde/share/config/colors/Custom_Colors. Now you must manually set focus on the next available slot which sets the current color to #FFFFFF -- completely unwanted behavior.

Any time 'Add to Custom Colors' is chosen, it should store the current color in the next open custom color slot. When all custom colors are filled, scroll-bars should be provided to accommodate. This has worked flawlessly in the past.

Comment 1 David Rankin 2016-11-03 03:12:59 UTC

Custom Colors are not preserved between uses of kcolorchooser. It doesn't appear any backend file saving the information. Setting a custom color, and then opening kcolorchooser again (e.g. to set a color in the Breeze theme) the previous custom colors are gone.

Comment 2 Christoph Feck 2016-11-03 13:38:02 UTC

The KF5 version of kcolorchooser uses QColorDialog. Please report this issue directly to Qt developers via https://bugreports.qt.io/