Version: (using KDE Devel) Installed from: Compiled sources Compiler: gcc 3.2 OS: Linux I noticed this bug wile trying to select some text while compiling some source code. Basically, I scrolled up a tad in konsole so that text was being added below my window, but what was in the window was not moving. I then tried to select some of this stationary text, but the selection area was mofified when new text was output making it difficult for me to make my selection.
Works here. You don't have a limited history and the part you wanted to select was part of the history which got deleted (watch the scrollbar moving!)?
Sorry for not responding sooner. I never noticed you responded. It still does not work for me (cvs last night). This is functionality that worked in 3.0 but is still broken in cvs. Basically, you just start a process that dumps text to the screen at a fairly rapid rate (say one line a second). Now scroll up just a tad so that the text in the window does not move (ie, the text is being aded below the window). Now, try to select some text on the screen, it is difficult because the selection start point is being moved up in the window when text is aded to the end of the buffer.
Did you read the question in it? What history settings do you use, try to increase the line settings or set it to unlimited.
Subject: Re: selecting text difficult while more output is written to the console I don't think you are understanding my explaination which is why I repeated it. It seemed like you thought I couldn't select the text because it was beyond the history. The problem exists with default history settings (1000 lines) and any other finite history size. On Thursday November 28 2002 04:51, you wrote: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > You are a voter for the bug, or are watching someone who is. > > http://bugs.kde.org/show_bug.cgi?id=50443 > > > > > ------- Additional Comments From binner@kde.org 2002-11-28 13:51 ------- > Did you read the question in it? What history settings do you use, try to > increase the line settings or set it to unlimited. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE95iKjgKpk8srJOlIRAmElAJ4lEUr3BpP3vQBJRGHF3fT9S6uNjgCfQYOB FdrjByF15jS2OeUHJC2VyNY= =6Nti -----END PGP SIGNATURE-----
Did you highlight text with triple clicking? Please try again with current CVS.
No, I'm left-click, dragging... and it's still there with 3.1.1a... is the update in the KDE_3_1_BRANCH that you want me to try?
I don't think that something changed in KDE_3_1_BRANCH which could fix this, but feel free to try. Is this reproducible everytime? Do you use some weird compiler parameters (last hope)? :-)
This bug is still 100% reproducable on KDE 3.1.93. Is anyone still working on this?
Also reproducable here with Debian's 3.2.2. To test I ran 'vmstat 1'. When attempting to select part of a particular line the screen stops scrolling (good). However the beginning of my selection doesn't stay put. Rather it moves -down- at one line per second (ie. stays the same number of lines from the bottom of the scrollback). It happens no matter what the type of selection is (single, double, triple click).
I can't reproduce this on CVS HEAD. I'm using left-click to select the text... works for me. No matter what I do and what I select, it works. Would the qt version matter? I'm running qt-3.3.2.
The Debian KDE packages currently depend on version 3.2.3 (or newer). As it happens 3.2.3 is the newest (and in fact only) version of qt3 available in Debian.
I have similar problem - when new text is comming (not moving what I see) the selection is "scrolling". You can look at http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133860 for details, but in short: 1. type 'while /bin/usleep 50000; do echo $RANDOM; done' 2. wait to have 2/3 screens full with random numbers. 3. Press Shift-Up to get one screen up and wait some seconds. 4. double-click with the left mouse button a line, hold the left button and try moving up or just left-right...
That redhat bug report is for KDE3.3.0. I just tested CVS/HEAD (soon to be KDE3.4) again and this bug is fixed.
I tested with FC3 + KDEee 3.4 and FC4t2 and the bug is still there. I did exactly what I've described in comment # 12 and the bottom line of the selection started to move down.
I just tried again following #12 and it works fine here. I don't know why people are having problems... What version of Qt? Try starting a default konsole (move $KDEHOME/share/config/konsolerc out of the way).
Aha. It seems that the bug isn't triggered unless your scrollback is full. Try 'find /proc' a few times and try again. :P My test: - fill scrollback - vmstat 1 - Try one of more of: - single or double click near the middle of the window, and slowly drag up and down the window. About one second after each time the pointer crosses a point near the anchor point, the anchor point will move down. - triple click near the top of the window, and drag downwards (at, say, 2 lines per second). I see the anchor point (ie. the other end of the selection) move down at exactly 1 line per second. I hope this helps.
Yea, O.K. I managed a couple of times to get the selection to move.... I couldn't really see any way of 100% duplicating. Before I think I was moving the mouse too fast... going to be hard to fix if there isn't a easy way to reproduce.
I reproduced this problem with konsole 1.4.1, kde 3.3.1-2.9.FC3 Red Hat and qt-3.3.4-0.fc3.0 at work. I first created a new account and then tested as the new user and did 'rm -rf .kde' too. The trick is to to cat a big file (cat /usr/share/dict/words) so you can have you konsole history buffer full (here the default is 1000). If the buffer is not full you can not duplicate this bug. After this type 'while /bin/usleep 500000; do echo $RANDOM; done', tripple-click a line (so you have whole line selected) and start moving your mouse slowly left and right on the same line. The bottom selection line moves with the output (1 more line of output, 1 more line selected downwards). To see the selection moving try tripple-clicking the 2-nd or the 3-rd visible line (the screen stops scrolling after this). In short: 1. make sure your history is limited to some reasonable number of lines (less than `wc -l /usr/share/dict/words`). 2. cat /usr/share/dict/words; while /bin/usleep 500000; do echo $RANDOM; done Is this reproducible now?
Yea, it appears that the triple-click is what I was missing. I can't reproduce this bug without that. I never use triple-click myself so I've never ran into this bug. 1. Set History lines to 1000 2. cat /usr/share/dict/words 3. while /bin/sleep 1; do echo $RANDOM; done # I don't have usleep on my system 4. Shift-Up 5. Triple click and move mouse slowly left/right.
Link to Red Hat's bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133860
To reproduce using single/double click you have to remember that the selection only jumps after you drag across a certain vertical position in the window. If you're scrolled back that point moves down the window until it's off the bottom of the window, at which point the bug is no longer reproducable. If you're not scrolled back the point stays in the same location on the screen. ie. Try up/down movements instead of left/right.
For reference, following #19, the viewing screen is not moving and the scrollbar is. In the code in TEWidget.cpp the scrollbar->value is used to determine the selection. Since the scrollbar is moving, this causes the end of the selection to move as well. I think there are other issues as well.
This issue might be solved by automatically enabling SCROLL LOCK while the user is selecting text. Currently you can work around the text selection problem by manually enabling SCROLL LOCK. Selections won't move until you disable SCROLL LOCK again.
Still here, one year later and kdebase-3.5.6-0.1.fc6
Bug still there in KDE 4.1.0 :-) I mostly run into this problem when analyzing medium-rate network traffic with tcpdump and/or tshark. I keep it running until I see something suspicious, then I scroll up (output is now a stable subset from the scrollback buffer) and try to select various things, e.g. the host's address with the mouse (go to the beginning of the address, hit LMB, move to the end of the address, release LMB). If between pressing and releasing the mouse button the running program has sent another line of output the window output is still the same (the position in the buffer moved, but the visible part is still the same) the beginning of my selection is moved one line down. Example: Line 1 ABCDEFGHIKLMNOPQRSTUVWXYZ Line 2 ABCDEFGHIKLMNOPQRSTUVWXYZ I start selecting at C in Line 1 and move forward to Z (selection would be CDEFGHIKLMNOPQRSTUVWXYZ). However, when during that selection a new line is outputed the selection reads ....Z\nABC, the old beginning mark is moved one line down and is now the end mark. Setting the scrollback buffer to unlimited fixes the problem as well.
I think this bug is fixed. Haven't noticed anything like this lately (and did notice it back when it was a problem).
Same bug here, in KDE 4.6.3. Pressing scroll lock doesn't help. Setting history to unlimited works.
I am using konsole 2.6.4 with kde 4.6.5 and it works for me. Using 1000 for scrollback and I can select text while the scrollbar is moving and the text is static.
I think this problem is fixed in recent version of KDE4 konsole. If someone still have this problem in recent version, please leave your comment.
Still happens with konsole 23.04.3. I did: 0. Adjust Scrollback says I have 10000 lines scrollback. 1. while ((1)) ; do echo $RANDOM ; sleep .001 ; done 2. Scroll to top of buffer, so I can see when it starts overflowing. 3. When it overflows, scroll to the middle of the buffer. 4. Even though the numbers on the screen aren't moving, trying to select with click+drag or triple-click selects some random lines further down. The selected area flickers wildly all over the place (but only under the area that should have been selected), if slowly moving the mouse during a click+drag, even though the rest of the window is static. P.S. Not sure what just happened to being able to vote on bugs.