From: Hugues B. <non...@gm...> - 2011-02-10 16:22:32
|
> OK... But if we want to share configuration, we need to be sure we're > using the same set of key names. Sure. I doubt this will be a mjor problem though. For most keys there is only one possible transcription and for the few that may conflict a simple hash table should be enough (not exactly clean but it would work). > Actually, the pause is *more* important; you need a pause of at least > 5 interrupt periods - around 50 ms - between two presses of the same > key. In contrast, a key only needs to be pressed for one interrupt > period in order to be recognized. Interesting. Is the 50ms delay between the two presses or between the first release and the next press? The later looks more sensible but I'd rather not waste debugging time over such a subtle difference. > For 1-to-1 key bindings, of course, you want to hold the key down > exactly as long as the PC key is pressed. Sure. More generally the last key of a sequence will be held down exactly as long as the PC key is pressed. > It does mean a fair amount of extra work, both for parsing and for the > actual implementation - knowing what key sequences are prefixes, > keeping track of what's been pressed, providing appropriate visual > feedback. Key handling is complicated enough as it is. Fair enough (although there would be no extra work in parsing since that syntax is supported for ti keys and it's just string splits anyway). > And yeah, I love Emacs, but it's a complicated interface for a very > complicated program. I don't like it. However I've come to know this vocal minority (and its vi counterpart) when working my IDE project a few years ago. > Indeed. You want to measure time by the calculator's clock. A > TilemZ80 timer would do the trick - that's what I'm currently doing, > although I currently have it set to run for 50 ms both up and down, > which probably isn't good enough - see above. That should do. > >> I suppose you're right, but I don't see that being an issue for normal > >> users. > >> Calculator keypads don't like having lots of keys pressed at once, > >> either. > > > > It's my understanding than with direct input they can handle a lot more > > simultaneous keypresses than a PS/2 keyboard can. More importantly the > > issue is that if you bind CTRL+X to calc key A and CTRL+Y to calc key B > > pressing CTRL+X+Y probably won't simulate pressing A+B (unless some > > dirty hacks are used) > > What sort of hacks did you have in mind? I don't think that would be > any dirtier than what I'm already doing to properly handle key-release > events. (If your binding is Ctrl+X -> skGraphvar, then the X key is > considered to have "activated" the Graphvar keypress, so you need to > hold down Graphvar as long as the X key is held down - regardless of > what the modifier keys are doing.) I don't know how key input works in Gtk but in Qt it's fairly clean and handling key releases does not require any sort of hack. I did not have any specific hack in mind because I've not actually tried the CTRL+X+Y case but my experience of writing a text editing widget makes me think it's not likely to be clean (try SHIFT+A+B in most text editors and you'll see what I mean). > Yeah, I'm inclined to put this into the "UI-defined" category. I'd > probably make it a menu option (with the option, of course, to bind > the action to a key, but I probably wouldn't provide such a binding by > default, due to the potential for confusion.) Sounds reasonable. Hugues |