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.
I can't seem to find any way to select text using the keyboard in the output window, yet this can be done with the mouse.
Already fixed. Duplicate of #16667 *** This issue has been marked as a duplicate of 16667 ***
Sorry. I wasn't clear enough in my original bug description. This isn't the same as 16667, because that only speaks of being able to select all the text in the component. I can use the mouse and select a sub-range of the text in the output window and copy that, but I can not do the same without the mouse (e.g. if I just wanted to select and copy characters 2-30 and then copy them).
OK, reassign to me.
So it could be pretty tough problem! Questions: 1) how to select text without mouse (easy, probably using Shift + arrow) 2) there is no way how to display "current" position inside OW - there is no "|" cursor (use "|" cursor or other background/foreground? - CCing Ivan because of this part) 3) how to move this current position (probably via arrows, but these already have other functionality - up, down..)
Reassign to Ivan.
Ales: I agree it is a tough problem. I spoke with Dirk Ruiz here, and he suggested that maybe we could/should be using tab and shift-tab to move around in the list of errors rather than arrow keys. This would "free up" the arrow keys to be used for text selection. That would address your points 1 and 3. Not sure about 2 just now.
We could do the following : - use left and right arrow to move the cursor around the output window - use shift + right/left arrow to extend selection forward or back - the ide uses F12 and shift F12 for next and previous error - so we can free up the up and down arrows in the ouput window to do standard cursor navigation (up down). [ Paranthetic discussion on this point: We can use up and down arrows to move between errors (as it is now) and enable left and right cursor movement and selection (two points above) this might be better attuned to user needs - people will most likely want to jump from error to error and then make a selection within an error ]
Ahem ... we need to think more generically. The library component is a terminal emulator with many and varied uses, so making arguments on the basis of "errors" and such is probably not a good idea.
Target milestone -> 3.3.1.
Target milestone -> 3.4
Output window also swallows F10. So it's impossible to invoke main menu directly from OW. Workaround for this can be invoke PRoperties or Explorer by CTRL+1 or 2 (it works...) and and invoke main menu by F10.
Ivan it seems like you have fixed this issue partially, only problem with F10 is still present, am I right ? If yes I vote for closing this one as FIXED, - workaround for menu is Alt+<mnemonic> or lowering priority. Thanks in advance.
This is a dup of a bunch of other stuff, but the F10 unresponsiveness is a specific regression. I"ll see if I can look into it today and fix it.
Target milestone was changed from '3.4' to TBD.
Set terget milestone to TBD
FYI: in a read-only editor pane (the closest Swing equiv. to the termulator in "dumb" mode), arrow keys move an *invisible* caret, and you can shift-extend this way. Try it in the JavaHelp viewer. Weird but sort of works. F12 and S-F12 are not substitutes for moving between hyperlinks (which BTW uses Ctrl-T anyway); these commands also jump to the active hyperlink, which you do not necessarily want to do. E.g. if there are dozens of compilation errors you are not interested in, followed by one or two you are, it would be very annoying to have many files open in the editor just so you can scroll past their errors.
Hyperlink navigation is now performed as follows: 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 (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. --------------------------------------------------------- As for selection, we still don't have a good design. Maya and i spent some time throwing ideas around but didn't come up with anything good. Her last ide was to have a mode where you use the context menu to switch mode to "selection mode" where keystrokes don't get passed through but only the relevant few allow selection manipulation. It was too modal for my taste, but it was riminiscent of the Microsoft command prompt. I had hoped that the Microsoft Windows command window would offer some ideas, but that thing doesn't have keyborad selection either. The latest thoughts I had on this were these: So now plain arrows keys are open for moving the selection cursor around. What I intend to implement is a between-character vertical-line cursor. This is going to be different from a traditional "terminal emulator" prompt cursor and in general will be invisible. As soon as you issue an arrow key it becomes visible as a cue to the beginning of a selection. Unlike Swing TextArea you won't be able to insert any text at that cursor location! Once the selection cursor is visible all standard keyboard accelerators will manipulate the selection as usual. When the selection vanishes the cursor doesn't reappear until you type arrow keys again. ----------------------------------- The problem is regarding the last sentence. The standard gesture to get rid of a selection is Ctrl-\ per JLF. Unfortunately if the underlying process is a unix process it will get killed with a SIGQUIT. (It's the same problem as Ctrl-C meaning copy etc, while under unix there are other gestures for copying (Copy key, implicit stuffing of clipboard with a selection) the same is not true for Ctrl-\). I know Sun's Gnome accessibilizing effort has to solve the same problem for the gnome term, but all my forays were ignored. That was a w whil ago so perhaps I should try again.
doesn't seem we can fix it for 3.5 => target = 4.0
Is a fix really still planned for 3.6?
Ivan, we're evaluating all open A11Y bugs for 3.6 - could you give us an update on the status of this issue?
Tim, what i'd like to do is to hand this bug of to "HIE" for them to design the gestures to support selection manipulation through the keyboard. Then either of us can implement it. So, who do we reassign and how do we reclassify this issue?
I just talked with Maya, who contributed to this discussion before, and I offered to take it over (helpful, since I'm the one that submitted the issue a couple years ago :-) This issue is just about the output window. It isn't about the compiler error output, or the debugger console, or anywhere else that the term component may or may not be used. I do not believe that it is necessary (or desirable) that the same solution be used in all cases. However, this solution should be applied to any read/write or input/output terminal-like use of the component. The component should have at least three "modes": 1) Pass Everything Through Mode: In this case, any and all keyboard gestures are passed through to whatever is "behind" the window. 2) Limited Pass Through Mode: Most things get passed through, but Alt-* and F* keys should be passed to the IDE environment. This should be the default mode in most cases. 3) Selection Mode: In this mode, cursor keys (arrows, home, end (and others?)) should be used to move a then-visible cursor about and shift+cursor key should be used to establish and/or extend a selection. Ctrl- and Alt- combinations should be passed onto the IDE (so copy and paste can be done) Any other key or mouse click should revert from this mode to whatever mode (pass everything or limited pass) was in effect before... this makes this mode a "spring-loaded" mode of sorts. Modes 1 and 2 should be persisted for each of the categories of use of this. The contextual menu for this component should have a way to switch modes. Thus: ... other menu items ... ---------- Text Selection Mode [x] Send Special Keys To IDE I think there should also be an option in the options system somewhere that allows one to switch the "send special keys to ide" back on since if a keyboard only user switches to pass all keys through, there will be no other way for them to get back.
A slight correction to what I wrote before: The menu item "Text Selection Mode" should be a verb or a checkbox. So, I'd suggest [ ] Text Selection Mode and, when checked, it puts one into the spring-loaded mode mentioned earlier.
*** Issue 24759 has been marked as a duplicate of this issue. ***
I hope this issue is fixed by former redesign attempts. Please reopen if the issue is still valid. At least I have checked that selection works well and also Shift-F10 allows to show popup menu. Marking as resolved fixed.