Lightweight API for localization of images, icons, etc.

[David Faure]

On Tuesday 15 January 2008, Chusslove Illich wrote:
> > [: David Faure :]
> > So using KStandardDirs::locate() is a working solution? Or did you choose
> > a solution that makes KStandardDirs::locate() not work? I'm a bit
> > confused :-)
> >
> > (And if locate works, is localizedFilePath() needed?)
> 
> Darn my wording, though I don't know how to put it better :)
> 
> Yes, this makes KStandardDirs::locate() a working solution, and the method
> for manual path wrapping is there only in case KStandardDirs::locate() is
> not directly used. Looking around the code in SVN a bit, I saw that at
> places e.g. KStandardDirs is used only to locate the top directory of
> resources, and then it proceeds with custom code. Only in that case one
> would have to manually wrap the final path of interest.

OK, but the real question is: are we sure that this code couldn't use KStandardDirs instead? :-)
I am not convinced about adding redundant API just because application code doesn't do things right, you see...

> I'm just wondering about the name itself. In particular now that one would
> use KLocale::i18nFilePath(...), which is near to
> KGlobal::locale()->localizedFilePath(...). And I'd like to avoid the latter
> for general use, because then the caller should for safety first check
> KGlobal::hasLocale() (which i18nFilePath does internally).

hasLocale is only false in corner cases (hmm, broken installs? unit tests? very early during app startup), no?

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).