Hi All,
The following was written before I watched Will's video. But I think most of it holds up. So I'm submitting it "as is" or "was."
The discussion now appears to be entering into a technical area beyond my comfort zone. Except for checking in once and awhile, and seeing if I can recruit others having needed expertise, this may be my last post on this thread.
Although I have always been driven curiosity about everything, shortly after WWII, when I was about 6 and TVs had yet to become mainstream, I took apart the family's radio. No one knew how to fix it and its replacement cost about a week's savings. To say the discussion which followed was not an encouragement of my tinkering with appliances would be euphemistic.
Now that I better understand the problem, at present I have only one thing to add. It will probably complicate things.
We are creatures of habit. Much --perhaps most of what we do, or at least how we do things-- is the result of our internalization of our culture's adaption to its environment, including the existent technology. We learn it, do it, it becomes the way we do it and, thereafter, we don't think about it. Having habits is efficient as anyone will attest who has had to wait while someone else tries to locate keys or eye-glasses “just left someplace.” But occasionally it does make sense to “re-invent the wheel.”
Use of the QWERTY keyboard is a cultural habit in English speaking countries. It, and probably every other keyboard, was designed for mechanical typewriters because it had quickly been discovered that people could press keys faster than the springs could return keys to their rest position. To avoid key-jamming keys for several of the most frequently typed letters were moved to awkward locations: that is, unable to speed up the action of the typewriter, they slowed down the action of the typist. When electronic typewriters and computer keyboards came about such hobbling of the typist was no longer necessary. But even the Dvorak keyboard –supposedly more ergonomic-- could not overcome our cultural adaption to QWERTY. Even on Smart-phones, where efficient typists use only their thumbs, the QWERTY keyboard is still deployed.
Except for those having to build it, I would suggest that the optimum solution in providing a keyboard for those limited to one-switch mobility would be to group the keys for the most frequently employed letters of the alphabet to the easiest to locate (first) position on a keyboard. The attached illustration began with that simple goal, but grew as other considerations came to mind. The order of the alphabetic keys is based on the work of Herbert S. Zim, as per Wikipedia: http://en.wikipedia.org/wiki/Letter_frequency. According to that source, the following constitutes the English alphabet in order of usage frequency:
ETAON RISHD LFCMU GYPWB VKJXQ Z
In that order, the first 8 letters are those employed 65% of time, and the first 12 constitute 80% of letter usage. The attached keyboard modifies that order to take into consideration factors:
1) per that source, the most frequent letter combinations, in order of their frequency are:
TH HE AN RE ER IN ON AT ND ST ES EN OF TE ED OR TI HI AS TO

Although the letter “E” is the most frequently used letter, I suspect it achieves that status not because English has many words which begin with “E” but, rather, because “E” is the most commonly used vowel. The letter “H” was moved closer to the beginning of the sequence to reflect how frequently it is used in letter combinations. The order of almost all of the other frequent letter combinations actually arises naturally from the sequence. I don't think Zim considered how often words are separated. But the manufactures of keyboards make the space-bar larger than the others and place it under your two strongest fingers. So I placed it in first position. The delete key was placed on the first row based on my experience attempting to type on a Smart-phone. My guess was that both the period/decimal point and comma are more frequently used that the letters which follow them on the proposed keyboard and I wanted to place them in close proximity to the number keys.

The keyboard is predicated on the assumption that it will be displayed and begin functioning as soon as the operating system has reached “desktop” and that without further intervention, at a given interval, cursor focus will scroll through the keys on the top row. Such scrolling is assumed throughout this suggestion, unless stated otherwise. That scrolling is taking place can be visually represented by changing the background color of the key then in focus. Consequently, to type a key all that is necessary is that the switch be pressed while focus is on that key. Note the “ChngInt” key at the bottom right. My guess is that what constitutes the proper interval may depend on both the individual and the extent of his/her practice with the keyboard. Pressing the ChngInt key will bring up a dialog box with three buttons: Keyboard, Mouse, Exit. Pressing Keyboard will bring up another dialog box showing the current speed and the choices +, -, Accept, Exit. Pressing Mouse will be similar, except that it will show the number of pixel for each standard move. Pressing Accept will bring up a dialog box with the choices Confirm, Return (to previous dialog), and Exit. Note the Mouse-fine button. Pressing it will reduce the length of a mouse movement to a small number (1?) per interval and the mouse movement will, thereafter, be so limited until Mouse-Off or one of the click buttons is pressed.

