I'd like to see the need for documentation reduced. Right now, if you don't have a hotkey list handy, you're dead. There's not much in the way of online help. And it's not always clear what state Blender is in.
For starters, a "hotkey" window type, with buttons for all the things you can do in the current mode, would help a lot. Users could either click on the displayed buttons, or just use it as a cheat sheet for the keyboard. Buttons should grey out (or disappear?) if not meaningful in the current context. Something in that window should show what state Blender is in, too.
That makes Blender much more accessable to new users, without forcing everyone into a different interface.
It also gets rid of the problem of out-of-date cheat sheets and books.
One very good idea... the first one that actually just completely makes sense... something easy and simple.
I would still love some way to change the keystrokes also...
Sounds cool - go for it!
There'll be a shortcuts list in the Blender Documentation as well - I shouldn't think it is too difficult to make an automatic convertor from DocBook XML --> C sources. In that way we could keep the documentation and the on-line help in Blender in sync.
Just an idea,
I'm waiting for the build process to work under MSVC before I try to do anything to the system. I'll definitely take a look at how hard this is to do.
It looks like "winqread3d" in "space.c" defines what the keys actually do, and in what state they do them.
Should be as easy as putting a text file into your default blend! You're not going to get "context sensitive" clicking working, since the context is often where the mouse is, and if its always in the hotkey window nothing much is going to happen.
In fact, why doesn't someone start a project to come up with a more sensible default blend than the current one? I spent ages on mine, could be uploaded at some point (loads of useful screen layouts).
Based on kid_tripod's idea..
Put documentation of interface into default blend file.
User could change the names for keys and such
You could have different associations for different languages
The executable might have a default set.
The executable should also be able to query itself for hotkeys so that
the environment at least will have bindings in the blend file for the hotkeys.
Extra: It would also allow you to determine if there are missing hotkeys between versions (by doing a check against a white-box testing blend file)