--===============7695503069550425260== Content-Type: multipart/alternative; boundary="===============3246001121241844892==" --===============3246001121241844892== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable > On Aug. 26, 2011, 5:20 p.m., Thomas L=C3=BCbking wrote: > > kwin/effects/taskbarthumbnail/taskbarthumbnail.cpp, line 122 > > > > > > No idea about the tabstrip, but this should in general likely be > > = > > effects->addRepaint(w->geometry()); > > = > > yesno? > > > = > Martin Gr=C3=A4=C3=9Flin wrote: > I think both is wrong as we need to repaint the thumbnail area. I'm p= retty 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->ad= dRepaintFull() ;-) > = > Thomas L=C3=BCbking wrote: > Oh and obviously the easiest solution: EVIL TRAP! > ------------------------------------------------- > = > void Toplevel::addRepaintFull() > { > repaints_region =3D decorationRect(); > workspace()->checkCompositeTimer(); > } > = > and now guess who's gone in the next event cycle / paint (despite rev= iewboard's display, this is in the deleted slot) :-P > = > Martin Gr=C3=A4=C3=9Flin wrote: > *cough* I thought this results directly in a call to Workspace. /me t= hinks 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/effe= cts/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(EffectWin= dow* w) = void TaskbarThumbnailEffect::slotWindowDeleted(EffectWindow* w) { + foreach (EffectWindow *window, thumbnails.uniqueKeys()) { + foreach (const Data &thumb, thumbnails.values(window)) { + if (w =3D=3D effects->findWindow(thumb.window)) { + window->addRepaint(thumb.rect); + } + } + } thumbnails.remove(w); } - Martin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102445/#review6035 ----------------------------------------------------------- On Aug. 26, 2011, 2:57 p.m., Sebastian K=C3=BCgler wrote: > = > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/102445/ > ----------------------------------------------------------- > = > (Updated Aug. 26, 2011, 2:57 p.m.) > = > = > Review request for kwin. > = > = > Summary > ------- > = > When thumbnails are shown and a window is deleted, only the other, still = existing windows are being repainted. The deleted window stays on the scree= n until repainted. In the typical taskbar thumbnail case, that's not a prob= lem, since the thumbnail of a deleted window is just never shown (no toolti= ps in that case). > = > In the Windowstrip applet, which is used as application switcher in Activ= e, when the window strip is not as wide as the screen, the windows shift le= ft, 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 th= e 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. > = > = > Diffs > ----- > = > kwin/effects/taskbarthumbnail/taskbarthumbnail.cpp 7761ba5 = > = > Diff: http://git.reviewboard.kde.org/r/102445/diff > = > = > Testing > ------- > = > start plasma-contour, with 3 open windows, close on of them from the wind= owstrip. > = > 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 wi= ndow is cleared. > = > = > Thanks, > = > Sebastian > = > --===============3246001121241844892== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
This is an automatically generated e-mail. To reply, visit: http://git.revie= wboard.kde.org/r/102445/

On August 26th, 2011, 5:20 p.m., Thomas L= =C3=BCbking wrote:

= = =
kwin/effects/taskbarthumbnail/taskbarthumbnail.cpp (Diff revision 1) 
void TaskbarThumbnailEffect::slotWindowAdded(EffectWindow* w)
= 

    122
    
    effects->addRepaint(<=
/span>w->rect());

  


 




  
No idea a=
bout the tabstrip, but this should in general likely be

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

yesno?


 




 
On August 27th, 2011, 6:40 a.m., Martin Gr=C3=A4=C3=9Flin wrote:=


 

  
I think b=
oth 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 woul=
d include the thumbnail area.

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

 






 
On August 27th, 2011, 10:09 a.m., Thomas L=C3=BCbking wrote:

 

  
Oh and ob=
viously the easiest solution: EVIL TRAP!
-------------------------------------------------

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

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

 






 
On August 27th, 2011, 10:14 a.m., Martin Gr=C3=A4=C3=9Flin wrote=
:

 

  
*cough* I=
 thought this results directly in a call to Workspace. /me thinks of updati=
ng 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/effe=
cts/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(EffectWin=
dow* w)
 =

 void TaskbarThumbnailEffect::slotWindowDeleted(EffectWindow* w)
 {
+    foreach (EffectWindow *window, thumbnails.uniqueKeys()) {
+        foreach (const Data &thumb, thumbnails.values(window)) {
+            if (w =3D=3D effects->findWindow(thumb.window)) {
+                window->addRepaint(thumb.rect);
+            }
+        }
+    }
     thumbnails.remove(w);
 }









- Martin






On August 26th, 2011, 2:57 p.m., Sebastian K=C3=BCgler wrote:









 

  


Review request for kwin.


By Sebastian K=C3=BCgler.




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






Descripti=
on 



 

  
   
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 ghos=
t 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 th=
at we want.

I'd like to commit to master and 4.7.

  		
 






Testing <=
/h1>


 

  
   
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 get=
s cleared only after an artificially triggered repaint, e.g. by dragging th=
e rest of the windows over it.

With the patch, behaviour is as expected, the preview of the rightmost wind=
ow is cleared.

  		
 








Diffs=
 


    

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





View Diff





  		
 











  

 



--===============3246001121241844892==--

--===============7695503069550425260==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin

--===============7695503069550425260==--