--===============0745066087== Content-Type: multipart/alternative; boundary="===============7333278700408141473==" --===============7333278700408141473== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102118/#review5261 ----------------------------------------------------------- This review has been submitted with commit b296f1199b6c10d03ebd704fd27d516d= f783afb6 by Matthias Fuchs to branch master. - Commit On July 28, 2011, 5:02 p.m., Matthias Fuchs wrote: > = > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/102118/ > ----------------------------------------------------------- > = > (Updated July 28, 2011, 5:02 p.m.) > = > = > Review request for Plasma and Aaron J. Seigo. > = > = > Summary > ------- > = > If there are multiple screens with different resolutions or which > are not alligned the same way then it could happen that popups at > the edge were drawn (partially) offscreen. > This patch fixes that issue. > = > I have the feeling that the code in this method is really ugly, I wonder = if there are plans to refactor it or to clean it up? > = > NOTE: I don't know if this patch might cause problems if there are animat= ions that are supposed to start offscreen etc. So please you with more insi= ght look at the patch to see if there could be some negative side effects. > = > = > =3D=3D=3D=3D > I just realised that the real problem is most likely that the existing co= de assumes that the screen begins at 0,0 e.g: > default: > if (pos.y() - s.height() > 0) {//if 0 was replaced with screenRec= t.top() it would also work in the specific case described in the report > pos.ry() =3D pos.y() - s.height(); > } else { > pos.ry() =3D pos.y() + (int)actualItem->boundingRect().size(= ).height() + 1; > } > = > = > This addresses bug 276336. > http://bugs.kde.org/show_bug.cgi?id=3D276336 > = > = > Diffs > ----- > = > plasma/corona.cpp 4afef7b = > = > Diff: http://git.reviewboard.kde.org/r/102118/diff > = > = > Testing > ------- > = > = > Thanks, > = > Matthias > = > --===============7333278700408141473== 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/102118/ 

This revie=
w has been submitted with commit b296f1199b6c10d03ebd704fd27d516df783afb6 b=
y Matthias Fuchs to branch master.

- Commit


On July 28th, 2011, 5:02 p.m., Matthias Fuchs wrote:

Review request for Plasma and Aaron J. Seigo.
By Matthias Fuchs.

Updated July 28, 2011, 5:02 p.m.

Descripti= on 

If there are multiple screens with different resolutions or =
which
are not alligned the same way then it could happen that popups at
the edge were drawn (partially) offscreen.
This patch fixes that issue.

I have the feeling that the code in this method is really ugly, I wonder if=
 there are plans to refactor it or to clean it up?

NOTE: I don't know if this patch might cause problems if there are anim=
ations that are supposed to start offscreen etc. So please you with more in=
sight look at the patch to see if there could be some negative side effects.


=3D=3D=3D=3D
I just realised that the real problem is most likely that the existing code=
 assumes that the screen begins at 0,0 e.g:
default:
        if (pos.y() - s.height() > 0) {//if 0 was replaced with screenRe=
ct.top() it would also work in the specific case described in the report
             pos.ry() =3D pos.y() - s.height();
        } else {
             pos.ry() =3D pos.y() + (int)actualItem->boundingRect().size=
().height() + 1;
        }
Bugs: 276336

Diffs=

  • plasma/corona.cpp (4afef7b)

View Diff
--===============7333278700408141473==-- --===============0745066087== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel --===============0745066087==--