Support for additional keys in keybindings should be manageable. Any suggestions? (Special characters, like '[' and '{', would be more of a challenge, but the mousewheel and F10-F12 should be simple enough.)
Edit: The mousewheel appears to use SDL_MouseButtonEvent, which makes combinations with modifier keys difficult to handle.
Given the dicussion of international keyboard layouts earlier, it's pretty clear it won't be easy to satisfy everyone.
Unfortunately, for US style keyboards it's precisely the [/{ and ]/} keys that are one of the best pairs for a second zoom up/down pair that TwbT needs with minimal finger reaching and DF doesn't use them for anything. Non-US keyboard styles will want something else.
Since such a zoom is frequently used and one may be almost anywhere in DF when you want to use it, it's hard to find *any* alpha keys that won't conflict somewhere.
Function keys require an extra reach which isn't what you want for such a frequently used operation, though they are good for less frequently used actions - especially with modifier keys so they don't conflict with DF Hotkey locations.
I guess the best answer is 'everything you can support reasonably'. No one would complain about being able to use *every* key, but will settle for as much as you can give.
As many punctuation and 'special' keys as possible. All the shifted numeric row symbols. It's likely that even stuff like 'insert', 'delete', 'home', 'end', 'page up', and 'page down' may be useful to plugin writers and people wanting to bind command lines to keys as well - as they avoid alpha key conflicts.
It may also be useful to be able to tell DFHack to eat a bound keystroke and not send it on to DF after acting on it. Something like a flag/parameter that says eat this keystroke after you recognize it on the keybind command line setting up a bind.
This would allow people to say "I never use '.' One-Step or ';' Movies or '?' Help - if I bind them with key eating they won't also be sent to DF for action and I get a free extra key". I say this because of noting the useing shift-P and shift-O for map resize bindings as was suggested earlier in this thread both pulls a lever *and* resizes the map.
The mousewheel poses interesting problems because you'd like to be able to distinguish mousewheel and mousewheel+modifier key just like click and click+modifier key are useful when seperately sensed. If this can be handled, mousewheel+modifier key(s) might become useful to plugin writers for scrolling long lists for example.
Since DF uses mousewheel for zoom by default, I still think a very intuitive mousewheel use with TwbT would be for mousewheel to zoom the map and mousewheel+Ctrl would zoom the text. I map zoom a* lot* more frequently than I text zoom with TwbT, so normal mousewheel is a better fit to map zooming than text zooming.
This would require some coordination between DFHack and TwbT though as you'd need to be able to suppress normal mouse wheel operation from getting to DF after it was used to TwbT map zoom and recognize mousewheel+Ctrl must be stripped of the Ctrl modifier before being sent to DF as a normal mousewheel action.
I'm an old fart, and I haven't been coding for a living for a bit over a decade. So I haven't dug into DFHack code as I never expect to be writing for it. So my comments are based on ergonomics and ease of use rather than knowing what's reasonably expectable to be possible.
Author
Topic: Text Will Be Text - dfhack plugin (Read 801628 times)