SUMMARY There seems to be pretty strange behaviours with unit converter. STEPS TO REPRODUCE 0: Open KRunner 1: Type 1 sqft 2: Type 1 sq ft 3: Type 1 ft^2 4: Type 1 m^2 5: Type 1 sqm 6: Type 1 sq m 7: Type 1 ' 8: Type 1 " 9: Type 1 ' 1 " 10: Type 1 ft 11: Type 1 in 12: Type 1 ft 1 in OBSERVED RESULT Does not invoke unit converter: 1, 3, 5, 6, 9, 12 Invokes unit converter: 2, 4, 7, 8, 10, 11 Specially, Case 7 will only gives out results about angles (interpreted as arc minutes), not lengths (as feet). EXPECTED RESULT All should invoke unit converter, maybe except 5 and 6 as I do not see these being used. Case 7 should also give out results about lengths. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: 5.19.5 (available in About System) KDE Plasma Version: 5.19.5 KDE Frameworks Version: 5.74.0 Qt Version: 5.15.1 ADDITIONAL INFORMATION
Thank you for the bug report. I will reassign this to the kunitconversion framework, this is where the units are provided. I will look into fixing some of the mentioned issues(like 1:), but I am no expert regarding the backend ;) >12: Type 1 ft 1 in This seems like a special case: You are basically saying: Give me results for 1 feet + 1 inch if I understand correctly. This is currently not supported, because it would need some "preprocessing" before calculating the result units.
(In reply to Alexander Lohnau from comment #1) > Thank you for the bug report. I will reassign this to the kunitconversion > framework, this is where the units are provided. > > I will look into fixing some of the mentioned issues(like 1:), but I am no > expert regarding the backend ;) > > >12: Type 1 ft 1 in > > This seems like a special case: You are basically saying: Give me results > for 1 feet + 1 inch if I understand correctly. This is currently not > supported, because it would need some "preprocessing" before calculating the > result units. Thank you. For the + thing it is actually described on wiki: https://userbase.kde.org/Plasma/Krunner#Calculator But `= 1 ft + 1 in` does not work, and none of the examples there actually work.
As a side note, I remember that at least `1 sqft` worked in the past. This might be a regression.
What you mean in the docs is a completely different component, that is the Qalculate engine of the calculator runner. Do you have it enabled? Maybe your distro build didn't come with qalculate... PS: The docs are from KDE4, so not up-to-date.
In general I thing we would need a better system here than hardcoding these strings :/ The pattern seem really repetitive with the "sq" or "²" pre/postfixes. Otherwise we would also need to fix a lot of other bugs. For example "1sq in" works, but "1sqin" does not work. But theoretically that should work too, right?
(In reply to Alexander Lohnau from comment #4) > What you mean in the docs is a completely different component, that is the > Qalculate engine of the calculator runner. Do you have it enabled? Maybe > your distro build didn't come with qalculate... > > PS: The docs are from KDE4, so not up-to-date. Thank you for that information. I have looked up the source code at https://invent.kde.org/frameworks/krunner but cannot find anything about qalculate, is there an option to enable it?
These things do not work: input (convert to) 115º (2 rad) 3º15’ (3.25º) π rad (180º) 100ºF (38ºC) 100 ha (1 km²) 1 rt (100 ft³) 2023-01-07 (Jan. 7th, 2023) (Julian Dec. 25th, 2022) (Dec. 25th, 2776 AVC) nautical units are unsupported local units are unsupported (under Polish locale: 1 q = 100 kg, 1 KM = 1 hp) 1 Hg is accepted and treated as 1 hg (?!) 1 KM is accepted and treated as 1 km (?!) 800 mm Hg is not accepted (800 mmHg) Note: 2 ft 3 in does not work but 30′0″ is handled by the calculator and evaluates to 9 m (why not 0.5º?) I admit that AVC may be too tricky because the year number shifts on Apr. 21st XD