Bugzilla – Bug 113221
key press lost when choosing installation language with cursor up/down
Last modified: 2005-09-01 15:45:48 UTC
when choosing the install language from list by means of the keyboard, the selected language highligts than reverts to preceding language. It starts with English(US) selected. To choose Francais, you have to press arrow down 2 times. Then it reverts to Spanish. This problem occured also in previous suse professional version (as in 9.3). It occurs more likely if your hardware is slow.
Well, the behaviour is logical, because when going from english to franch with keys, you have to pass spanish. Why don't you use mouse?
There is a built-in timeout that skips languages if you are pressing keys very fast. If you press keys either very fast (at keyboard repeat rate) or you simply wait until the screen is redrawn, everything is just fine. Only if you happen to press keys in that speed in between those timings you'll get that behaviour.
In my interpretation of the processing, it seems as if, after switching to the language selected by a number of key strokes, and after redrawing the screen, the next action would be to clear the keyboard input buffer and thus loosing that intermediate key press. On slow systems, loading a language and redrawing can take a much longer time, and the longer this time lasts, the more likely that the user could have pressed an other key. I understand that in most situations in yast, it is much safer to drop input while processing takes place (because things change and the user sould act on current situation after processing is finished) but in this case, there should be a list of action not to be dropped (up and down).
I would suggest a simple resolution: set the time out before loading the language setting to 1 or 1.5 seconds, this would be a good compromise, I think.
Stefan?
No. That would be the ultimate worst possible approach. Everybody would have for that time for every key press. The current timeout is 200 ms. That means that key presses are not delivered until 200 ms are elapsed. If there were key presses in between, those will be ignored. The returned key press only makes the caller aware of any change in the selection box; it will then query the currently selected item, the current language in this case. That timeout is generic - every YaST2 selection box has it. It works out well for most cases, even in this language selection. Only if you have a very slow machine and you are hitting keys in a pretty hectic way, yet (just) not quickly enough, you will have this problem: As the dialog is rebuilt, the translations have to be reloaded, and this takes a moment. Sorry, you just have a fringe case. And no, no input buffer is ever being cleared. This is the most antisocial behaviour any application can ever have. It results in a lot of nasty surprises. We discussed that at length: http://yast.suse.com/tdg/html/UI-Events.html#id2557628