Porting away from KLocale

[Kevin Ottens]

On Thursday 24 October 2013 19:22:02 Albert Astals Cid wrote:
> 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?

Looks like what I described was unclear. :-)

With my proposal, it's basically what you'd get but having the method still in 
Tier 1. The idea being that the actual call to KConfig is done outside of 
KCoreAddons but it then puts the setting in a shared space, if for some reason 
this call didn't happen (with the technique I propose it'd be if we don't have 
the platform theme loaded) then we fallback to a hardcoded default.

So you get all the apps using the same way of calculating the KB as before.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

Sponsored by KDAB to work on KDE Frameworks
KDAB - proud supporter of KDE, http://www.kdab.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20131025/83b82af4/attachment.sig>