FE 'tkGooie' Utilities

---

'SELECTOR/CONVERTER-tools' group

---

tkSpeedConvertSelect

(where speeds may be miles-per-hour,
kilometers-per-second, inches-per-year,
centimeters-per-decade, etc.
--- huge or tiny)

(FE = Freedom Environment)

FE Home Page > FE Downloads Page > FE 'tkGooies' Description Page >

FE 'tkGooies' 'SELECTORtools' Page > This Page

INTRODUCTION to 'tkSpeedConvertSelect'

I was planning (in 2016-2017) to make some Tcl-Tk GUI's for converting various kinds of quantities (distances, areas, volumes, weights, densities, speeds, etc.) from one specified unit-of-measure to another.

In August 2017, I published the first of these Tk GUI's --- a tkDistanceConvertSelect Tk script --- and soon after that a tkAreaConvertSelect Tk script and a tkVolumeConvertSelect Tk script and a tkWeightConvertSelect Tk script.

One of my main goals in creating these 'convert' GUI's is to support conversions over a very wide range of values. For example, for distances, I wanted to be able to support converting distances that may be astronomically huge (for example, distances up to the diameter of the 'observable' universe, in light-years or whatever) or distances that may be microscopically small (for example, distances at the sub-atomic level, in nanometers or whatever).

To do this, I wanted to allow the user to specify the 'convert-from' distance in 'scientific notation' --- a decimal coefficient and a base-10 exponent (an integer).

And the 'convert-to' distance was also to be expressed in 'scientific notation'.

This is in contrast to the tkSpeedGun utility I wrote in 2013, which was intended to convert between kilometers-per-hour and miles-per-hour --- with the intention of handling a restricted range of speeds --- like those encountered by a tennis ball in a tennis match. That utility had the luxury of knowing that the speeds would be numbers in the range of zero to a maximum of about 300 (or 1000 or whatever) --- in increments of about 0.1.

Instead of dealing with a range of values FROM about 0.1 TO about 10-to-the-3rd, I wanted to deal with values in the RANGE of about 10-to-the-minus-80 TO about 10-to-the-plus-80.

Using the tkWeightConvertSelect Tk script as a starting point, I decided to code this 'speed converter' utility --- and, like the distance, area, volume, and weight 'converter' 'tkGooies' utilities, allow it to be a 'selector' utility also, in the sense that a specified speed (in the specified units) could be written to 'stdout' --- by a click on a button of the GUI.


Speed versus Velocity

For this utility, the term SPEED is used rather than VELOCITY, because, strictly speaking, 'velocity' is a 'vector' and we are doing 'scalar' calculations. We imagine that we are dealing with 'linear' distances rather than 'curvilinear' distances and paths.


Distances and Times   (a huge number of combinations)

Speed is a RATIO of distance-over-time. If we imagine allowing for 10 different units-of-measure for 'distance' and 8 different units-of-measure for 'time', this results in 10 x 8 = 80 different units-of-measure of speed to choose from.

If --- like in the 'tkGooies' for converting distance, area, volume, and weight --- we allow only ONE listbox for selecting the units-of-measure for speed, the user could be dealing with a very long list.

To avoid a long list of speed units-of-measure, I decided that the speed-convert GUI would allow the user to pick a pair of speed units (numerator and denominator) --- from units in TWO 'listbox' widgets. So ...

Rather than using a single listbox with about 80 entries (or more), we use TWO listboxes --- a 'distance' listbox and a 'time' listbox --- with about 10 to 20 entries each.

Examples of distance units: inches, feet, yards, miles, kilometers, meters, centimeters, millimeters, micrometers, nanometers, light-years, etc.

Examples of time units (alphabetically): century, day, decade, hour, microsecond, millisecond, minute, second, week, year --- and more.


Range of sizes   (huge and tiny speeds)

