To set and retrieve category colors, a TagCache is used, where tags are stored by gid. So far, the utf8 encoding of a tag's name was used to retrieve a tag from the cache. In general, however, the gid of a tag is not the same as its name. Since the gid may be unknown when looking for a tag's color, this change switches to the tags' names for keys.
Fixes Bug 333754
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
I don't think that iti si a good idea to change the API from getTagByGid -> getTagByName, because also other applications use this.
My suggestion to add a Method called getTagByGidOrName. we ( kolab) have written one based at 4.13:
https://git.kolab.org/rKPddc2f877ac219ac7a29ba8778b50f40f1093a9cc
That way you don't break old code.
The original methods of TagCache were restored in order not to break old code that relies on it. In order to avoid name-gid collisions and because of the fact that clients know whether they want to match gids or names, we maintain separate methods for the tag name and gid caches.
| src/tagcache.h | ||
|---|---|---|
| 58 | I would suggest QHash<QString, Akonadi::Tag::Id>, becuase the name is actually a QString, so no need to convert it to/from a QString. | |
i have tested this form a user perspective on fresh tags and it works without any problems so far. categories keep their color.
Looks good, two minor nitpicks:
As this introduces new public API, you have to bump PIM_VERSION in CMakeLists.txt.
| src/tagcache.h | ||
|---|---|---|
| 45 | The argument should be called name | |
Fix what was asked for. I assume it is sufficient to change the PIM_VERSION in the CMakeFile.txt of calendarsupport only, since PIM_VERSIONs between pim modules are already diverging.
Please note that I do not have commit access, so reviewers, go ahead :-)