Community
Participate
Working Groups
An example of this behavior is in OS X's Terminal app. If you manually scroll up, especially if you're actively scrolling (i.e. mouse is holding the scroll bar), output on the console should not jump to the bottom. It should only jump to the bottom when the user scrolls the console back down to the bottom. If you've ever tried to scroll up to read a stack trace while there is continuous output writing to the console, then you know the hair-pulling not having this behavior can cause.
*** Bug 170186 has been marked as a duplicate of this bug. ***
Deferred
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
Reopening. This would really be handy.
Here is the code (17 lines): http://blog.pdark.de/2009/02/03/stop-scrolling-in-swt/
While that's better than the current behavior, IMO, OS X just gets this right. It's not just when you're holding the scrollbar, it's if you drag it up at all. Once you drag it up, the scroll locks, presuming you're trying to read something in the scroll history. If you move it back down to the bottom, it will unlock. You can see this behavior in Terminal really easily, and it's almost always done what I intuitively expect when I'm trying to read.
*** Bug 282435 has been marked as a duplicate of this bug. ***
Could it be as simple as the patch in bug 282435?
> Could it be as simple as the patch in bug 282435? Unfortunately not. When I run the class below, the Console view stops scrolling after a few lines (without any scrollbar interaction of my part). public class ConsoleFiller { public static void main(String[] args) { for (int i = 0; i < 1000000; i++) { System.out.println(i); try { Thread.sleep(100); } catch (InterruptedException e) { e.printStackTrace(); } } } }
yeah -- unfortunately, that worked when i originally wrote it and then ended up breaking a couple builds later. it wasn't my proudest patch, I will say :)
What about my code? http://blog.pdark.de/2009/02/03/stop-scrolling-in-swt/
I think the definitely-don't-scroll-if-you're-holding is good. I think OS X's behavior is even a little better, which is just that if you scroll up from the bottom, you scroll-lock. Just snap the scrollbar back to the bottom and you're scrolling again. It seems like a really intuitive interaction to me.
(In reply to comment #12) > I think OS X's > behavior is even a little better, which is just that if you scroll up from the > bottom, you scroll-lock. Just snap the scrollbar back to the bottom and you're > scrolling again. It seems like a really intuitive interaction to me. KDE Terminals behave the same way and I agree, this would be better but from memory, I think that's not possible without patching StyledText.
I am constantly frustrated by this. I am scrolling the console window to look at a stack trace and it suddenly swaps to another app or scrolls away from where I am looking. To prevent this behaviour I have to press two buttons, scroll lock and pin console. Then later I wonder why the console is not showing activity and I realise I have not unpressed the buttons. The LogCat console in the android plugin detects when you start scrolling.
*** Bug 412054 has been marked as a duplicate of this bug. ***
*** Bug 362040 has been marked as a duplicate of this bug. ***
Created attachment 242411 [details] Patch to lock the screen when scroll bar is moved up This patch adds a listener on the vertical scroll bar . Also it locks the console at that point. once scroll bar is moved near the end of the document,end of the document is revealed as now. Thanks Aaron for the scroll bar listener code blog, but that locks the screen till we are holding the scroll bar.
*** Bug 437752 has been marked as a duplicate of this bug. ***
So, this improvement request has been around for almost a decade. How about it?
(In reply to Marc from comment #19) > So, this improvement request has been around for almost a decade. How about > it? We are working on it, the solution is under review !!
*** Bug 440740 has been marked as a duplicate of this bug. ***
The patch does not stop the scrolling no matter what I do: 1. grab the scroll bar 2. use mousepad scroll gesture 3. click the scroll bar above the scroll widget Snippet I used: public class FloodConsole { public static void main(String[] args) { for (int i = 0; i < 100000000; i++) { System.out.println(i); } } }
(In reply to Michael Rennie from comment #22) I didn't try the patch, but I think your snippet causes a different effect: The Console view by default has a ridiculously low limit of 80000 chars, and then it starts to throw away the first line, which can cause all kinds of weirdness. I think the overflow behavior is not that important, so I suggest you throttle the sysouts a bit (e.g. Thread.sleep(100);)
The patch works fine with the snippet in Comment #9 But fails to produce the scroll lock effect with the snippet in Comment # 22
Created attachment 246422 [details] Scroll Lock un lock behaviour This patch locks and un locks on scroll drag. Suggesting the new action, as in previous patch if output is more, reaching near the end does not work all the time. So we are not able to reveal the end of the document always When the output is really fast as in Comment #22, we never get the widget selected event as SWT.DRAG or SWT.SELECTED.
(In reply to Sarika Sinha from comment #25) > Created attachment 246422 [details] This patch doesn't reliably lock scrolling for comment 9 for me (Windows 7) when I grab the thumb and then repeatedly move and stop the mouse. It seems to toggle between locked/unlocked with every new movement. The auto-locking should also work if the widget is scrolled via PageUp, ArrowUp, Ctrl+Home, etc. I'm not sure if a DRAG event is sent in that case. Coding comments: The listener should not be stored in a field. It's not used elsewhere. new SelectionListener() {..} should use a SelectionAdapter and should not override widgetDefaultSelected(..). userHoldsScrollbar.get() == Boolean.FALSE ... get rid of auto-unboxing: userHoldsScrollbar.get() == false ... get rid of "false" literal: !userHoldsScrollbar.get()
Created attachment 246465 [details] Scroll lock on Top, Page Up and Drag Thanks Markus for reviewing and suggesting for using Top, Page up etc. Now I am using Bottom to unlock this scrolling and this helps removing the lock/unlock on each movement. Page UP, Top and Drag action can now lock the screen. Ctrl Home does not work though.
(In reply to Sarika Sinha from comment #27) > Created attachment 246465 [details] [diff] > Page UP, Top and Drag action can now lock the screen. Pressing the PageUp key doesn't lock for me on Windows 7. You need to listen for key events too. Also, when just scrolling up via mouse wheel doesn't lock (note that this sends the selection event, but you ignore that event). Unlocking is very hard to achieve. The only way for me on Windows 7 is to select 'Bottom' from the scroll bar context menu. You should check whether the thumb is at the bottom and then unlock. When going into lock mode, the scroll lock icon should be selected/enabled, otherwise it becomes very strange for the user: the button doesn't allow me to unlock anymore.
Created attachment 247954 [details] Scroll lock on Page Up , Top, Home, Drag and Mouse wheel scroll up Scroll lock will happen on vertical bar action(Top, Page Up & Home), key selection ( Home & Page Up) and mouse wheel scroll up action. This will set the Scroll Lock icon enabled. Lock can be removed using Scroll lock action/icon or keys like END and Scroll bar Bottom action.
(In reply to Sarika Sinha from comment #29) > Created attachment 247954 [details] > Scroll lock on Page Up , Top, Home, Drag and Mouse wheel scroll up > > Scroll lock will happen on vertical bar action(Top, Page Up & Home), key > selection ( Home & Page Up) and mouse wheel scroll up action. > > This will set the Scroll Lock icon enabled. > > Lock can be removed using Scroll lock action/icon or keys like END and > Scroll bar Bottom action. behaves much better now (using the snippet from comment #9). A couple more cases which probably should work: 1. ctrl+up arrow and up arrow do not lock 2. drag scroll bar to bottom, scroll wheel to the bottom, page down, down arrow to bottom, ctrl+down arrow do not unlock
(In reply to Sarika Sinha from comment #29) > Created attachment 247954 [details] [diff] Much better now, since one can see the lock mode. However, it is still not possible to unlock using the mouse wheel (scroll down fast to the end) or the scroll bar thumb (pull it to the bottom). Since one can lock via those two ways, one must also be able to unlock. > ctrl+up This is lower prio for me.
Created attachment 249056 [details] Scroll Lock JDT Patch
Created attachment 249057 [details] Scroll lock on Top, Page Up ,Home, Drag and Mouse Wheel This patch adds an interface to support the lock action provided by any view implementing the Scroll Lock interface. View locks with UP, Page Up, TO, Home and Scroll bar drag action (Screen Lock icon is set to Locked state in the view) View gets unlocked with Bottom and End or if Scroll Bar, Page Down and Down Arrow key reached to the end of view display. (Page Down pressed once may not unlock if it is not at the end of display)
Comment on attachment 249057 [details] Scroll lock on Top, Page Up ,Home, Drag and Mouse Wheel Works great now! Issues with the patch: - IScrollLockState must not extend IViewPart, it should only be responsible for the lock state ==> rename it to IScrollLockStateProvider - IScrollLockState needs real Javadoc, not just the @since tag - TextConsoleViewer: replace all the "consoleView" related stuff (code and parameter, Javadoc, ...= with scrollLockStateProvider After those changes the patch is good to go.
Comment on attachment 249056 [details] Scroll Lock JDT Patch The patch works. Some minor corrections to be made: - the required version for ui.console must be adjusted in the manifest.mf - adjust to changes in main patch (IScrollLockState, don't use "view") - the old constructor in JavaStackTraceConsoleViewer can be removed - add dispose() to JavaStackTraceConsolePage where you 'fScrollLockStateProvider' to 'null' After those changes the patch is good to go.
Comment on attachment 249056 [details] Scroll Lock JDT Patch Actually, this patch is not needed since the JavaStackTraceConsole doesn't allow to lock.
(In reply to Dani Megert from comment #34) > Comment on attachment 249057 [details] [diff] > Scroll lock on Top, Page Up ,Home, Drag and Mouse Wheel > > Works great now! There's one issue I noticed: when at the end and nothing else is written to the console, using the mouse wheel, scroll bar or scroll down arrow, the view flickers.
Created attachment 249123 [details] Scroll lock on Top, Page Up ,Home, Drag and Mouse Wheel Good catch -> Flickering !!! No need to reveal the end of document if scrollLockStateProvider is provided as it takes care of it. Also resetting the scroll Lock to unlocked state while disposing.
Created attachment 249137 [details] Scroll lock on Top, Page Up ,Home, Drag and Mouse Wheel Removed the resetting of Scroll Lock state on dispose
Comment on attachment 249137 [details] Scroll lock on Top, Page Up ,Home, Drag and Mouse Wheel Patch is good. I've fixed several Javadoc issue before committing. Please take a look at them. Committed with http://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=http://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=a11ed20c73670c89c15179e9f790f53ac7e31c33
.
Verified using Eclipse SDK Version: Mars (4.5) Build id: I20141208-2000
I can imagine that this new feature has some benefit for some scenarios. Personally I find it totally annoying because it interferes with how I'm used to (and want to) work with the console. 99% of all times I want to know if problems/exceptions are logged to the console and now it always stops scrolling to the end where new traces are appended. I wonder if I can configure the console to behave like before, i.e., without automatically scroll-locking? BTW. part of the problem is that the console seems to stop by itself at arbitrary times without me even touching the console view. I haven't managed to see any relation to something that I'm doing or that happens in the console. It also strikes me that the scroll-lock could be automatically released when I clear the console, but that might be a matter of taste.
(In reply to Eike Stepper from comment #43) > I can imagine that this new feature has some benefit for some scenarios. > Personally I find it totally annoying because it interferes with how I'm > used to (and want to) work with the console. 99% of all times I want to know > if problems/exceptions are logged to the console and now it always stops > scrolling to the end where new traces are appended. Yes, that's how it's supposed to be, unless the user tries too look at stuff above (e.g. scroll up). > I wonder if I can configure the console to behave like before, i.e., without > automatically scroll-locking? No. > BTW. part of the problem is that the console seems to stop by itself at > arbitrary times without me even touching the console view. To me it looks like that *is* the problem you're running into. We'd need to have a new bug with steps, so that we can stop that arbitrary locking of the view.
(In reply to Dani Megert from comment #44) > > BTW. part of the problem is that the console seems to stop by itself at > > arbitrary times without me even touching the console view. > > To me it looks like that *is* the problem you're running into. We'd need to > have a new bug with steps, so that we can stop that arbitrary locking of the > view. I can submit a new bug but I really don't know what steps are needed to demo the problem. One thing I observed, though: When I scrolled the console and it gets locked and I then restart my runtime instance, then the auto-lock button stays selected even in the new launch, which starts with a fresh empty console. For me that's kind of unexpected and maybe I had just forgotten that, long ago, I did scroll the previous console. Not sure if I managed to get this over well ;-)
(In reply to Eike Stepper from comment #45) > (In reply to Dani Megert from comment #44) > > > BTW. part of the problem is that the console seems to stop by itself at > > > arbitrary times without me even touching the console view. > > > > To me it looks like that *is* the problem you're running into. We'd need to > > have a new bug with steps, so that we can stop that arbitrary locking of the > > view. > > I can submit a new bug but I really don't know what steps are needed to demo > the problem. Are you maybe providing input in the console? If so, you might run into bug 457969. > One thing I observed, though: When I scrolled the console and it gets locked > and I then restart my runtime instance, then the auto-lock button stays > selected even in the new launch, which starts with a fresh empty console. That's the case since a long time, i.e. only one state that is preserved over launches and restarts. But I see your point. We should only update the preference value when the user explicitly clicks the button. Can you please open a bug against Platform Debug and cc me? Thanks.
(In reply to Dani Megert from comment #46) > > One thing I observed, though: When I scrolled the console and it gets locked > > and I then restart my runtime instance, then the auto-lock button stays > > selected even in the new launch, which starts with a fresh empty console. > > That's the case since a long time, i.e. only one state that is preserved > over launches and restarts. Sorry, that was wrong. Even in 3.x we clear the state when the last Console is closed or on restart, i.e. it will always be in the auto-scroll state. Can you reproduce a case where the button is checked after a restart?
(In reply to Dani Megert from comment #47) > Sorry, that was wrong. Even in 3.x we clear the state when the last Console > is closed or on restart, i.e. it will always be in the auto-scroll state. > Can you reproduce a case where the button is checked after a restart? Yes, I tried it when you asked me to provide concrete steps. And with the following test I just found out that it's probably slightly worse: public class ScrollLockTest { public static void main(String[] args) { for (int i = 0; i < 100; i++) { System.out.println("I fill the console..."); } } } Notice that this is not an Eclipse Application launch and *Restart*. It's a Java launch and when you start it once, then scroll the console and then *start* it again, the console is still locked. To me it's even surprising that the actual auto-lock happens when I scroll the console of the *terminated* first launch. That should probably not happen. In any case I think a new launch or a restart should always start unlocked.
(In reply to Eike Stepper from comment #48) > (In reply to Dani Megert from comment #47) > > Sorry, that was wrong. Even in 3.x we clear the state when the last Console > > is closed or on restart, i.e. it will always be in the auto-scroll state. > > Can you reproduce a case where the button is checked after a restart? > > Yes, I tried it when you asked me to provide concrete steps. And with the > following test I just found out that it's probably slightly worse: > > public class ScrollLockTest > { > public static void main(String[] args) > { > for (int i = 0; i < 100; i++) > { > System.out.println("I fill the console..."); > } > } > } > > Notice that this is not an Eclipse Application launch and *Restart*. It's a > Java launch and when you start it once, then scroll the console and then > *start* it again, the console is still locked. That's the behavior we had for more than 10 years. Let's focus on the changes introduced by the auto-lock. Of course you can file an enhancement request for a new per-launch scroll lock setting if you want. > To me it's even surprising > that the actual auto-lock happens when I scroll the console of the > *terminated* first launch. I agree, we should avoid that. Can you file a bug for that? Thanks.
(In reply to Dani Megert from comment #49) > > Notice that this is not an Eclipse Application launch and *Restart*. It's a > > Java launch and when you start it once, then scroll the console and then > > *start* it again, the console is still locked. > > That's the behavior we had for more than 10 years. Let's focus on the > changes introduced by the auto-lock. Of course you can file an enhancement > request for a new per-launch scroll lock setting if you want. Hm, not exactly I think. Formerly I really had to click on that scroll-lock button and that I would remember even after a restart of the launch. But now "it gets pushed for me" and it took me quite a while to notice that. Even now that I know about the new auto-scroll-lock feature I find it not very practical that I always must remember to uncheck that button before I restart the launched process. > > To me it's even surprising > > that the actual auto-lock happens when I scroll the console of the > > *terminated* first launch. > > I agree, we should avoid that. Can you file a bug for that? Thanks. Sure: http://bugs.eclipse.org/459494
(In reply to Eike Stepper from comment #50) > (In reply to Dani Megert from comment #49) > > > Notice that this is not an Eclipse Application launch and *Restart*. It's a > > > Java launch and when you start it once, then scroll the console and then > > > *start* it again, the console is still locked. > > > > That's the behavior we had for more than 10 years. Let's focus on the > > changes introduced by the auto-lock. Of course you can file an enhancement > > request for a new per-launch scroll lock setting if you want. > > Hm, not exactly I think. Formerly I really had to click on that scroll-lock > button and that I would remember even after a restart of the launch. But now > "it gets pushed for me" and it took me quite a while to notice that. Yes, the auto-scroll lock should not affect the view state. Only when the user clicks on the toolbar icon it should affect the next launch. Please file that bug (sorry, I'm terribly lazy here ;-).
(In reply to Dani Megert from comment #51) > Please file that bug (sorry, I'm terribly lazy here ;-). No problem. This is not severe, just a little annoying when you work with consoles a lot ;-) I submitted http://bugs.eclipse.org/459517
>> I wonder if I can configure the console to behave like before, i.e., without >> automatically scroll-locking? >No. No ? That's all ? Please, when you decide to modify an existing feature, as much as possible, respect people's habits and usages and supply a way to disable the new behavior, in case of. Hence you could improve your new feature without messing up the existing ones. Me and my nerves are thanking you in advance.
(In reply to Laurent Barbareau from comment #53) > >> I wonder if I can configure the console to behave like before, i.e., without > >> automatically scroll-locking? > > >No. > > No ? That's all ? > > Please, when you decide to modify an existing feature, as much as possible, > respect people's habits and usages and supply a way to disable the new > behavior, in case of. Hence you could improve your new feature without > messing up the existing ones. Me and my nerves are thanking you in advance. I totally agree with that. I'm sorry to say, but this is the most annoying change over the last years. Even on a cluttered desktop the console is the part that's always visible and by clicking there I want to bring eclipse to front and not lock the console. There's a button for that.
(In reply to Ingo Wiese from comment #54) > by clicking there I want to bring eclipse to > front and not lock the console. That would be a bug. Clicking alone must not auto-lock. Please file a bug with steps to reproduce this and cc me. Thanks.
(In reply to Ingo Wiese from comment #54) > (In reply to Laurent Barbareau from comment #53) > > >> I wonder if I can configure the console to behave like before, i.e., without > > >> automatically scroll-locking? > > > > >No. > > > > No ? That's all ? > > > > Please, when you decide to modify an existing feature, as much as possible, > > respect people's habits and usages and supply a way to disable the new > > behavior, in case of. Hence you could improve your new feature without > > messing up the existing ones. Me and my nerves are thanking you in advance. > > I totally agree with that. I'm sorry to say, but this is the most annoying > change over the last years. Even on a cluttered desktop the console is the > part that's always visible and by clicking there I want to bring eclipse to > front and not lock the console. There's a button for that. +1 couldn't agree more.
Am I wrong or was it broken again in 4.6? I am currently using 4.6M3 When I scroll up, no scroll lock is activated. Manually activated scroll lock is unlocked when I scroll further up.
Using GTK 3.18 on X11, in case it is relevant.
Filed a bug #485192. I find this feature very annoying.
(In reply to Pavel Sklenak from comment #58) > Using GTK 3.18 on X11, in case it is relevant. I tested it works as expected with windows and GTK 3.16. What is the OS and Desktop Manager? Was it working for you before with the same configuration?
I used it under windows 10, windows 8.1 and windows 7 (native), no special installation. Everywhere the same behaviour. I'm using classic theme, but changing without theme doesnt help. No change if limit console to 1000000 or 80000. If you have an output of 1000 lines and you scroll up 1 line, scroll lock gets deactivated immediatelly? I have to scroll up ~70 lines before sroll lock is activated.
(In reply to Sarika Sinha from comment #60) > (In reply to Pavel Sklenak from comment #58) > > Using GTK 3.18 on X11, in case it is relevant. > > I tested it works as expected with windows and GTK 3.16. > What is the OS and Desktop Manager? Was it working for you before with the > same configuration? Gnome 3.18/Fedora 23 With the old version (4.5, I guess) the scroll lock was deactivated only when reaching bottom of the output. I use unlimited console output, the scrolling jumps by 3 lines at once, the scroll lock gets immediately deactivated regardless of position.
The behaviour is regardless of limitting. (Switched it off, the same) The scroll lock gets deactivated if scrolling within the last ~10% of the log. In the first 90% its activated automatically. Its also independent from MouseWheel, cursor up and page up. I thought it was since introducing the feature, can't remembering that it was working well (The old manual scroll lock was not comfortable, but it worked, always wondered why it wasnt implemented like in IntelliJ, which had this feature since 2000?). AAAAHHH: Cool, I just discovered I can scroll which dragging WITHOUT toggling the autoscroll state.
For those as me who need to disable the auto scroll lock I have opened a request : https://bugs.eclipse.org/bugs/show_bug.cgi?id=495658