This converter is intended to be able to convert speeds chosen from a huge range of sizes: speeds on the order of a a lightyear-per-year (the speed of light ; the theoretical maximum speed of any entity) --- or faster --- to extremely slow speeds, on the order of a micrometer-per-century or slower.

Estimates of the diameter of the 'observable' universe are on the order of 1.0 times 10 to the 11th lightyears --- which is about 10 to the 27th meters. Imagine traversing the diameter of the 'observable' universe in a second. Even though this is theoretically impossible, this GUI allows for dealing with speeds like 10 to the 27th meters per second.

Similarly for extremely small speeds.

Estimates of the diameter of a hydrogen atom are on the order of 1.0 times 10 to the -11 meters. And the size of a subatomic particle is at least 1000 times smaller --- so less than 10 to the -14 meters.

This GUI can deal with speeds encountered by traversing the diameter of a subatomic particle in a century or more --- where a century is about 3 times 10^9 seconds.

Traversing 10^-14 meters in 10^9 seconds is a speed on the order of 10^-23 meters per second. This GUI is meant to handle such extremely slow speeds.

In order to be able to handle such huge ranges, in the various units, the GUI allows for specifying the speed (in either of the pair of user-selected units) in 'scientific notation':

   a COEFFICIENT (for example, between 1.00000000 and 10000.00000000)
and
   an EXPONENT (an integer, assuming a 'base' of 10).

And the exponents we want to be able to handle are on the order of about minus-100 --- to plus-100 --- including zero.


THE GUI DESIGN

Following a Tk GUI design procedure that I started using around 2015, I laid out a 'text-sketch' of a proposed layout for the GUI.

In the below sketch of the GUI:

  SQUARE BRACKETS indicate a comment (not to be placed on the GUI).
  BRACES          indicate a Tk 'button' widget.
  A COLON         indicates that the text before the colon is on a 'label' widget.

  UNDERSCORES     indicate a Tk 'entry' widget (if any).
  CAPITAL-O       indicates a Tk 'radiobutton' widget (if any).
  CAPITAL-X       indicates a Tk 'checkbutton' widget (if any).
  <----O---->     indicates a horizontal Tk 'scale' widget (if any).

The options available to the user are indicated by the following 'sketch' of the GUI:

 FRAMEnames
 VVVVVVVVVV
                    -----------------------------------------------------------------------------------
                    tkSpeed - Converter/Selector
                    [window title]
                    -----------------------------------------------------------------------------------

  .fRbuttons         {UseIt} {Cancel} {Help} {Calc 2from1} {Clear2} {Calc 1from2} {Clear1}

  .fRmsg             [.... Messages to user are displayed in a label here ...............................]

  .fRleft                                                             .fRright
  [The sub-frames below are                                           [The 2 scrollable listboxes below
   in this '.fRleft' frame.]                                           are in sub-frames --- '.fRdist' and
                                                                       '.fRtime' --- in this '.fRright' frame.]

                                                                      |----------------A |----------------A
  .fRleft.fRunits1   Units1:[selected units displayed here] O units1  | centimeters    | | century        |
                     [in 2 text widgets separated by a 'per' label]   | feet           | | day            |
                                                                      | ...            | | ...            |
  .fRleft.fRvalues1  Coefficient: ___________  Exponent: {+}___{-}    | inches         | | decade         |
                                                                      | ...            | | ...            |
  .fRleft.fRunits2   Units2:[selected units displayed here] O units2  | kilometers     | | hour           |
                     [in 2 text widgets separated by a 'per' label]   | lightyears     | | ...            |
                                                                      | ...            | | ...            |
  .fRleft.fRvalues2  Coefficient: ____________ Exponent: {+}___{-}    | meters         | | ...            |
                                                                      | miles          | | minute         |
                                                                      | ...            | | ...            |
                                                                      | nanometers     | | second         |
                                                                      | ...            | | ...            |
                                                                      | yards          | | year           |
                                                                      |<-------------->V |<-------------->V


