Bug 372009

Summary: kcolorchooser - 'Add to Custom Colors' overwrites previous custom color
Product: [Applications] kcoloredit Reporter: David Rankin <drankinatty>
Component: generalAssignee: 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/Implemented 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/