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.
dev build 200310010100 Some scrollbars in Netbeans (output window for one) scroll way too slowly.. I think they're set to scroll one unit at a time. I would like to see this value increased to 30 or 50 units at a time. Example usage: try to select text found in the output window by dragging the mouse from left to right and having the horizontal bar auto-scroll to the right. It scrolls very slow on long texts.
Hello? Any movement on this issue? Sounds like something that's easy to fix and it's getting rather annoying on my end. I need to copy/paste large amounts of text from the output window at least 50 times a day and I keep on having to scroll horizontally one unit at a time to do this. Please evaluate this issue soon.
Assigning to terminal emulator which should handle autoscroll step size I think.
Cc'ing Ivan, since he told me he plans to be making some changes in Term soon.
Just to confirm ... Are you specifically unhappy with _auto_ scrolling or is the granularity of scrollbutton and scroll bubble actions also troublesome?
I'm unhappy with the granularity of horizontal scrolling on the output window (OW) when I: Clear on text in the OW Drag the mouse to the right of the OW, causing the selection to extend to the end of the line While I'm dragging in step 2, the granularity is way too small. It's scrolling one character at a time while I expect maybe 15.
Is it OK for vertical scrolling?
Currently it is ok for vertical scrolling because personally I have never had a need to highlight a lot of text vertically. I can image, though, in the future if someone wishes to highlight say 200 lines of output it might be annoying to scroll one line at a time vertically too. I would experiment with changing both the horizontal and vertical scrolling rates and giving it a try. I think a good idea is to make the scroll rate a percentage of the window size in that direction. For example, if the window is very wide, the scroll horizontally should be fast. If a screen is very short (vertically) it should scroll downward slowly. And the scrolling rate should adjust as the window size changes at runtime. That would be the ultimate solution in my opinion.
Setting this issue to target milestone future - I've got enough to do with winsys and property sheet and html rendering infrastructure, that I'm not likely to get to this. Ivan, you'll probably be the one to address this anyway - if you think you can do something on it in time for 3.6, reassign this issue to yourself and set it as you wish.
Until we agree on a common solution changed the rate from 50 to 10 milli-seconds per frame.
After discussions on nbui here's the plan based on DavidJohn recommendation: scrolling rate relative to the distance of mouse from edge. this is apparently a common idiom. not quite clear whether rates should be different for vertical and horizontal scrolling rate proportional to distance from edge as opposed to ratio of distance from edge to width of window (but experiment anyway :-) rate _linearly_ porportional to distance from edge. (BUt experiment with other functions?) rate should manifest itself as alteration of millisecond delay as opposed to altering the number of columns shifted/lines scrolled.
Ivan, Sounds like a good idea. Please apply this algorithm to vertical selection as well as horizontal.
Since you seem to be handling this, Ivan, in a devious attempt to reduce my open bug count, I'm going to assign this issue to you :-O
Not an issue anymore with the new output window implementation for 4.0
closed
While the terminalemulator is not in active use in NB proper, it is being used in sunstudio so bugs against it are still relevant and shouldn't be closed just because there's OW2.
Hi Ivan, just short explanation why this issue has been verified/closed : we closed all already resolved issues, so did this one. It was fixed on 16/07/2004 by pnejedly with TM=4.0, so we've verified this resolution. Because you've reopened it again, it seems like it had never been solved before ... that's another reason why we did it, some of issues already resolved for long time are still valid and nobody knows about it....
due to lack of response from the reopener... issue closed =P
What do you want me to say? The terminalemulator _still_ has slow scrollbars and that is _still_ an issue for SunStudio. The bug is filed against core/terminalemulator, not output window. So, yes while OW's scrolling problem has been resolved by switching to OW2, the bug in core/terminalemulator is still there and I still need to do something about it one of these days.
Ivan, has anything changed in 2 years or does this bug still exist?
Yes. But the terminalemulator is no longer used in regular netbeans, only in sunstudio. Are you impacted by this when using sunstudio or plain NB? Of only when using plain NB then please file a separate IZ against core/output.
Ivan, I use plain NB and it works fine. I was just asking whether this was fixed in sunstudio so we could close this issue but I guess this isn't the case.
Is not reproducible in the fresh NB
The nature of this IZ is that of an RFE. The scrolling speed during selection is supposed to be proportional to distance from window. That's how it is, for example, with the NB text editor. This RFE hasn't been implemented yet so the issue still stands.