[Since the lists of units-of-measure for distance and time could get rather long,
 we put the units-of-measure in the 2 listboxes in alphabetical order --- so that
 the user can rather easily locate a specific unit-of-measure.]

---

GUI components:

From the GUI 'sketch' above, it is seen that the GUI consists of about

   - 11 button widgets
   -  9 label widgets
   -  4 text widgets
   -  4 entry widgets
   -  2 listbox widgets
   -  2 radiobutton widgets (1 pair on 2 separate 'units' lines of the GUI)
   -  0 checkbutton widgets
   -  0 scale widgets


For this speed-convert GUI, I would need to use an 'edit_inputs' proc to check on decimal and integer values that a user puts in the 4 'entry' widgets. A slight modification of the 'edit_inputs' proc of the tkWeightConvertSelect Tk script would suffice in this 'speed convert' script.


SCREENSHOTS of the GUI

I set to work converting the 'tkWeightConvertSelect' code to this proposed 'speed-convert' GUI, and I ended up with the GUI seen in the following image.

This is the GUI as it appears on startup --- the 'Units2' coefficient entry widget is empty and the 'Units2' exponent entry widget is also empty.

'Units1' is initialized to 'miles' per 'hour' and 'Units2' is initialized to 'kilometers' per 'hour'. And the 'Units1' coefficient is initialized to 100.0 and the 'Units1' exponent is initialized to zero.

    These initial values can be easily changed by changing some 'set' statements at the bottom of the script, in the 'Additional GUI Initialization' section.

At this point, the user can simply click on the 'Calc 2from1' button to have the conversion of 100.0 'miles/hour' to 'kilometers/hour' performed --- with the result showing in the 'Units2' coefficient and exponent entry widgets.

In fact, for the following image, I did that --- except for changing the 'Units1' exponent to 6 before clicking on the 'Calc 2from1' button. The 'Units2' values showed up with an exponent of 6.

I decided to click on the '-' (minus) button on the left of that 'Units2' exponent until I reduced the exponent to zero. Then I captured the following image.

---

Note that '-' and '+' buttons appear on either side of the 2 exponent entry fields.

After implementing the 'tkDistanceConvertSelect' GUI and trying it out, I found that it would be advisable to allow the user to adjust the 'scientific notation' to a combination of coefficient and exponent that would be most 'meaningful' to the user.

So the four '+' and '-' buttons were added to the GUI --- along with proc's to adjust a coefficient and exponent pair for each click on one of the buttons.

Each click adjusts the exponent up or down one unit while moving the decimal point appropriately in the coefficient.

---

The message ('advice') area on the GUI lets the user know that the unit-of-measure for 'Units1' and 'Units2' can be changed by using the 2 radiobutton widgets on the GUI --- in conjunction with the TWO listboxes. After clicking on one of the 2 radiobuttons, the user selects a 'speed' unit-of-measure by a click on a line in EITHER or BOTH of the two listboxes.

---

For the 'Selector' function of this utility:

If this converter-selector utility is embedded in another 'app', such as a shell script or another Tcl-Tk script, the 'UseIt' button can be clicked to send the two sets of units-coefficient-exponent to 'stdout' --- so that the calling script can use the entered data and/or the calculated data.

An example of how the 'stdout' text can be captured in a script variable is shown in comments near the top of the script.


The 'Help' button on the GUI provides rather complete and detailed help for using the GUI. A proc named 'popup_msgVarWithScroll' presents the Help text in a popup window.

Anyone who implements this script can easily change the Help text, which is defined in a 'set' statement near the bottom of the script.

There is a section in the 'HELPtext' variable that suggests how to deal with special speed units-of-measure --- such as 'knots' and the speed-of-light and the speed-of-sound.


DESCRIPTION OF THE CODE

Below, I provide the Tk script code for this 'tkSpeedConvertSelect' utility.

I follow my usual 'canonical' structure for Tk code for this Tk script:



  0) Set general window & widget parms (win-name, win-position,
     win-color-scheme, fonts, widget-geometry-parms, win-size-control,
     text-array-for-labels-etc).

  1a) Define ALL frames (and sub-frames, if any).
  1b) Pack   ALL frames and sub-frames.

  2) Define & pack all widgets in the frames, frame by frame.
              Within each frame, define ALL the widgets.
              Then pack the widgets.

  3) Define keyboard and mouse/touchpad/touch-sensitive-screen action
     BINDINGS, if needed.

  4) Define PROCS, if needed.

  5) Additional GUI initialization (typically with one or more of
     the procs), if needed.


This Tk coding structure is discussed in more detail on the page A Canonical Structure for Tk Code --- and variations.

This structure makes it easy for me to find code sections --- while generating and testing a Tk script, and when looking for code snippets to include from other scripts (code re-use).

I call your attention to step-zero. One new thing that I started doing around 2014 is using a text-array for text in labels, buttons, and other widgets in the GUI. This can make it easier for people to internationalize my scripts. I will be using a text-array like this in most of my scripts in the future.

All the 'set' statements for the text array, 'aRtext', are in one contiguous section toward the top of the code.


Experimenting with the GUI

In all my scripts that use the 'pack' geometry manager (which is all of my 100-plus Tk scripts, so far), I provide the four main pack parameters --- '-side', '-anchor', '-fill', '-expand' --- on ALL of the 'pack' commands for the frames and widgets.

That helps me when I am initially testing the behavior of a GUI (the various rectangular widgets within it) as I resize the main window.

In this particular GUI, I have chosen to allow the window to be re-sized --- so that the TWO listboxes can be re-sized easily by 'pulling' on the lower-right corner of the GUI.

I also used '-fill x' and '-expand 1' for the two coefficient entry fields so that those fields will expand if the user x-expands the GUI window.

However, one could un-comment the statement

   wm resizable . 0 0

to make the window fixed at its initial size.

With the window resizable, you can experiment with the '-side', '-anchor', '-fill', and '-expand' parameters on the 'pack' commands for the various frames and widgets --- to get the widget behavior that you want.

---

Additional experimentation: You might want to change the fonts used for the various GUI widgets. For example, you could change '-weight' from 'bold' to 'normal' --- or '-slant' from 'roman' to 'italic'. Or change font families.

In fact, you may NEED to change the font families, because the families I used may not be available on your computer --- and the default font that the 'wish' interpreter chooses may not be very pleasing.

I use variables to set geometry parameters of widgets --- parameters such as border-widths and padding. And I have included the '-relief' parameter on the definitions of frames and widgets. Feel free to experiment with those 'appearance' parameters as well.


Some features in the code

There are plenty of comments in the code, to describe what most of the code-sections are doing.

You can look at the top of the PROCS section of the code to see a list of the procs used in this script, along with brief descriptions of how they are called and what they do.

Here is a quick view of how each of the procs are 'triggered'.

   'listboxD_select_units'   - called by a button1-release binding on the 'listboxD' widget.

   'listboxT_select_units'   - called by a button1-release binding on the 'listboxT' widget.

   'speed_update'            - called by the two 'Calc' buttons.

   'adjust_values1'          - called by the '+' and '-' buttons for exponent1.
   'adjust_values2'          - called by the '+' and '-' buttons for exponent2.

   'clear_values2'           - called by the 'Clear2' button.
   'clear_values1'           - called by the 'Clear1' button.
 
   'edit_inputs'             - called by the 'speed_update' proc.
   'decimal_check'           - called by the 'edit_inputs' proc.

   'put_vars'                - called by the 'UseIt' button.

   'advise_user'             - called in the 'Additional GUI Initialization' section
                               at the bottom of this script.  Could also be called by
                               some procs such as 'speed_update'.

   'popup_msgVarWithScroll'  - called by the 'Help' button and by the 'edit_inputs' proc.


