This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102445/

On August 26th, 2011, 5:20 p.m., Thomas Lübking wrote:

kwin/effects/taskbarthumbnail/taskbarthumbnail.cpp (Diff revision 1)
void TaskbarThumbnailEffect::slotWindowAdded(EffectWindow* w)
122
    effects->addRepaint(w->rect());
No idea about the tabstrip, but this should in general likely be

   effects->addRepaint(w->geometry());

yesno?

On August 27th, 2011, 6:40 a.m., Martin Gräßlin wrote:

I think both is wrong as we need to repaint the thumbnail area. I'm pretty sure that it worked for sebas because on active the geometry of each window would include the thumbnail area.

Oh and obviously the easiest solution to the question would be: w->addRepaintFull() ;-)

On August 27th, 2011, 10:09 a.m., Thomas Lübking wrote:

Oh and obviously the easiest solution: EVIL TRAP!
-------------------------------------------------

void Toplevel::addRepaintFull()
{
    repaints_region = decorationRect();
    workspace()->checkCompositeTimer();
}

and now guess who's gone in the next event cycle / paint (despite reviewboard's display, this is in the deleted slot) :-P

On August 27th, 2011, 10:14 a.m., Martin Gräßlin wrote:

*cough* I thought this results directly in a call to Workspace. /me thinks of updating the docu for EffectWindow::addRepaint(Full)()
Here the proper patch - please give it a try if it fixes the problem for you

diff --git a/kwin/effects/taskbarthumbnail/taskbarthumbnail.cpp b/kwin/effects/taskbarthumbnail/taskbarthum
index c1cfdd1..5aa6048 100644
--- a/kwin/effects/taskbarthumbnail/taskbarthumbnail.cpp
+++ b/kwin/effects/taskbarthumbnail/taskbarthumbnail.cpp
@@ -119,6 +119,13 @@ void TaskbarThumbnailEffect::slotWindowAdded(EffectWindow* w)
 
 void TaskbarThumbnailEffect::slotWindowDeleted(EffectWindow* w)
 {
+    foreach (EffectWindow *window, thumbnails.uniqueKeys()) {
+        foreach (const Data &thumb, thumbnails.values(window)) {
+            if (w == effects->findWindow(thumb.window)) {
+                window->addRepaint(thumb.rect);
+            }
+        }
+    }
     thumbnails.remove(w);
 }

- Martin


On August 26th, 2011, 2:57 p.m., Sebastian Kügler wrote:

Review request for kwin.
By Sebastian Kügler.

Updated Aug. 26, 2011, 2:57 p.m.

Description

When thumbnails are shown and a window is deleted, only the other, still existing windows are being repainted. The deleted window stays on the screen until repainted. In the typical taskbar thumbnail case, that's not a problem, since the thumbnail of a deleted window is just never shown (no tooltips in that case).

In the Windowstrip applet, which is used as application switcher in Active, when the window strip is not as wide as the screen, the windows shift left, leave a blank space on the right which doesn't get cleared, so a ghost of the window stays on screen.

The patch addresses this by adding the rect of the vanishing window to the area to repaint in the next frame, essentially clearing exactly the part that we want.

I'd like to commit to master and 4.7.

Testing

start plasma-contour, with 3 open windows, close on of them from the windowstrip.

Without the patch, you'll see 3 windows painted, the third of which gets cleared only after an artificially triggered repaint, e.g. by dragging the rest of the windows over it.

With the patch, behaviour is as expected, the preview of the rightmost window is cleared.

Diffs

  • kwin/effects/taskbarthumbnail/taskbarthumbnail.cpp (7761ba5)

View Diff