[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: KConfigGroup and entryMap
From: "Thomas Braxton" <kde.braxton () gmail ! com>
Date: 2007-12-27 16:22:32
Message-ID: 928c3f1b0712270822k55ef8179n4e9637e296bb765d () mail ! gmail ! com
[Download RAW message or body]
On Dec 27, 2007 5:45 AM, Mauricio Piacentini <piacentini@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
KConfigGroup::readEntryUntranslated().
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
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic