| Summary: | KDateTable::setCustomDatePainting() doesn't do anything | ||
|---|---|---|---|
| Product: | [Unmaintained] kdelibs | Reporter: | Charles Connell <charles> |
| Component: | kdeui | Assignee: | kdelibs bugs <kdelibs-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | HI | ||
| Version First Reported In: | SVN | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | Fixes bug | ||
|
Description
Charles Connell
2007-12-26 23:54:20 UTC
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. |