Re: KUnitConversion Review

2014-04-03 Thread Aleix Pol
On Thu, Feb 27, 2014 at 5:15 PM, John Layt jl...@kde.org wrote:

 Hi,

 I've been reviewing KUnitConversion (KUC for short) and doing some small
 clean-ups, and I'm slowly coming to the conclusion I'm not a fan of the
 api.
 However it is used in a few places, so rather than try rewrite the api in
 the
 time remaining, I'll finish up the clean-ups and we can release it as is
 and
 look to replace it later on.

 The main clean-ups are:

 * Remove use of KCurrencyCode.  Currently it's only used to get the
 currency
 name of the 50 currencies KUC supports and it seems overkill to keep all
 207
 data files and the api in KUC just for that purpose.  Instead I'd move it
 to
 kde4support with the rest of KLocale (we also need to move the config files
 from kde-runtime).  This would also remove the dependency on KConfigCore.

 * Try port away from ki18n to tr().  KUC makes extensive use of ki18nc()
 and
 ki18ncp(), but I need to check with Chusselove if all the plural
 translations
 can be handled with Qt or if any are scripted.

 * If we remove those two dependencies then KUC becomes Tier 1, but Tier 2
 is
 fine either way.

 * Convert more classes to QSharedData

 * Some small API changes

 * Lots of docs clean-ups, code style, etc are needed but can be done later.

 I've done the first step, and I just need a volunteer to do the git magic
 required to:

 * Move kcurrencycode.h and kcurrencycode.cpp including history from
 kunitconversion/src to kde4support/src/kdecore

 * Move kde-runtime/localization and everything in it including history to
 kde4support/src/localization or kde4support/runtime/localization or
 wherever deemed appropriate

 * Move kde-runtime/l10n and everything in it including history into the
 same
 localization folder as above but folder renamed from l10n to
 localization/country (i.e. at same level as currency folder)

 * Make sure the data files are built and installed, but need to think about
 parallel installs with KDE4 data files

 The data file moves are part of the kde-runtime clean-up, but it makes
 sense
 to do them alongside the code moves.

 Longer term, I've started work on a new Tier 1 library tentatively called
 KStandards to support the different ISO code standards, and measurement
 standards and conversions.  I've already converted KCurrencyCode to a new
 KCurrency class using json files, and KCountry and KUnits should follow in
 due
 course to provide a future migration path for apps that need them.

 Cheers!

 John.

 ___
 Kde-frameworks-devel mailing list
 Kde-frameworks-devel@kde.org
 https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


Can we get an update on what's the status of this? Is KCurrency going to
kde4support? Maybe it's not needed to deprecate it yet? It can get
deprecated at some point in the future within KUnitConversion and then we
can add new classes when the ISO alternatives are available.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


Re: KUnitConversion Review

2014-03-04 Thread Kevin Ottens
On Tuesday 04 March 2014 01:04:05 John Layt wrote:
 So, now KPrintUtils and KUnitConversion are about done (bar the
 KCurrencyCode move), are there any other Frameworks needing review?

All the unmaintained ones, some of the maintained ones too.

 At Tier 1 level it just looks like KCodecs, KGuiAddons and KIdleTime
 are unclaimed?

Is it an offer to be the maintainer for more frameworks? Be my guest. :-)

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

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: KUnitConversion Review

2014-03-04 Thread Alex Merry
On 02/03/14 18:58, Kevin Ottens wrote:
 On Thursday 27 February 2014 17:15:56 John Layt wrote:
 I've done the first step, and I just need a volunteer to do the git magic
 required to:

 * Move kcurrencycode.h and kcurrencycode.cpp including history from
 kunitconversion/src to kde4support/src/kdecore

 * Move kde-runtime/localization and everything in it including history to
 kde4support/src/localization or kde4support/runtime/localization or
 wherever deemed appropriate

 * Move kde-runtime/l10n and everything in it including history into the
 same localization folder as above but folder renamed from l10n to
 localization/country (i.e. at same level as currency folder)

 * Make sure the data files are built and installed, but need to think about
 parallel installs with KDE4 data files

 The data file moves are part of the kde-runtime clean-up, but it makes sense
 to do them alongside the code moves.
 
 Any taker for those moves? Alex, I think you already did a couple of those 
 right?

OK, I'll have a look at some point this week.

Alex
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


Re: KUnitConversion Review

2014-03-04 Thread John Layt
On 4 March 2014 09:25, Kevin Ottens er...@kde.org wrote:
 On Tuesday 04 March 2014 01:04:05 John Layt wrote:
 So, now KPrintUtils and KUnitConversion are about done (bar the
 KCurrencyCode move), are there any other Frameworks needing review?

 All the unmaintained ones, some of the maintained ones too.

 At Tier 1 level it just looks like KCodecs, KGuiAddons and KIdleTime
 are unclaimed?

 Is it an offer to be the maintainer for more frameworks? Be my guest. :-)

It is, as I seem to have lost one along the way ;-)  I was thinking by
reviewing some of them I'd get a better idea of what would be suitable
for me, so if there's any you think are higher priority let me know.

Cheers!

John.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


Re: KUnitConversion Review

