Re: Porting away from KLocale
On 24 October 2013 07:33, Kevin Ottens er...@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. John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Porting away from KLocale
On Thursday 24 October 2013 16:56:47 John Layt wrote: On 24 October 2013 07:33, Kevin Ottens er...@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. Cheers. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by KDAB to work on KDE Frameworks KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Porting away from KLocale
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. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Porting away from KLocale
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
Re: Porting away from KLocale
On Wednesday 23 October 2013 20:40:19 John Layt wrote: 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? Hm, wouldn't that fit in KCoreAddons? * 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 Or have that done by the caller (thinking about KCoreAddons there, it couldn't use KConfig for the default). * 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. 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 signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Porting away from KLocale
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. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Porting away from KLocale
On 17 October 2013 01:51, Aleix Pol aleix...@kde.org wrote: Hi, I was trying to port some application to Qt/KF5, then I realized that I didn't know how to port KLocale::formatByteSize. I don't see anything in QLocale for this, so I feel a bit stuck. Also I don't see any information in KDE5Porting.html Anybody has an idea of what's the solution? Hi, Byte size formatting is not available in Qt, nor natively on any other platform or ICU/CLDR. It was the one thing in KLocale we needed to keep and I think Steve (?) at some stage was looking at breaking it out as a separate utility class. Someone recently submitted a patch to Qt for just this, but Thiago quickly rejected it do to several issues, mostly that there's no standard way of doing it across all platforms. There's a small chance it could get in to 5.3, but it's not a high priority for Qt right now.. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Porting away from KLocale
Hi, I was trying to port some application to Qt/KF5, then I realized that I didn't know how to port KLocale::formatByteSize. I don't see anything in QLocale for this, so I feel a bit stuck. Also I don't see any information in KDE5Porting.html Anybody has an idea of what's the solution? Thanks! Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
