If you move a tab, the terminal emulator area fails to redraw and becomes a solid black. Clicking in it triggers a redraw. This is a longstanding bug that I could never remember to file. It affects Konsole 4.8.1 and if I recall, 4.8.2 as well. I switched to Gentoo stable shortly after the 4.8.2 upgrade, so I not 100% certain that I checked, but I would be surprised if it were fixed.
> if I recall, 4.8.2 as well. Yes, 4.8.2 is affected as well. I am using yakuake, and there I don't get this behaviour. Interestingly only moving by mouse triggers the error. Use "Ctrl+Shift+[right,left]", and everything goes well.
(In reply to comment #0) > If you move a tab, the terminal emulator area fails to redraw and becomes a > solid black. Clicking in it triggers a redraw. This is a longstanding bug > that I could never remember to file. Interesting... We had this bug already once, but it was fixed in KDE 4.4.4 (bug 301620). I dont see the problem here either. Either the fix did not cover all corner cases or a regression occurred. Please report this upstream, and mention also the old upstream bug...
> Either the fix did not cover all corner cases or a regression occurred. > Please report this upstream, and mention also the old upstream bug... Upstream seems to not have tried to catch issues with zsh. According to the upstream bug (https://bugs.kde.org/show_bug.cgi?id=164099#c13, reopened 2010-11-28), it still occurs, but only with zsh - that's what I use, and probably Richard, too. So I started bash and all issues are gone.
Created attachment 308293 [details] Hack to fix the tsh blanking Just put a usleep(1) between the window-resizings in Session::refresh() and zsh won't blank anymore... But as the comment in the Session::refresh() says, the Developers also don't think their solution is correct, so.... a Hack for the Hack ;)
Upstream patch: http://quickgit.kde.org/?p=konsole.git&a=commit&h=ccfc3f859c5695cc08895570efd0831db0d3b9b0
(In reply to comment #3) > > Either the fix did not cover all corner cases or a regression occurred. > > Please report this upstream, and mention also the old upstream bug... > Upstream seems to not have tried to catch issues with zsh. According to the > upstream bug (https://bugs.kde.org/show_bug.cgi?id=164099#c13, reopened > 2010-11-28), it still occurs, but only with zsh - that's what I use, and > probably Richard, too. So I started bash and all issues are gone. I am using GNU Screen with bash.
(In reply to comment #5) > Upstream patch: > http://quickgit.kde.org/?p=konsole. > git&a=commit&h=ccfc3f859c5695cc08895570efd0831db0d3b9b0 I have applied this against Konsole 4.8.1. It does not address the issue when GNU Screen is used, but increasing the delay to 100 microseconds does.
(In reply to comment #7) > when GNU Screen is used, but increasing the delay to 100 microseconds does. Upstream increased to 500 microsecs.
(In reply to comment #8) > (In reply to comment #7) > > when GNU Screen is used, but increasing the delay to 100 microseconds does. > Upstream increased to 500 microsecs. It turned out that 100 microseconds was not enough. If running irssi inside screen inside ssh, the screen will not repaint. I think we need a different approach. With SSH in the equation, the time necessary to wait should be arbitrarily large.
(In reply to comment #9) > I think we need a different approach. Of course, but that's what the comment in Session::refresh() says: // attempt to get the shell process to redraw the display // // this requires the program running in the shell // to cooperate by sending an update in response to // a window size change // // the window size is changed twice, first made slightly larger and then // resized back to its normal size so that there is actually a change // in the window size (some shells do nothing if the // new and old sizes are the same) // // if there is a more 'correct' way to do this, please // send an email with method or patches to konsole-devel@kde.org So this patch is a hack to make the hack work better, but of course not a nice solution.
Thanks for the reference. I am a bit confused why we have this problem when dragging and dropping tabs, but not when highlighting new tabs. I do not think that we should have a bug in one case and perfect behavior in another. I might be inclined to think that the hack is working in one instance, but failing in another, but the fact that SSH is enough to trigger it in one instance despite the second hack makes me suspect otherwise. I haven't had time to look at the fine code, so my suspicions might be incorrect, but these are my thoughts.
Fixed in 4.8.3 which comes out real soon now (this week). :)8
