Community
Participate
Working Groups
When the terminal produces output it always makes the cursor visible (by scrolling to the end). There should be a mode where auto-scroll is disabled. Similar to the eclipse Console.
CQ:WIND00215180
Some implementation for scroll lock is there, but the corresponding "Scroll Lock" button in the UI has never been activated since the feature does not fully work as expected. For instance, when scroll lock is chosen, then rather than locking the CURRENT line of output, it jumps to line #1. Contributions are welcome for addressing this.
Created attachment 170823 [details] Fix terminal view jumping to first line if Scroll Lock is activated
This patch looks like a low risk patch. Since it does not change the behavior whe scroll lock mode is disabled. Uwe, does this fix make scroll lock usable?
From looking at the patch, I agree that it's low-risk. While I can see no impact of this on Open Source (because we don't expose the TerminalActionScrollLock in the TerminalView), I also see that the fix won't harm us since fScrollLock should always be false. I have gotten direct confirmation from Uwe that this does solve the problem. So based on Michael's statement (which I interpret as a +1) and Uwe's statement that it does help, I'm OK with committing it. I will schedule it for 3.2.1 though in order to minimize risk with the release ongoing (I cannot prove for sure that fScrollLock will always be false in open source).
Created attachment 170909 [details] Patch with Copyright Contributor Line
(In reply to comment #4) > This patch looks like a low risk patch. Since it does not change the behavior > whe scroll lock mode is disabled. > > Uwe, does this fix make scroll lock usable? Yes, it does. The result of the patch is that the - Visible area of the widget stays at the same scrolling position and - The vertical scroll bar does not jump. It stays in position and is updated while the output is appended below the visible area.
The fix is imported for the Wind River commercial product. We have a customer report for this (WR internal reference CQ:WIND00215180) and our guidelines request fixing the issue in the next possible release vehicle. To achieve this, we require to put this into TM-Terminal 3.2.
Thanks Uwe - I have opened bug 315529 requesting a backport of this for the Wind River commercial product. For the Helios Stream though, I would still prefer waiting with this for 3.2.1. I've been bitten by late-binding fixes before, and in this case I don't see the value of pushing this into Helios.
Created attachment 170914 [details] Complete patch, also enabling the Scroll Lock toolbar button Attached patch includes Uwe's original fix, and also enables the "Scroll Lock" toolbar and menu contributions (including the necessary docs update to do so). I found that there is still one inconsistency with this: When I have multiple terminal connections open inside one terminal view, and I enable "scroll lock" on connection 1, then it only applies to connection 1; but when switching to connection 2, the state of the button/menu still indicate scroll lock on (although it is off).
Given that this is a new UI contribution which we better have in 3.2 than in 3.2.1, I might be pursuaded allowing this into Helios if - other committers agree (review+) The feature seems to work fine from my testing. It would be great if we could fix the minor inconsistency I mentioned. The value of having this in Helios seems to outweigh the risk putting it in - there is no API involved, it looks good so far, and in case we run into minor bugs these can be fixed in 3.2.1.
Created attachment 170915 [details] patch v3 This patch fixes the state of the scroll lock action when switching connections inside one view instance; it also updates some copyright dates in the documentation. I also thought that since this is a user-visible new feature, we need to increase the "minor" version of the terminal.view plugin and feature. The terminal widget plugin remains at a micro increment only, since only bug fixes were made. By now, I really believe that this should go into 3.2RC4. Committers (Uwe, Michael), please review and approve the patch.
Looks good and works fine. I've tested it integrated with our product.
Released, please verify with I20100603-0700. Michael and Toni, I'd still like to get your opinion on the fix.
looks good for me
Looks reasonable. For simplicity and consistency, I would have put the scrollY(getVerticalBar()); scrollX(getHorizontalBar()); inside scrollToEnd() which already tests for fScrollLock, but that's just cosmetics.
Created attachment 171097 [details] move code into scrollToEnd() Thanks Toni - if attached additional patch is what you had in mind, I'll commit it.
(In reply to comment #17) > Thanks Toni - if attached additional patch is what you had in mind, I'll commit > it. Yes, that's what I had in mind.
Released Toni's cleanup / simplification.
CQ:WIND00215180 We have found an understandable but unexpected issue with the scroll lock feature, by exposing it via SSH to the following shell script: #!/bin/sh X=1 while true ; do X=`expr $X + 1` echo "Hello $X" done Running this script, the "scroll lock" feature does not work - - the problem with the test case is that new lines are printed so quickly, that the Terminal Widget's buffer runs over. Fix: Window > Preferences > Terminal : Set "Terminal Buffer" to 100000 lines Now, scroll lock works as expected even with this case (until 100000 lines are reached). The point is that when the terminal buffer size is exhausted, new lines are being added to the buffer and removed at its beginning, since we have a ring buffer. As a consequence, the "locked scroll location" always remains at the same place while the buffer under it gets rotated. Is this expected behavior, or should the scroll lock position rotate with its underlying source line when the buffer runs over ... up until the time when the "locked line" is expelled from the buffer? What do others think?
I have filed bug 316981 to track the "scroll lock when buffer runs over".
