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.
Currently we use MouseWheelUp/Down for scrolling by 3 lines in editor. Many users, however, redefine manually the shortcuts Ctrl-MouseWheelUp/Down to enable faster scrolling - they do it by assigning PageUp/Down actions to the shortcut. Other users just demand this type of functionality to be introduced. However, there is the opposing concern; users tend to activate Ctrl-MouseWheelUp/Down accidentally in several scenarios as pointed out, e.g., in issue #203243 or issue #212484. The original assignment of editor size change to the same shortcut led to strong users' opposition because accidental font changes could not be reverted easily and could damage live presentations etc. (this has been resolved by issue #212484 and is addressed further by #214772). In view of the conflicting opinions above, I still consider it valuable to take use of Ctrl-MouseWheelUp/Down shortcut, but in a way that would be on one hand regarded as useful and on the other as not significantly harming in case of accidental invocation. Therefore, assigning the accelerated scrolling action to this shortcut seems to be the acceptable way of making things better. Note that what I suggest here is different from assigning PageUp/Down action. The proposal here is: Ctrl-MouseWheelUp/Down scrolls similarly as MouseWheelUp/Down alone, only faster. (Meaning that cursor is not moved by this action). As of the actual speed: scrolling by the whole page length would be an easy option, but it has two disadvantages: it is easy to loose track of how far it has been scrolled if there is no overlap between what has been seen before and after, and too fast scrolling would be perceived as too annoying in case of accidental invocation (or in the usecase when users keep Ctrl pressed and then click to go to definitions, scroll, click etc.) Thus I suggest to consider the accelerated scroll to be either a given number of lines (e.g., 3x or 5x the standard scroll) or to be either 1/3 or 1/2 of current page size. Ideally, this would be adjustable in Options. This feature must be possible to deactivate or reassign in Keymap.
I'm not sure this is a good idea. There are already some mice and trackpads that accelerate scrolling speed according to user gestures so why introduce something that's duplicate of a hardware feature and hard to discover anyway. Is there any other software using this?
The comment http://netbeans.org/bugzilla/show_bug.cgi?id=203243#c0 is one of those I have seen/received showing that some users redefine Ctrl-MouseWheel to PageUp/Down for this purpose. CC-ing Rich for second opinion.
Ctrl-MouseWheel should always be used to zoom in/zoom out on documents. If it is possible to determine mousewheel acceleration, use that to inform the number of lines of scroll vertically.
Rich, actually we had used Ctrl-MouseWheel for zooming originally, but in NetBeans context this raised strong opposition including one strong complaint from some top dog several layers higher in our management hierarchy - the reason is this: one of the absolutely most popular shortcuts in NetBeans is Ctrl-LeftClick which means "go to declaration". This, unfortunately, interferes with Ctrl-MouseWheel as follows: users often go to declaration, then scroll a couple of lines, then go to declaration again etc. etc. In this sequence from time to time they hit the wheel while still holding Ctrl. At such moment the editor zoomed in or out (changed font size) and, e.g., a public presentation got broken before the user realized it was necessary to zoom back - what in NetBeans untill now is not really straighforward (hence issue #214772). The opposition to Ctrl-MouseWheel to be used for zooming (in this case editor font sizing) was so strong that we had to reassign the action (issue #212484). So with Ctrl-MouseWheel we will always have a problem, but if utilized merely for scroll acceleration (which is a kind of "zoom in speed" ;-) this might not be that serious. But this is hard to guess without perhaps a trial of some kind..
I have accidentally discovered that Adobe Creative Suite uses these shortcuts: MouseWheel for vertical scrolling as usual, Ctrl-MouseWheel for vertical scrolling, Alt-MouseWheel for zooming. Alt-MouseWheel is coincidentally the same as we use now.
Thanks for the historical perspective. Like you've seen with Adobe, modifier keys on mouse-wheel have no real standard/guidelines-based behavior. I think this is something that users should opt in to, and yes, it should be put out there on a trial basis and see if folks like it.
Petr, I think acceleration with Ctrl-MouseWheel will have the same problem as we had with zooming (change in behavior just because of pressed Ctrl during navigation). What if we try Shift-MouseWheel? Shift is used to capitalize (make bigger :-)) letters, let's capitalize (accelerate) mouse speed
Vladimir, thanks for commenting on this. Actually in view of the repeated expressions of doubt I change my recommendation - in order to stay on the safe side it is perhaps better to refrain from assigning Ctrl-MouseWheel to anything. But I would still recommend to have a "faster scroll" action defined and available for users who would want to assign it to Ctrl-MouseWheel manually. As for the Shift-MouseWheel idea, it clashes with another proposal which I believe might have a bigger practical impact than faster scrolling as discussed her, see issue #214783.
Not to harp on it, but is there any way to tap into some sort of acceleration calculation from the mousewheel itself, i.e. when the user spins it faster, increase the scroll interval?
(In reply to comment #9) > Not to harp on it, but is there any way to tap into some sort of acceleration > calculation from the mousewheel itself, i.e. when the user spins it faster, > increase the scroll interval? There is MouseWheelEvent.getPreciseWheelRotation(). It's return value depends on the speed of the scroll wheel. I tried it with my MS Windows 7 touch mouse and the return value varied from 0.001 (very slow scrolling) to 2.0 (very fast scrolling). But these values are propagated to editor window scrollbars and I can scroll as fast or as slow as I want. But I don't have a regular mouse with an actual scroll wheel so I can't check how it behaves in other cases.
*** Bug 226489 has been marked as a duplicate of this bug. ***
(In reply to Petr Somol from comment #8) > But I would still recommend to have a "faster scroll" action > defined and available for users who would want to assign it to > Ctrl-MouseWheel manually. A faster scrolling function would be great. I'm really missing this since I changed from another IDE. I think for the user it don't makes a big difference if he has to hold down Shift or Ctrl or maybe Shift-Ctrl. Most elegant way would be if could define it yourself in the keymap.
Coming from Eclipse I really lack this feature.
Netbeans 8.1 and still nothing.
Any luck to see this feature in V. 8.2? It's importante especially on Linux because the OS gives you no option for mouse scroll rate, so should be app-based (just like Firefox and Eclipse do).
V. 8.2: nothing yet. Let's hope in V. 9.0.