Version: 2.1 (using KDE 3.1.0) Installed from: (3.0) Compiler: gcc version 2.95.4 20011002 (Debian prerelease) OS: Linux (i686) release 2.4.20 It seems that whenever kate jumps to a line that is currently not on screen, the text area should be redrawn but is not. Best example to see this is when using the search or replace dialog. Create an empty file, put the word 'hello' in the middle of line 200, then go back up to line 1 and search for 'hello' by pressing ctrl+f, entering hello and pressing enter. The search-window should then vanish and the word 'hello' in line 200 should be selected. But it does not. Instead, the window is still visible (although not there), and it moves with the rest of the document when scrolling. Somehow, the graphic of the window became part of the text window and is just not re/overdrawn until you select that area or scroll it off screen. However, this does not happen every time, sometimes the text area seems to be redrawn correctly, sometimes it doesn't. Maybe a bad timing? You may have to try the above quite a few times until the error is visible. Again, no screenshot, because kate seems to be redrawing itself whenever I try doing a screen.
I know about this bug too :) but again I think it not a bug in Kate... Kate redraws whenever Qt tells it to. My theory to what's happening is that Qt schedules a redraw of the area under the dialog, then we scroll the view, and then we get the redraw request. Unfortunately Qt doesn't translate the redraw requests upon scrolling the view as it should (in my opinion). I might have a dig in Qt to see if I can come up with a fix.
Actually, have you seen this bug in Kate itself, or something that embeds Kate like Gideon/KDevelop3?
Subject: Re: further text area redrawing problems Seen it directly in kate. I've tried to reproduce it in kwrite, but that doesn't work. Just happens in kate.
Hi, I can't reproduce this with the search example, but I do have this problem and I can reproduce it like so: Go to the bottom of the screen and paste about 10 lines of text by right clicking and selectin paste. The menu will stay visible.
Subject: KDE_3_1_BRANCH: kdelibs/kate/part CVS commit by rodda: Temporary band-aid fix for bug 53392: further text area redrawing problems I think this is a Qt bug (pending paint events not translated by a call to QWidget::scroll()), have asked the trolls... CCMAIL:53392@bugs.kde.org M +13 -10 kateviewinternal.cpp 1.150.2.13 --- kdelibs/kate/part/kateviewinternal.cpp #1.150.2.12:1.150.2.13 @@ -387,4 +387,7 @@ void KateViewInternal::scrollPos(KateTex if (QABS(viewLinesScrolled) < lines) { + // temporary fix for scroll() not translating pending paint events + KApplication::kApplication()->processEvents(); + updateView(false, viewLinesScrolled); int scrollHeight = -(viewLinesScrolled * m_doc->viewFont.fontHeight);
is fixed now, or ? at least as much as we can do without modifying qt ?
No. Basically the solution trolltech advised me to use is to change all instances of widgets disappearing before scroll to deleteLater() or single-shot timer to hide(), so the expose happens after the scroll. This is not nice because it means getting all 3rd party apps and modifying them as appropriate as well. I am still pressing my case to Trolltech (I believe this is indeed a bug because you just can't use scroll() and expect that your widget will be 100% robust), but I'm doubtful it will get fixed cleanly there. As this is not a great flaw I'm basically waiting until I get a verdict, or until 3.2 draws near...
*** Bug 56673 has been marked as a duplicate of this bug. ***
any newer infos about that from trolltech ?
I have worked around it by explicitly repainting that area per hand, works nicely, too, make me more happy than the processEvents will move this to wish: fix it proper in qt
Subject: kdelibs/kate/part CVS commit by rodda: A few changes: Trivial fixes: * correctly determine whether a position is selected in block mode * merge single on-the-spot actions into one undo action * delete obsolete commented out text * fix makevisible behaviour when called from outside the view and the cursor is already in the correct place Not-so-trivial: * fix redraw when the widget is obscured before a scroll and has to deal with repaint races (fixes bug 53392, which I think has a dupe in the kdevelop bugs) - reviewed by Christoph and Anders CCMAIL:53392-done@bugs.kde.org M +4 -20 katedocument.cpp 1.655 M +24 -2 kateviewhelpers.cpp 1.5 M +57 -10 kateviewinternal.cpp 1.268 M +3 -0 kateviewinternal.h 1.93
*** Bug 61534 has been marked as a duplicate of this bug. ***