(This is probably a zvt bug, hence gnome-libs. I don't have Pinstripe yet, hence beta 3.) Gnome terminal does not always correctly paint itself on scroll when a portion of its window is covered (as far as I can see, it has to be the lower right portion). To reproduce: Fire up a gnome-terminal (mine are about 130x35, but I don't think it's size-dependant). Cover a few lines and a few dozen columns of the bottom right corner. Hit return until you're causing the window to scroll. Run a command which will produce a few lines of output (ls -l in a smallish directory does it for me). Some of the output lines will be missing or incomplete. Drag another window over it and they will paint OK.
Also a problem in beta5 - highly annoying
This defect is considered MUST-FIX for Winston Gold-release
This one is nasty. We have a theory which patch created the bug, but that patch fixed another similar bug, so simply removing it isn't going to work.
Does merging the expose events and then forcing a repaint of a rectangle the width of the expose area and the height of the window fix this. I think it will if the clip rectangle is adjusted for this.
The part that doesn't get redrawn shouldn't be getting an expose; the stuff that gets graphics exposes gets redrawn properly. At least, with the way to reproduce it I've found, the failure to redraw is on the left side of the term, not hte side that's partially covered...
I can reproduce this problem (or one very much like it) without partially covering the window. New gnome-terminal, "while :; do date; done", and on lines which cause a scroll only the first three characters or so are drawn.
I've seen this too on pinstripe, but it doesn't happen on every installation -- it appears to be affected by the video mode XFree is running in.
This bug is really horrible; the gnome-terminal redraw code is insanely complicated, and changing any of it looks likely to break something else. We've spent many hours looking at fixing this already with no very good idea how to fix it. The only "definitely will work" solution so far is to always redraw the whole terminal on scroll, but then we have a "gnome-terminal is pretty darn slow" bug.
It's still present in the latest available packages (internally) and it makes many operations really, really hard. Better slow than non-working.
OK I'm putting the "slow but works" patch into the test tree. Will close the bug when it goes into the real tree. I know someone is going to flame us about how "Red Hat made gnome-terminal slow" or something, sigh.
Still a problem using all the latest and greatest.
Actually, the problem here seems to be that it doesn't want to start a new line... painting everything on the same line OK, though ;)
Is it at least better? If it's better now, we'll leave it slow, if it's not better, it may as well be fast so I'll back out the attempted fix. We can't fix the draw code though; there is just no way to figure it out and feel confident about it in 7 days, it's a fairly major rewrite-lots-of-code kind of project. i.e. if slowing it down didn't fix it, it ain't getting fixed.
Yes, it's better. It does repaint correctly now, it just doesn't add a newline so it goes on writing from the start of the current line.
The solution here is a reworked terminal widget. My time estimate on this task is 1-2 months. Not planned in the immediate future. Though I wouldn't mind seeing it done.