KPlotting and KUnitConversion

John Layt jlayt at
Tue Aug 12 16:54:49 UTC 2014

On 10 August 2014 23:20, Garret Wassermann <gwasser at> wrote:

> I am also curious who is the KUnitConversion maintainer as well.
> Similarly, unit conversion software would be fantastic,
> however it is missing many units and features.
> I would also be glad to work on either cleaning up KUnitConversion,
> or working on a replacement library. I believe I saw on the archives
> someone working on KStandards?
> What is the best way to get involved in the KStandards framework
> development? I will try to contact the person listed on KUC source code
> too but maybe it is more appropriate to post to the mailing list for
> feedback from everyone.

Hi Garret,

I'm the maintainer for KUnitConversion, you can find the maintainer in
the metainfo.yaml file in each Framework repo [aside: perhaps we need
to generate a page with this listed?].  I'm also the person looking at
KStandards, or KCodes as I'm now calling it.  For now KCodes will be
sticking to the ISO code support and not doing any unit conversion
stuff, that's a long way away if at all. At the moment I'm talking to
the Wikidata people about improving their ISO code data so we can just
become a consumer of their data, rather than having to maintain it on
our own. I'm hoping to have that resolved soon and will push the code
forward at that point.

KUnitConversion does have it's limitations which is why I'm thinking
about how to improve or replace it, but that won't happen any time
soon so it's best to keep improving it in the meantime.  The main
thing I dislike is every unit regardless of category being in a single
enum, which can lead to nonsense like trying to convert 1 meter in
degrees Celsius. That's a version 2 fix though, and in the meantime
there's other things to work on, like removing the dependency on ki18n
and using Qt tr instead. You say there are units and features you need
that we don't support?  The obvious place to start is to implement
those in the existing library so we understand them better if once we
get around to designing a new api.  The best place to discuss these is
always here on list, so can you say what it is you are missing?  Once
we've discussed any new features, you can then code them and submit
the patches to our ReviewBoard so I can review them.



More information about the Kde-frameworks-devel mailing list