Message-ID: <8499950a0804242134i16747008yd49bf15782c318bd@mail.gmail.com> Date: Fri, 25 Apr 2008 05:34:56 +0100 From: "Oleg Verych" <olecom?ENOMSG@gmail.com> To: "GCC for MSP430 - http://mspgcc.sf.net" Subject: keyboard and pointer devices (Re: super-macro intention description language) > > But maybe I'm missing the point. My programming keyboard has exactly two > > keys, a zero and a one. I don't need as, gcc, ld, gdb, etc. Everyone can > > program this way - the trick is to just get down and be `one' with memory. > > I can't resist replying that a colleague of some years ago made his first > micro-processor system with a keyboard of just two keys - '0' and '1'. After all those iphone, multi-touch pads, touchpads, trackballs, mouses, keyboards are still here. Note: what i will propose is for most computer users: * word processing * programming * others i.e who don't need precision pointing. Some engineers (drawing, architects, geography, etc.) and gamers require big sensitivity and precision. So, think about keyboard as a big touchpad with logarithmic step size and floating coordinate frame start. For example. You need to move pointer to some place on the screen. So, first keypress defines coordinate start, this is start of the vector (key can be held). Then you press other key on needed distance as you feel it can point to your location. If you missed, next key(s) to this can make smaller steps to chosen direction. Start is remembered until next long keypress or key+other key. Even in text-input widgets long keypress is odd, double keypress is oddly odd. If you want to type loooooooooooooooooooooooong sequence, use vectors! GUI box model. Any dialog/window has widgets as boxes (name it). Example, don't use Alt+(what crap?) to focus, use described vectors on keyboard. Buttons like OK, cancel, default, any other are not bound to the ESC, enter, or ALT+?, but they bound to places on keyboard, that you see inside window box. Again, big distances can be stepped by successive logarithmic stepping, even if this is one hand. + dynamic keybinding (key macros), where user can define/remember keys (or vectors) for any application, set of windows, just windows. IMHO this is pure software task of representing keyboard to OS/application. I think this is cool idea. Who tried to implement or think about such? Programmers? I have another ideas of using this kind of keyboard in ordinary command line. Command line, that was on 70s and still alive today. To use it more effectively and have text user interface (not windowed or boxed) more flexible and smart. (but no one is interested in it here, isn't ?:) -- sed 'sed && sh + olecom = love' << '' -o--=O`C #oo'L O <___=E M
Same when i was a kid.
As with crappy XML here, i had questions, when i was a kid.
Why i can't turn wheels in truck simulator game gradually, with different speeds by keyboard? E.g.
Why i have to buy a wheel-joystick, pedals? Corrupted markes of vista-toastering corporations!
_____
making key-vectors (testing of idea; `sh` + `sed`)
Very first step -- input of vectors. Arrows as well as :alnum: keys can be pressed. Reference is 'd'(can be changed), exit is '`'. Scale is linear with k=4 (will be adjusted for every widget/box/window).
ftp://flower.upol.cz/upload/ised.sh
I wish `dd` or similar was a shell built-in. select()-like functionality in shell is the long due must. But how cares?
____
now ised.sh is kind of grid widget
now
ised.shis kind of file-list + file-pick grid widget. The first widget actually. I want it to be a replacement for inflexible standard TAB completion choice in shell. Now i need line editor or block editor of some kind.Run it in directory with some files and simple navigation:
When C coders tell you to not look into their source, it's kind of stupid situation. Here is the
`sed`, and code is indeed scary. Unmaintainable after few kilobytes, unreadable nearly after start.Now you will have the clue about my syntax highlighting and stupid text editors rants.
____