KConfigGroup and entryMap

Thomas Braxton kde.braxton at gmail.com
Thu Dec 27 16:22:32 GMT 2007

On Dec 27, 2007 5:45 AM, Mauricio Piacentini <piacentini at kde.org> wrote:
> Apparently there was a recent change in behavior for
> KConfigGroup->entryMap(). This broke translation of theme files for
> games, you can see it in KMines for example. What happens in short is
> the in kgametheme.cpp we had something like:
>      KConfigGroup group = themeconfig.group(d->themeGroup);
>      d->themeproperties = group.entryMap();
> And the returned entryMap would have the entries in the default, non
> localized format. If we do:
>      KConfigGroup group = themeconfig.group(d->themeGroup);
>      kDebug(11000) << "Name map is" << group.readEntry("Name");
> Then Name is returned in the correct, localized format.
> So the question is: how do we deal with this? One obvious solution now
> is to maybe loop through all the keys in the returned entryMap (or use
> KConfigGroup->keyList(), which is also untranslated right now), and
> extract and store the localized versions for the values. HOWEVER, this
> might break again in the future, if entryMap() or keyList() is changed
> to return localized data. It is a matter of how the API is supposed to
> work. To the KConfig guys:
> In the case above, what is the correct behavior? Should entryMap or
> keyList return translated data, or not? Can we rely on this for the future?

entryMap() will/should return a localized entry if there is one.
Usually if the entry _is_ localized the localized version is the one
wanted. If you need the untranslated entry you should use

keyList() simply returns the names of the entries, so it shouldn't be
able to return anything localized.

> I am not sure at which point the behavior of KConfig was changed, but
> right now my main concern is to define the behavior of the API, instead
> of coding a workaround in libkdegames that might break again in the future.
> Regards,
> Mauricio Piacentini

More information about the kde-core-devel mailing list