Porting away from KLocale

Albert Astals Cid aacid at kde.org
Thu Oct 24 17:22:02 UTC 2013


El Dijous, 24 d'octubre de 2013, a les 17:44:01, Kevin Ottens va escriure:
> On Thursday 24 October 2013 16:56:47 John Layt wrote:
> > On 24 October 2013 07:33, Kevin Ottens <ervin at kde.org> wrote:
> > > On Wednesday 23 October 2013 20:40:19 John Layt wrote:
> > >> * The obviously place to move it is k18n, as either part of
> > >> KLocalizedString or in a new KByteFormatter class?
> > > 
> > > Hm, wouldn't that fit in KCoreAddons?
> > > 
> > >> * No locale file overrides the default BinaryUnitDialect, so we only
> > >> have to worry about reading any user override from kglobals
> > > 
> > > Or have that done by the caller (thinking about KCoreAddons there, it
> > > couldn't use KConfig for the default).
> > 
> > Well, that becomes the central question then, if we allow users to set
> > a global override or not?  I don't think its very useful to tell all
> > apps that they need to read the global config themselves to see how to
> > format the bytes, they would reasonably expect that that is what the
> > method is there to hide from them.  It would effectively become an
> > application-level setting depending on if the app decides to read the
> > config.  On the other hand, if Qt eventually gains support it can use
> > the setting from there.  If we're happy to ignore user settings for
> > now then KCoreAddons will be fine.
> 
> I think we can go this route. Worst case we can channel the default setting
> through a dynamic property on the application object which would be set by
> the platform theme plugin. We used to do that for some other features.

I understand you guys want to make things as low in tiering as possible to 
ease the reuse of stuff, but can you please also think about those of use that 
want to deliver a consistent desktop where it makes sense that all the apps 
use the same way of calculating the KB? Maybe we can have one function that 
does not depend on KConfig and one that does for those of us that want the 
consistency/ease of use?

Cheers,
  Albert

> 
> Cheers.



More information about the Kde-frameworks-devel mailing list