What are the typical size ranges of widgets in the application running at comfort level? Four, exactly. Four is a balanced binary selector, it represents two bit precision, and at comfort level the human is two bits. We know it is two bits because the user, at comfort level, pays the least amount of attention to her hand. At work, in front of the screen, on hr butt, the legs have a one bit configuration. The typical velocity setting the human delivers via the mouse will be two bits.
The two hands on the keyboard are more like a four digit, most reasonable keyboards users, at comfort, can select about 16 of the most common keys, they hunt and peck the rest. But I don't care, Sam Morse and Mr. Ascii already encoded the key board.
How complex is the screen relative to the application? About twice as complex, and the user pays closer attention when moving from window to window i she adopts more setting for n instant, the large jump settings. This is all a direct result of Fitt's law, take a look.
Consider the computer graphics tool, design app. The graphics way more complex, so the user has to zoom in on a particular region, get the widget sizes large enough the she can more about with two bit velocity settings.
No brainer, we can make the mouse match the applications and always keep the user happy. This is all hand ey,e X windows has nothing ot add, it knows nothing about application complexity or zoom. The application knows everything, and it is in user space, and that is where mouse tracking belongs.
The new system with independent, user space mouse tracker allows each application to select he tracking complexity and speed. Any given editor, for example, should have a drop down menu to choose a mouse manager. In some cases, like spreadsheet, we will deliberately use a low complexity cell quants. Then the serious draw apps will want more hand eye, they will expect the professional to maintain five to seven velocity settings. Then some users will just want a damn good, adaptable Huffman encoder tracking system.
Am I doing this with IO manager?
No, still massaging that code to operational, I posted a copy. I am using a fixed point, zero order predictor based on weighted sum of current and past. Works fine for console loop, it has few movements to worry on a command line; it is all keyboard. Bur console loop running in a rect needs to track it at low rate to determine when the rect is in focus. Simple enough, drop tracking speed to half a second, when the x about y are close enough, increase tracking rate to a quarter, then wait for the user to click when when user and tracker are in sync.
No comments:
Post a Comment