Display conversion ratio between units

[nswarup14]

Fixes #27

Kindly review

Tested on Ubuntu 18.04 and Sugar v0.114

[quozl]

Thanks. Briefly reviewed;

• [x] your check of length in _Conversion.settext seems without functional effect,
• [x] your call to _modifyfont (a) clutters the main function when it doesn't have to be there, and (b) does not use FONT_SIZE and so won't change when the Sugar font size is changed,
• [x] there are other changes that have not been explained, so I doubt you intended them; such as the change from file to open, and the refactoring of the code into _formatvalues,
• [x] the ratio is not displayed with a colon (:), but a tilde (~),
• [ ] the ratio is displayed as the result of a calculation of a unity measurement, but it is more conventional to explain unit conversion where possible as whole numbers; resolving the ratio into the lowest common denominator.

Could you please return to design stage and make a response on the issue to propose what is to be displayed? You seem to have jumped design and got right into coding how you think it should be solved.

[nswarup14]

@quozl Thanks for the inputs. I shall update the commit message with the all the changes I have done. Regarding the display changes, I shall do so in a new commit. Regarding the point of design, I shall comment on the issue.

[chimosky]

Tested 7d669a7.

When digital storage is selected, conversion ratio shown for byte as from unit and [Gigabyte, Megabyte, Petabyte, Terabyte] as to unit show [1e-09, 1e-06, 1e-15, 1e-12] respectively and this isn't user friendly. The reverse is also the case for Petabyte and Terabyte as from unit and Byte as to unit.

[nswarup14]

@chimosky Thanks.

I had not noticed this earlier but yes, the result displayed is of the form [1e-09, 1e-06, 1e-15, 1e-12]. The reason for it can be in the way the converted values are formatted by the activity, before displaying.

I shall investigate this further now

[quozl]

Thanks. Reviewed as-at 7d669a75ec758b31ea1e3becb88c828899827a43.

• [ ] your _settext function inside Conversion did nothing except call the parent class equivalent; and can be safely removed without functional change, fixed in 1b01a37,
• [ ] the name of the class Conversion was inconsistent with the name of the class Ratio, as both suggest each other, fixed in 4961bb2a1028beea7180886d343961c60df20aba and 35318c6341242d3e1008c71f4981c5d6cbfc54b4,
• [ ] there was a mix of private and public function names, fixed in 4cceb33c2b3f9fbf36e0aa654125af489f1160d3,
• [ ] much of the code added just before the calls to _update_conversionratio was repetitive, fixed in 3a8497cc0dcf8e3e070da626d00e860c85475972.

Briefly tested on Ubuntu 18.04 with Sugar master branch.

[drLite35]

Hi @quozl, Is there anything missing in this PR any reason not to merge it, I tested it seem to be working fine. Thanks.

[quozl]

Perhaps the last item in the first checklist needs doing? What do you think?

[drLite35]

Yes, Last task is not done, I didn't see it. Just an observation though , while I was testing/going through activity I didn't felt the need to know about representation in whole numbers, unitary conversion works best, but that might be due to me being comfortable with decimals. But what children and student are most familiar with is the real question, so for example if we take 1 inch = 2.54 cm so like was there any idea to alternatively represent this in form of fractions or any otherway because to me it looks more approachable and easy to understand.