It should be apparent from the foregoing that I am talking about “re-inventing the wheel”. Doing so would require expertise (which I lack) with respect to keyboard codes, Mouse-Routines?, GUI design, and some programming. Can it be done by first deconstructing Magoo? Much of the programming can probably can be done using BASH. The suggested keyboard would require 98 buttons and, of course, a scrolling routine. You'll notice that the “Keyboard” is actually an array. As such, automatic scrolling and several other actions can be accomplished using imbedded Do-While loops, or their equivalent.

The following is an explanation of how the rest of the “keyboard's” functions. Up and Down do what you would expect, move the focus to the next higher or lower row, with Up5 and Up6 returning focus to Row A. [Row names and Column numbers are not part of the keyboard: present only to facilitate consideration and discussion]. Having rearrange the alphabet in a logical but as yet unfamiliar sequence, I've tried to group other keys where they're likely to be recalled through association with similar keys. So I've grouped the numbers and common math function keys together and in close proximity to the period/decimal-point and comma keys. Row F begins with the three Ms: Move, Mouse and Menu. An onscreen keyboard will on occasion be in the wrong location: ergo Move. Mouse, will shift focus from the cursor to the mouse-cursor. And Menu will shift focus to the start button of the menu. The meaning of Left, Right, Up and Down should be obvious, although the subroutines they invoke will differ depending on which of the 3 Ms were pressed.
Prior to the prevalence of the mouse there were both word-processing and web-browsing software that could be completely controlled using the “directional tabs” --i.e. Right, Left, Up and Down. I don't know of any today. But if there are, because of the limitations of operating a mouse via a single-switch, it would be better to use such software and abandon the mouse in favor of “directional tabs.”
The “o/o” appearing in some cells indicates an on-off toggle. In addition to Suspend (or hibernate whichever is better) and shutdown the keyboard has a “pause” toggle. Invoking it will simple pause cursor and mouse-cursor movements until it is pressed again. Everyone needs to take a break once in awhile.
The bottom row contains word-processing functions. Depending on the software used –not just word-processing software-- directional tabs could be preferable.
Once the groupings of keys likely to be used in conjunction with each other had been laid out, I filled empty cells with functions I thought might be useful, such as the pause toggle. The volume button would initiate a module to increase/decrease speaker volume. I thought a “Seek Help” key might be of value: pressing it would set volume to maximum and initiate an appropriate call for attention. Lastly, the function key (func o/o) could invoke a number of hot-key actions such as func-o to open, func-s to save. Pressing it would return the cursor to the first row and invoke a subroutine which would respond to the press of a key on a defined list (including func-o which would turn it off), ignoring any other press. Pressing the second key would seek confirmation, then turn off func and initiate the called for action.

As I mentioned previously, an inherent problem with onscreen keyboards is they will occasionally obscure something on the screen. A better solution would be to reserve space across the bottom (or top) of the screen. Excluding the UP & Down keys of Columns 1 and 14, there are 86 keys. It would be frustrating and inefficient for a user to have to wait while the program scrolled through most of the keyboard before focusing on a desired key. So even if the keyboard were aligned across the bottom (top) of the screen, you still would want to divide the keys into groups with each group having its own panel/window and a mechanism for changing focus from one panel to another.

Can these people reliably tilt their chin forwards, backwards, left, and right, about a half-inch, without problems?

If this gets into pure software I'll have to bow out. I can probably learn arduino code, but even a linux shell script is likely beyond me right now (although I'll have a look if it becomes necessary).

EDIT: even tilting the chin 1/4 or 3/8 inch, would be enough... just need to be able to do it enough to bump into something is all._________________

Can these people reliably tilt their chin forwards, backwards, left, and right, about a half-inch, without problems?

If this gets into pure software I'll have to bow out. I can probably learn arduino code, but even a linux shell script is likely beyond me right now (although I'll have a look if it becomes necessary).

Starhawk, I think your hardware solution sounds awesome so I don't want you to think your efforts were in vain for a second.

It's just that the guys who get the shaft on computer access only have a single motion (that isn't even always predictable). So the only way to delineate it is by steps--move mouse, click mouse, wait for A, etc.

Imagine putting a 10kg-20kg weight around your neck and you could only interact if you could put the part in the right place....and you are disabled.

I previously indicated that I was able to obtain a functioning version of onboard in jejy69's lxpup-aptget-test by using its included synaptic to install the necessary debs. With onboard onscreen and geany opened clicking the onscreen keys sent the keys selected to geany which displayed them. I'm not certain, however, if onboard is entirely functional under lxpup-aptget. I called up its config module and turned on scanning. Thereafter, various sections of the keyboard were highlighted, but (1) selecting mouse as the keyboard device and checking "mouse only" froze the application except to allow pressing the Enter key to uncheck it and (2) after unchecking "mouse-only" clicking a key on the onscreen keyboard while in the scan mode no longer sent key-strokes to geany. Turning off that mode restored onboard’s communication with geany. Similarly, unless scanning was turned off, onboard did not communicate with either opera or firefox. Hopefully, that problem is simply because I don't really know how to configure onboard or can be overcome. Exploring onboard has overcome my concern that an on-screen keyboard would occasionally obscure other on-screen windows: its display can be dragged and resized so that it uses only space immediately above the taskbar. Although other windows may extend under that display, there's probably a workaround. Interestingly, when set to “grid” mode, onboard –although it then only displays a “reduced” keyboard and number pad-- appears to arrange the alphabetic keys in some variation of letter use frequency I discussed. I wonder if it's customizable?
Assuming the input problem is not a show stopper, onboard's problem of working with a mouse may be overcome by simply not. I know you youngsters may find it hard to imagine, but there was a time when mice were not only not attached to computers, computers didn't know what to do with them. It was the time of Dos. Apparently there's still enough of us old geezers that someone took the time to create the gleebox addon for Chrome (I think also usable in Chromium and Iron), http://thegleebox.com/, and the mouseless-browsing addon for firefox, https://addons.mozilla.org/en-us/firefox/addon/mouseless-browsing/. Some of opera's functions can be initiated by key-strokes but, unless I missed it, not all.

From a practical standpoint, that leaves only the urgent need for a mouseless wordprocessor. I naturally thought of Wordperfect 5.1 for dos and wondered if it could run under a dos emulator. So I downloaded the dosemu deb from Ubuntu and installed it. [Actually, I turned it into an SFS which, when loaded, successfully ran in any precise-pup, Lupu, Slacko and Exprimo, but not Carolina: missing lib]. I then downloaded and installed WP51 from http://www.oldversion.com/windows/wordperfect-5-1.
The attached screenshot is of WP51 running under dosemu in precise-aptget-test.
WP51 is a complete wordprocessor. It can also create table --small spreadsheets. Although it can use a mouse, all its functions can be called up via the menu or thru keyboard commands, using key-combinations. It can also create and use macros of commonly employed phrases and commonly undertaken actions. If I recall correctly, it can also create datafiles, but if not dataperfect can also be downloaded and used in conjunction with it. It’s been awhile, but for two years it was the program I used on a daily basis to write legal briefs and various correspondence. Both Wp51 and Dataperfect are now in the public domain. I’d also note that available from corel via its public files are modules to localize WP51 to most Western European languages. However, although onboard provides a full keyboard currently I have no way of testing whether in scan mode it would accept combination keys.
An alternative to WP51 is the text editor geany which I frequently use to jot down short (for me, probably long for others) notes and clearly sufficient for basic written communications. Although it does not do pretty things like change fonts and spell-check, it does have customizable key-bindings including a “snippet” function. But again the question arises whether Onboard in scan mode can handle combination keys.
And there’s the inimitable Vim which its users swear by but which is so robust that, suspecting a long learning curve, I’ve been hesitant to try. Perhaps it can be toned down?
Rounding out the picture, there are mouseless file-managers, and entire Linux Window-managers for which no mouse is required. Among them are “awesome,” “xmonad” and “ratpoison.” I don’t know whether any of these would work under even jejy69’s lxpup-aptget, or which might be the best for our purposes. On the other hand, if onboard in scan mode can handle key-combinations, as Start menus can be controlled via the directional keys once the Start icon is pressed, a key-binding to simulate that press may be sufficient with any Puppy's window-manager.

So, rather than trying to include mouse-usage, which at best would be frustratingly slow, why not avoid its use altogether.

I have found another free Windows webcam solution which, in parallel with this thread, you may want to check out. It looks really good, covering both mouse control and keyboard input purely with head/eye movements. Text to speech is also catered for.

Your mention of WP 5.1 brought back a lot of memories.
I used it for years in conjunction with an add-on (The A-Z of WordPerfect) which made it easier to use than Word. It was in essence a collection of macros covering all features. I may still have a copy on one of my archive CDs. Let me know if you wish me to check._________________Regards ETP
Pups inmy kennels.

forum member SFR has done some fantastic work developing a couple of scripts (attached below) that allow a Puppy to be fully controlled from a single keyboard switch. In their current form the scripts respond to the Pause/Break key that you have requested (and can initially be tested by anyone without having to disassemble the keyboard).

Unfortunately I have not used GOK or Onboard so I don't know if the script will suit your needs with those programs, but I have tested each of them with the xvkbd onscreen keyboard and the combination is very powerful.

The user only needs to run one of these scripts. Although they perform identical tasks they are visually different and it is up to the user to choose which best suits their needs/screen layout etc.

The scripts are as follows:

1) Radar6 places a small window at bottom right of the screen and contains a rotating line within a circle. The rotating line determines the direction that the mouse will travel, and the pause key determines the actions to be performed.

2) Navbar2 places a navigation bar across the top of the screen and uses 8 arrows to display the intended direction of mouse travel, and again, uses the pause key to control actions.

*** DO NOT RUN BOTH SCRIPTS AT THE SAME TIME ***

How does a single key control the actions? Both Radar and Navbar alternate between "choose direction" mode and "choose action" mode and the user simply presses the pause key when they see their preferred direction/action highlighted in the control window.

NOTE : SFR has done a lot of work to make these scripts perform well, but it is important to remember that there are many Pups, many browsers, and a variety of window managers to choose from. Your mileage may vary!! I have been testing with a small number of Pups, and will be testing more combinations, but my first recommendation is that Magoo (which is based on Precise) seems very compatible. There are screenshots below of Radar6 running on Magoo on my netbook. (obviously a bigger screen would suit most users...)

I will describe how I install Radar, but please note that I don't know a lot about the "right way" to do this. (I really don't know all the conventions about where things should go, and how they should be connected together, so I will describe what worked for me). I recommend that you try this script (or any new script for that matter...) on a fresh installation that does not contain important data. The script itself will not cause you any problems but if you are a bad driver and lose control of the mouse you have only youself to blame
If you want to trial Navbar instead of Radar you simply follow the same install steps.

1) Download the attached Radar6 (or Navbar) tar and extract it somewhere. Then place a copy of the extracted folder in /root
2) Click on the radar file inside that folder. You should see the radar window appear at bottom right of the screen. (It should appear on top of all other windows, but if not you may need to shrink other windows enough for it to be always visible)
3) Click the Pause key and you should see the mouse start to move in the direction shown by the radar screen. When you get to where you want to go just hit the pause button again and the radar screen will change to show you the actions you can choose. Just cycle through this process as required
Navbar is similar, but places the control window at the top of the screen so that it doesnt overlap maximised windows below it. At this stage I find radar a little easier to drive than navbar - but both have their advantages.

xvkbd
xvkbd is not a requirement for Radar or Navbar, but it will be a valuable add-on for most users. If the user wishes to type into a document or browser etc you can have xvkbd running in the background, then navigate to the taskbar, select the xvkbd tab (which will bring xvkbd to the front) then click the "focus" key on the xvkbd keyboard, click on the chosen program window, then start typing the text on the keyboard and it will appear in the desired document window. I don't know how xvkbd compares with Onboard but it seems to work well and I found it quite easy to adapt to.

8bit mentioned this post which details the installation and use of xvkbd:
http://www.murga-linux.com/puppy/viewtopic.php?p=261712#261712
I think the pet will install on most systems, but if not you can manually install the files: Basically you put the xvkbd file somewhere like /usr/bin and click on it when you want it running, or else you can put the file (or a symlink) into the /root/startup folder if you want xvkbd running as soon as Puppy is started.

Some systems also require the two extra libraries mentioned in that post to be added into /usr/X11R7/lib, and then it is necessary to add symlinks with the correct names that xvkbd is looking for. This only has to be done once.

Magoo : Magoo is not a requirement for Radar or Navbar - it just happens to be a Puppy that I like (targeted at vision-challenged or menu-challenged users) and it seems to work well with radar and navbar. It is available as an iso or a .pet
http://murga-linux.com/puppy/viewtopic.php?p=671472#671472

Now all that's required is to find someone to offer a service grafting 3.5mm mono connectors onto old keyboards so we can tap into the pause key with a footswitch/headswitch or whatever...

Yes. Really great work by SFR. No doubt with some encouragement and aiding and abetting by greengeek.

Add the following, per the xvkb site:
"Automatic Click
Set on/off of the automatic click feature and the delay before automatic click is activated. If this feature is set, xvkbd will work as if left mouse button is clicked when mouse pointer is moved on a button and stays long enough. You may want to set Jump Pointer? to OFF to avoid auto-repeating."

I haven't quite figured out how best to use magoo perhaps because I think Magoo-MK129 is broken. (Will email author). But in any event, geany text editor can be run mouseless. I've given up efforts to include WordPerfect for Dos via dosemu since, to make it compatible with Linux apps its native file format could not be used (readable only by LibreOffice, maybe OpenOffice) and if docs are saved as mere text it has little to recommend it over geany.
"A" Magoo modified to substitute geany and other "mouseless" apps would be a very useful interface for this project.
I'm still trying to figure out how to customize xvkb's interface so as to group the most commonly used letters of the alphabet in a pattern of close-proximity to reduce the necessary mouse movement and delay between desired letters. While xvkbd has built in functions to assignments for special keys, they don't handle "standard" keys. However, xvkbd itself must because in addition to the standard "US" keyboard, you can select already available keyboards as diverse as Dvorak or Korean. [The onscreen key must have a label indicating what letter will be sent to the target application, or function called, and "pressing" the key so labeled must have the desired effect]. I'll write to Tom Sato, xvkbd's creator, as soon as I've thought out a keyboard layout using xvkbd's design rather than the rectangular one of the previous illustration.

I'll write to Tom Sato, xvkbd's creator, as soon as I've thought out a keyboard layout using xvkbd's design rather than the rectangular one of the previous illustration.

I think it's a great idea to have an alternative layout of keyboard - those who do a lot of typing might find a real productivity boost if the keyboard had all those "couplets" that you listed on it. Why type one letter at a time when you could do it two at a time?

Maybe even a list of several alternative keyboard layouts? One for maths, one for science, etc etc

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum