> 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.
Hi John, Thanks for the info! I am new to much of this stuff, so let me ask a potentially dumb question -- what are the ISO codes? From past conversations I assume you mean switching between formats/currencies for different countries, but I would appreciate any elaboration so I understand what is going on and how to help better. Would unit conversions even go together with the ISO codes, or would they be better off split off as two different libraries? (perhaps KStandards for unit conversions and KCodes for ISO?) > 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 That bothers me as well. I am also bothered by what seems to be (from my admittedly quick look over the source code) a lack of extensibility. More below. > 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? A little bit of context -- I'm working on some academic software and think proper unit conversion would be a great help for some problems long term. I have done work with electricity/magnetism in past, but am currently working on a heat transfer project. Volts, Amperes, Ohms, Teslas and the like are missing, despite being regular SI units (although magnetism especially uses many CGS units, so this is where I think such a library may come in handy). >From heat transfer, more compound units such as a thermal conductivity (watt per meter-kelvin) are missing, and of course being able to translate between metric and the old BTUs would be nice. I am glad to start adding these units to play with the idea, but I think ultimately it shows a limitation of the current design. It is missing a few SI base units, and several categories of common units, and the thought of adding a new category for EVERYTHING out there seems a bit silly. A library that allows one to define new derived units in terms of base units and register them with the library would be really cool. it could be useful for anyone no matter how specialized the field, rather than having to update the library itself every time someone wants a new unit. I would also like to see a library that allows basic arithmetic with these units. Perhaps overloaded operators to allow one to add or multiply quantities and preserve the correct resulting units. Being able to for example set a = 2 kg, and b = 9.8 m/s^2, then type c = a * b and have the library know that c has the unit of Newtons now (or at least, know how to combine the units and show the resulting kg*m/s^2 and check that it is equivalent to a newton). It will be useful as a sanity check on my work, though I also see this being useful for more educational oriented software. Obviously this is my whole laundry list of ideas/interests. I am not sure what is feasible and what might be harder than I expect, but if we can bounce ideas around and settle on a path forward, I will be glad to contribute when I can! In the meantime, I can write up some basic classes for the extra units I currently need, and see how that fits into the library. Thanks for your help, Garret _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel