Colour strings.
William Overington
Copyright 2002 William Overington
Tuesday 5 February 2002
In January 2002 I started a new thread in the discussion forum at http://forum.mhp.org entitled "Colour strings.". As it happened, no one else posted to that thread.
I thought that it might be interesting to add a transcript of that posting into this sequence of documents.
The postings are the text that appeared, except that I have corrected the spelling of the word isosceles. Unlike the corrected spelling mistakes of an earlier document in this series, this spelling mistake was not a keying error, but was as a result of how I had deliberately spelled the word. It was the automated spelling check for this document that brought the matter to my attention. This was then checked with a hard copy dictionary.
2002/01/16 21:31
In considering the ways in which one may indicate
routes to other parts of the program on display screens for an MHP
display using a Java program I have thought that with a minimum set
of input events that if one wishes to have the four colours as such
as on-screen indicators of such routes, then a programmer can only
have four such links.
Copyright 2002 William Overington
This file is accessible as follows.
I have therefore devised a software
construct of a colour string, which in Java is just an ordinary
String variable. The idea is that route indicators could consist of
one, two or more small landscape format filled rectangles adjacent
to each other in a horizontal row left to right, with a small gap
between each adjacent pair of such landscape format filled
rectangles if a colour string contains two or more characters. The
idea is that the colour string would contain as many characters as
there are landscape format filled rectangles in the route indicator.
The characters could either be characters r g y b or could be
characters 0 1 2 3 or could be specially designated codes from the
unicode private use area.
In choosing a route a viewer would
choose a sequence of coloured buttons on the hand held infra-red
control device followed by a VK_ENTER event on the hand held
infra-red control device. It would be desirable, though not
obligatory, not to have two adjacent landscape format filled
rectangles of the same colour.
Whereas colour strings one
colour long would give four possibilities, colour strings two
colours long would give twelve possibilities where two adjacent
colours are not the same. Colour strings three colours long would
give thirty-six possibilities where two adjacent colours are not the
same.
Colour strings two colours long would probably be
sufficient for many applications. However, as the Java language has
facilities for directly testing two strings for equality, it would
even be possible to mix colour strings of different lengths on one
display if so desired with no great problems in the programming.
I am wondering quite what would be the situation for someone
who is red green colour blind and who tries to follow this system,
or even use an ordinary MHP display where red and green filled
squares are used as route indicators, so I wonder if it might be a
good idea to have a standard practice that where one is asked to
input a colour as a routing choice that if one pushes VK_ENTER
instead, then the coloured squares will change shape, so that the
VK_COLORED_KEY_0 shape stays as a filled square, the
VK_COLORED_KEY_1 shape becomes a filled lozenge, the
VK_COLORED_KEY_2 shape becomes a filled circle and the
VK_COLORED_KEY_3 shape becomes a filled triangle, namely an isosceles
triangle with a horizontal base, the point at the top in the centre
and the base of the triangle being the side that is unequal to the
other sides.
If that becomes a widely used standardized
programming practice on the DVB-MHP platform, then people who are
colour blind might get used to using its results, having firstly
learned, as a one time only exercise, which shape corresponds to
which colour button on the hand held infra-red control device.
William Overington
16 January 2002