On Thu, Feb 27, 2014 at 5:15 PM, John Layt 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
>
On 4 March 2014 15:59, Kevin Ottens 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://m
On Tuesday 04 March 2014 15:29:33 John Layt wrote:
> On 4 March 2014 09:25, Kevin Ottens 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?
> >
On 4 March 2014 09:25, Kevin Ottens 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.
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 "kde4sup
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, KGui
On 2 March 2014 19:58, Kevin Ottens 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
Hello,
On Thursday 27 February 2014 17:15:56 John Layt wrote:
> 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
> [: John Layt :]
> One thing I've noticed is that it uses KLocalizedString in public api and
> as internal storage, is this a normal way of doing things? I would have
> thought once the translation has been done that a QString should be OK for
> storage and api use?
Since KLocalizedString delays
On 28 February 2014 10:52, Chusslove Illich wrote:
>> [: John Layt :]
>> * 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.
>
> So far no lang
> [: John Layt :]
> * 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.
So far no language has any scripted translations here.
There should be n
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 releas
12 matches
Mail list logo
