Version: (using KDE Devel) Installed from: Compiled sources Compiler: g++ (GCC) 4.1.2 20061115 (prerelease) (SUSE Linux) OS: Linux The call will not affect the color of the cell that it is supposed to be called on. I can confirm the problem from Kopete code, within a KDatePicker, and alone in the unit test. (I add the call to that. It really should be there anyways).
Created attachment 22694 [details] Fixes bug The QHash of and QStrings and DatePaintingMode*'s was being misused. Insertion and deletion functions were generating strings from KCalendarSystem::formatDate, but the lookup function was using QDate.toString(). These two different mechanisms produced a different date format, so every lookup was a miss.
I agree with the diagnosis. I would rather turn the customPaintingModes into a QHash keyed on QDate and drop the calls to formatDate everywhere, but that can't be done without creating a qHash() function, and *that* can't be done since it depends on the KDateTable object. Is there a reason why KCalendarSystem::formatDate() is used as the hash key or does anyone know if it can be switched to QDate::toString() which depends only on the QDate? If it can't be switched I would say to apply the patch.
Can I commit the fix?
I would say commit it. It's better to have working code even if non-ideal architecturally. It can be turned into working ideal code later.
Fixed. http://websvn.kde.org/?view=rev&revision=754431