2014-03-04 Thread Kevin Ottens
On Tuesday 04 March 2014 15:29:33 John Layt wrote:
 On 4 March 2014 09:25, Kevin Ottens er...@kde.org wrote:
  On Tuesday 04 March 2014 01:04:05 John Layt wrote:
  So, now KPrintUtils and KUnitConversion are about done (bar the
  KCurrencyCode move), are there any other Frameworks needing review?
  
  All the unmaintained ones, some of the maintained ones too.
  
  At Tier 1 level it just looks like KCodecs, KGuiAddons and KIdleTime
  are unclaimed?
  
  Is it an offer to be the maintainer for more frameworks? Be my guest. :-)
 
 It is, as I seem to have lost one along the way ;-)  I was thinking by
 reviewing some of them I'd get a better idea of what would be suitable
 for me, so if there's any you think are higher priority let me know.

KGuiAddons definitely. The other two are important too, but this one is even 
more important.

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

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: KUnitConversion Review

2014-03-04 Thread John Layt
On 4 March 2014 15:59, Kevin Ottens er...@kde.org wrote:

 KGuiAddons definitely. The other two are important too, but this one is even
 more important.

OK, I'll get onto that then.

John.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


Re: KUnitConversion Review

2014-03-03 Thread John Layt
On 2 March 2014 19:58, Kevin Ottens er...@kde.org wrote:
 On Thursday 27 February 2014 17:15:56 John Layt wrote:

 * Try port away from ki18n to tr().  KUC makes extensive use of ki18nc() and
 ki18ncp(), but I need to check with Chusselove if all the plural
 translations can be handled with Qt or if any are scripted.

 * If we remove those two dependencies then KUC becomes Tier 1, but Tier 2 is
 fine either way.

 Would be nice to have it tier 1 if possible indeed. Nice move.

Still to be done, but I've now removed all the uses of
KLocalizedString in the api of the public classes, so it will be safe
to remove the dependency at any time in the future.

 * Convert more classes to QSharedData

 * Some small API changes

 Please also do so before beta 1.

Done, and pushed.  It's a BIC  and SIC change, but it appears no-one
has ported to use the KF5 version as yet.  All the classes are now
proper shared data containers, and all the internal implementation
details that had leaked into the public classes have been removed, so
it's a lot cleaner.  I've put the details in the porting guide.  I
still have a few small changes to look at, but this is the serious
stuff done.  I'll clean-up the apidox and add more tests later.

 Longer term, I've started work on a new Tier 1 library tentatively called
 KStandards to support the different ISO code standards, and measurement
 standards and conversions.  I've already converted KCurrencyCode to a new
 KCurrency class using json files, and KCountry and KUnits should follow in
 due course to provide a future migration path for apps that need them.

 Excellent. Any effort on it should be scheduled at KF 5.1 though.

Yeap, 5.1 is the plan, I want to try get some supporting stuff in Qt
as well, but I'll probably roll a Tech Preview around the KF5 release.

So, now KPrintUtils and KUnitConversion are about done (bar the
KCurrencyCode move), are there any other Frameworks needing review?
At Tier 1 level it just looks like KCodecs, KGuiAddons and KIdleTime
are unclaimed?

Cheers!

John.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


KUnitConversion Review

2014-02-27 Thread John Layt
Hi,

I've been reviewing KUnitConversion (KUC for short) and doing some small 
clean-ups, and I'm slowly coming to the conclusion I'm not a fan of the api.  
However it is used in a few places, so rather than try rewrite the api in the 
time remaining, I'll finish up the clean-ups and we can release it as is and 
look to replace it later on.

The main clean-ups are:

* Remove use of KCurrencyCode.  Currently it's only used to get the currency 
name of the 50 currencies KUC supports and it seems overkill to keep all 207 
data files and the api in KUC just for that purpose.  Instead I'd move it to 
kde4support with the rest of KLocale (we also need to move the config files 
from kde-runtime).  This would also remove the dependency on KConfigCore.

* Try port away from ki18n to tr().  KUC makes extensive use of ki18nc() and 
ki18ncp(), but I need to check with Chusselove if all the plural translations 
can be handled with Qt or if any are scripted.

* If we remove those two dependencies then KUC becomes Tier 1, but Tier 2 is 
fine either way.

* Convert more classes to QSharedData

* Some small API changes

* Lots of docs clean-ups, code style, etc are needed but can be done later.

I've done the first step, and I just need a volunteer to do the git magic 
required to:

* Move kcurrencycode.h and kcurrencycode.cpp including history from 
kunitconversion/src to kde4support/src/kdecore

* Move kde-runtime/localization and everything in it including history to 
kde4support/src/localization or kde4support/runtime/localization or 
wherever deemed appropriate

* Move kde-runtime/l10n and everything in it including history into the same 
localization folder as above but folder renamed from l10n to 
localization/country (i.e. at same level as currency folder)

* Make sure the data files are built and installed, but need to think about 
parallel installs with KDE4 data files

The data file moves are part of the kde-runtime clean-up, but it makes sense 
to do them alongside the code moves.

Longer term, I've started work on a new Tier 1 library tentatively called 
KStandards to support the different ISO code standards, and measurement 
standards and conversions.  I've already converted KCurrencyCode to a new 
KCurrency class using json files, and KCountry and KUnits should follow in due 
course to provide a future migration path for apps that need them.

Cheers!

John.

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel