Apache OpenOffice (AOO) Bugzilla – Issue 37820
Zoom eats numerical keystrokes
Last modified: 2013-08-07 15:12:27 UTC
This is a combination of 2 not fatal, but annoying, user interaction issues in the Zoom dialog: A defect in the user experience but unknown whether due to OO code. I searched issues with "zoom" in summary but didn't see a likely candidate for dupe issue. However it is so obvious I think there may be a dupe that does not use the word zoom in the summary. caveat emptor.. 1) Numerical zoom shortcuts eaten when caret in zoom box When the input caret is in the manual zoom specification box (where you type how many percent to zoom the View), you can jump to other radio buttons with sequences like Alt-e and Alt-p. However the numerical radio buttons (i.e. Alt-1, Alt-0) do not work. 2) When manual zoom radio button is selected, "1" goes to 100% but Alt-1 does not work. Even if you back out of the input box (i.e. with shift-tab) the Alt-number sequences fail to work correctly. Upon backing out of the zoom percentage input box, Alt-1 goes nowhere. However Alt-E works. If you type just a "1" you will be moved to the 100% zoom radio button and select it, which is what was desired. (using redhat 9 windowmaker Japanese but not with Japanese input mode enabled)
Hi, this is not a bug. If you use ALT and the nNUMK Keypad numbers this will not work because ALT+NUMPad is a different key number then ALT+Main keypad numbers. Nevertheless I re-assign this Issue to the enhancement team for evaluation. Frank
Please note I believe there may be a misunderstanding. I am not using a numerical keypad on my keyboard. I am only using the normal number keys along the top of the keyboard. I confirmed this in OO presenter (the powerpoint clone) today as well. Basically the entire View->Zoom box for OO has user interface issues regarding ease of keyboard navigation for new users, at least with 1.1.2 which I still have. I have other issues too but will see if I can upgrade to a later build before posting more. Perhaps this was fixed already which is why you think I am talking about the numerical keypad? Thank you!
Hello, I came back to this issue and reconfirmed it in Presenter with 1.9.104 on RH9 linux. The two subissues do indeed exist and are interface bugs. This has nothing to do with a numerical keypad. The two bugs to restate the problem are: 1. Click the mouse on the 75% radio button in the Zoom dialog. Press Alt-1. This will not select the 100% radio button despite the "1" in "100%" being underlined. Just typing the 1 key without the Alt key works. 2. Click the mouse inside the Variable text widget. Enter Alt-1. The 100% radio button is not selected. And since this is a text entry widget, just typing the 1 key alone will enter a 1 in the widget without making a radio button selection obviously. The only way to reach the other radio buttons is to enter Shift-Tab, and then type a 1 for example to select 100%. This behavior breaks the UI paradigm that trains users to see an underlined character in a widget as an Alt-key combination. Seen in Presenter (or I guess it's called Impress) in 1.9.104 on RH9 linux.
SOLVED. Regarding the two points in the last comment, 1: The interface was redesigned so there is no such button anymore. 2: It works correctly now. Confirmed on OOo 3 in Windows XP.
To grep the issues easier via "requirements" I put the issues currently lying on my owner to the owner "requirements".