This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Not able to navigate to left/right in output window | ||
---|---|---|---|
Product: | cnd | Reporter: | Lukas Hasik <lhasik> |
Component: | Terminalemulator | Assignee: | ivan <ivan> |
Status: | CLOSED FIXED | ||
Severity: | blocker | CC: | mbudris, mmirilovic, mvenkatraman, non_migrated_user |
Priority: | P2 | Keywords: | A11Y |
Version: | 3.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
Lukas Hasik
2002-01-08 17:46:19 UTC
How about using Ctrl Pg up and Ctrl Pg Dn as shortcuts to move one pane to the left or right . These also happen to be JLF recommendations. And this is how the shortcuts behave in the editor. inreasing priority -> to be fixed to 3.3.1 OW has to be accessible ! User has to have chance to see whole output even when navigating only with keyboard. For inspiration look at Source Editor. Scrollbars are focusable -> and then you can manage them with keyboard. Maya's idea sound good. Just a note to clarify - I think that giving focus to the scroll bar is a bit odd. I am not sure I understand why the editor does this. If the user can move up and down by pgUp PgDn and left and right by CtrlPg up and Ctrl PGDn - we would not need to pass focus to the scroll bars. I wasn't right with focusable scrollbars. Scrollbars are focusable only on jdk1.4 ! Sorry for inaccuracy. Target milestone -> 3.4 Target milestone -> 3.4 Target milestone -> 3.4 Target milestone -> 3.4 added FFJ40_WAV_APPROVED keyword For a while I considered this bug to be a tip'o the iceberg for _all_ keybrd shortcut problems with the term/OW combo. Most of them, and of course the left-right navigation, have been dealt with. Controlling the selection with the keybrd is still to be done and is the subject of http://www.netbeans.org/issues/show_bug.cgi?id=24759 A fair amount of time was wasted because the JLF incorrectly cites Ctrl-Tab and friends for hypelrink navigation, when in fact it's supposed to be Ctrl-T and Ctrl-Shift-T. You can read all the gory details in .../terminalemulator/ReleaseNotes.ivan.txt. Here is the final set of bindings Action New binding Old Binding Where -------------------------------------------------------------------- Scroll line up Ctrl-UpArrow (1) UpArrow Term Scroll line down Ctrl-DownArrow (1) DownArrow Term Scroll page up PageUp Term Scroll page down PageDown Term Scroll view left Ctrl-PageUp (1) Term Scroll view right Ctrl-PageDown (1) Term Scroll column # No good binding available Next hyperlink Ctrl-T (2) (3) DownArrow OW Prev hyperlink Shift-Ctrl-T (3) UpArrow OW Activate hyperlink Enter|Space Enter|Space OW Activate hyperlink Single-click (4) Single|Double-Click OW+Term Next Error & Activate F12 (3) F12 OW Prev Error & Activate Shift-F12 (3) Shift-F12 OW (1) Conflicts with JLF TabbedPane accelerators. (2) The highlighted errors are best described as hyperlinks hence the generic treatment. (3) If you reach the last (first) link/error next (prev) will not work on the first try and will put out a message in the status bar. One more will cause a wrap then. (4) The original implementation was very confused about single vs double click. So much so that I couldn't characterise it. For example build errors were navigable with a single click, while exception errors had to be double-clicked. these shortcuts look good. they have hie approval. verified in [nb_dev](20021016) Resolved for 3.4.x or earlier, no new info since then -> closing. moving terminal emulator issues to terminalemulator component. To see the correct version and target milestone of this issue look at Issue Activity table. |