It is my hope that the copious comments in the code will help Tcl-Tk coding 'newbies' get started in making GUI's like this.

Without the comments, potential young Tcler's might be tempted to return to their iPhones and iPads (and other equivalents) --- to surf the web to find out what Trump's wife, Melania, is wearing.

    In a comedian's radio show, I heard the comedian invent new versions of her name --- nicknames: 'Melanoma' and 'Mesothelioma'. Sounds like better names for Donald. Those names reflect what 'the Donald' is doing to clean-energy-development, national parks and lands, and cultural-diversity aspects of the USA.

    'The Donald' is bi-polar to the max. In a single speech in Arizona (in Aug 2017), he talks of loving everyone --- and, in the same speech, vents his hate on Mexicans and fellow Republicans and the part of the media other than Fox News. (He probably added his usual dose of hate for Obama and Hillary.)

    The people seen behind him at that Arizona speech were gobbling up whatever he was saying with glee --- as if they were at a holy-roller gathering. They are as bi-polar as he is.

    Everyone is bipolar to a certain degree --- but Donald takes it to the (upper) limit.

    RAGING-BULL to purring-pussycat to RAGING-BULL to purring-pussycat to RAGING-BULL to ......... It is exhausting trying to follow the hour-to-hour and minute-to-minute mood swings. Think of what his poor (rich) Cabinet is experiencing.

Hopefully the following code will help some people become Tcler's --- or better Tcler's.


THE CODE

Here is a link to CODE for the script 'tkSpeedConvertSelect.tk'.

With your web browser, you can 'right-click' on this link --- and in the menu that pops up, select an item like 'Save Link Target As ...' --- to save this file to your local computer.

Then you can rename the file to remove the '.txt' suffix. Make sure that you have execute permission set on the file --- in order to execute the script.


SOME POTENTIAL ENHANCEMENTS:

