On 23 October 2013 12:56, Aleix Pol <aleix...@kde.org> wrote: > On Tue, Oct 22, 2013 at 2:03 PM, David Faure <fa...@kde.org> wrote: >> >> On Thursday 17 October 2013 23:47:40 Aleix Pol wrote: >> > Well maybe I could help with this, but I'd need to know what do you >> > think >> > it would be the most appropriate solution. >> >> I'd say, split it out into a separate function for KF5, and later on, if >> you >> feel like it, contribute it to Qt for 5.3. > > I created a task for it on the kdelibs cleanups [1] so anybody can pick it > up. > > Aleix > > [1] http://community.kde.org/Frameworks/Epics/kdelibs_cleanups
OK, here's a high-level suggested plan: * The obviously place to move it is k18n, as either part of KLocalizedString or in a new KByteFormatter class? * Move KLocale::BinarySizeUnits, KLocale::BinaryUnitDialect, and KLocale::formatByteSize() * Do we make it a pure static method? Or require an instance to be created? * If static-only then don't need setBinaryUnitDialect(), and binaryUnitDialect() will become a static defaultBinaryUnitDialect() * No locale file overrides the default BinaryUnitDialect, so we only have to worry about reading any user override from kglobals * Default to using QLocale() for number formatting, but need to be able to set a different locale to use. If static-only then just add an extra parameter to override the locale, otherwise will need a setLocale() * Don't forget the tests :-) The only other thing we may also want to keep from KLocale is formatDuration() / prettyFormatDuration(). It's on my todo list for Qt 5.3 and not used many places, but we may want to keep our version for now. Cheers! John. _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