Several possible enhancements come to mind:

  • Format of the decimal (coefficient) output:
    Currently, the 'precision' (number of decimal places) displayed in the output is hard-coded in a variable named 'FORMATforCOEF' near the bottom of the script, in the 'Additonal GUI Initialization' section.

    A widget (such as a 'scale' widget --- or an 'entry' or 'spinbox' widget, to be more compact) could be added to the GUI --- to allow for specifying the number of decimal places to be displayed in a computed coefficient.

      A sort of 'homemade spinbox' widget was made in an RGB Color Array Generator Tk script. It uses 4 small '+' , '++' , '-' , and '--' buttons on either side of a widget that displays the current integer value. The '++' and '--' buttons allow for fast-incrementing of the integer.

    There are some loss-of-significant-digits issues that arise on a coefficient when clicking on a '+' exponent-button of the distance/area/volume/weight/speed convert 'tkGooies' a large number of times. Some of these problems may be handled by allowing the user to set the 'precision' of the two decimal coefficients.

  • More distance and time units:
    Some other distance and time units could be added.

    Examples of additional distance units:

    • fathoms
    • furlongs
    • leagues
    • dekameters
    • hectometers
    • megameters

    Examples of additional time units:

    Each new unit-of-measure added would require adding 3 new setting statements near the bottom of the script, in the 'Additonal GUI Initialization' section. Example for distance:

        .fRrigh.fRdist.listboxD insert end "fathoms"
        set aRcoefD(fathoms/meter) [a decimal number goes here]
        set aRexpD(fathoms/meter) [an integer goes here]
        
  • Change the underlying conversion method:
    I have used the 'aRcoefD' and 'aRexpD' arrays to hold conversion factors based on using 'meter' for a common distance-unit-of-measure to which all the other units-of-measure for distance are 'tied'.

    And I have used the 'aRcoefT' and 'aRexpT' arrays to hold conversion factors based on using 'seconds' for a common time-unit-of-measure to which all the other units-of-measure for time are 'tied'.

    There may be precision errors that are revealed in this approach --- depending on the accuracy of the coefficients used in the 'aRcoefD' and 'aRcoefT' arrays.

    For example, with the tkDistanceConvertSelect Tk script, converting 1 'mile' to 'feet' may yield a value like 5279.99993402 instead of 5280.

    Various techniques might be used to eliminate 'hiccups' like this. But ... since this utility does essentially all of what I had hoped that it would do, I prefer to go ahead and release the code rather than spending more time trying to deal with precision (or rounding) issues.

    NOTE:
    The conversion factors that I put in the 'aRcoefD', 'aRexpD', 'aRcoefT', and 'aRexpT' arrays may not be to the precision required to answer certain user questions. In fact, there may be some gross errors in one or more of these conversion factors. Testing should be done to determine if the accuracy of these factors is suitable for a particular application. The user of this code may have to change these factor values as needed. (Or some users may wish to change the technique --- in proc 'speed_update' --- used to perform the conversions.)

  • Better ways of avoiding 'mismatched' values showing in the 4 entry fields:
    In this Tk GUI script, I have implemented a couple of ways to reduce the likelihood of the GUI displaying units1-coefficient-exponent values not equal to the units2-coefficient-exponent values ---

    • in the BINDINGS section of the code, and
    • in the 'listboxD_select_units' and 'listboxT_select_units' procs.

    In the BINDINGS section, the 4 entry fields have <KeyPress> bindings so that if a user is changing coef1 or exp1, then coef2 and exp2 are 'cleared' because the 2 speeds (expressed in 2 different units-of-measure) are probably not going to be equivalent.

    And vice versa --- that is, if a user is changing coef2 or exp2, then coef1 and exp1 are 'cleared' because the 2 speed triplets (units1-coef1-exp1 and units2-coef2-exp2) are probably not going to be equivalent.

    In the two 'listbox*_select_units' procs, coef1-and-exp1 is 'cleared' if the user changes 'units1' and 'coef2' is non-blank --- and coef2-and-exp2 is 'cleared' if the user is changing 'units2' and 'coef1' is non-blank. This is to reduce instances of the 2 speed values not being equivalent --- due to a units-of-measure change.

    In addition, the 'Clear2' and 'Clear1' buttons allow the user to 'manually' clear coef2-and-exp2 and coef1-and-exp1, respectively.

    There might be better ways to achieve the goal here of eliminating the display of 'mismatched results'.

Since I have not used this script for a large number of tests over widely varying speed magnitudes, there are probably some other enhancements that may be suggested by futher usage.

If I ever find that I am using this utility and I find that any of the features above are highly advisable to add or change (or implement in a different script), then I may return to this script to add/change/implement that feature.

Some additional ideas to include in this Tk GUI may be inspired by various on-line speed converters on the internet, such as


IN CONCLUSION

As I have said on quite a few other Tcl-Tk code-donation pages on this site ...

There's a lot to like about a utility that is 'free freedom' --- that is, no-cost and open-source so that you can modify/enhance/fix it without having to wait for someone else to do it for you (which may be never).

A BIG THANK YOU to Ousterhout for starting Tcl-Tk, and a BIG THANK YOU to the Tcl-Tk developers and maintainers who have kept the simply MAH-velous 'wish' interpreter going.

Bottom of the page for tkSpeedConvertSelect --- a utility in the FE 'tkGooies' system, in the 'SELECTOR/CONVERTER-tools' group.

To return to a previously visited web page location, click on the
Back button of your web browser a sufficient number of times.
OR, use the History-list option of your web browser.
OR ...

< Go to Top of Page, above. >
< Go to FE 'tkGooies' 'SELECTORtools' Page >
< Go to FE 'tkGooies' Description page >
< Go to FE Home page. >

This FE web page was created 2017 Sep 01.

If I ever post a copy of this code on the Tcler's Wiki site (wiki.tcl.tk) ---
as a backup and alternative to this page, I plan to put a link to that page here.