--===============1011012812145352922== Content-Type: multipart/alternative; boundary="===============0609717258697992271==" --===============0609717258697992271== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit > On March 27, 2014, 5:57 p.m., Marco Martin wrote: > > "break" as in.. ? > > David Edmundson wrote: > Add kickoff to the desktop. Resize it so it's compact then hover over it. Broken. > > Marco Martin wrote: > uhm, works for me? http://wstaw.org/m/2014/03/27/plasma-desktopLW1833.png > > Marco Martin wrote: > ah, no, apparently depends from where the applet is > > Marco Martin wrote: > well, i don't see where locateinsideparent should be true. > > right now locateinsideparent = true if the window is a desktop.. and that doesn't seem to make any sense? > > if i remove completely locateinsideparent everything seems to just work? > > David Edmundson wrote: > Without ever setting it to true WidgetExplorer won't work when loaded on a second screen which is to the right of the main screen. > > We would try to position it to the left outside the parentItem (which is the entire screen) so it appears on the wrong screen. > The fact that it works in any other case is just a fortunate set of circumstances as the logic to make sure it fits in the screen ends up putting it back. > > I will need to add the locateInsideParent: true to the relevant part of in kde-workspace. > > Marco Martin wrote: > hmm, to me the proper solution would be trying to always put the dialog in the same screen as the parent view > > David Edmundson wrote: > >the proper solution would be trying to always put the dialog in the same screen as the parent view > > Which is why we need the locateInsideParent. Without it we explicitly calculate that the best position for the widget explorer dialog is off the screen. Calculating something should be completely off the screen and then trying to manipulate it back onto the right screen isn't a very proper solution. We need to fix the initial calculation to be in the right place to start with. > > Relative to the parent the ideal position for widget explorer and any other popup are completely different. One is on top of the parent, the other is outside it. We need a way to tell dialog that as determining it automatically (what we had before this patch) doesn't work safely enough. > > > > Bump. If you're still not convinced ping me on IRC sometime so I can persuade you that I'm totally right. :) - David ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117121/#review54355 ----------------------------------------------------------- On March 27, 2014, 5:34 p.m., David Edmundson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/117121/ > ----------------------------------------------------------- > > (Updated March 27, 2014, 5:34 p.m.) > > > Review request for Plasma. > > > Repository: plasma-framework > > > Description > ------- > > Add property to determine if popups should be inside or outside the parentItem > > For some cases of dialog we want to position within the parent item for > example widget explorer. For popup applets on the desktop the dialog > should appear outside of the parentItem. > > Currently we try to determine it automatically from the window type of > the parentItem. This worked fine for widget explorer and panels, but > breaks for popup applets on the desktop. > > > Diffs > ----- > > src/plasmaquick/dialog.h 3804d18 > src/plasmaquick/dialog.cpp 77c0c8c > > Diff: https://git.reviewboard.kde.org/r/117121/diff/ > > > Testing > ------- > > > Thanks, > > David Edmundson > > --===============0609717258697992271== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit
This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117121/

On March 27th, 2014, 5:57 p.m. UTC, Marco Martin wrote:

"break" as in.. ?

On March 27th, 2014, 7:43 p.m. UTC, David Edmundson wrote:

Add kickoff to the desktop. Resize it so it's compact then hover over it. Broken.

On March 27th, 2014, 7:51 p.m. UTC, Marco Martin wrote:

uhm, works for me? http://wstaw.org/m/2014/03/27/plasma-desktopLW1833.png

On March 27th, 2014, 7:56 p.m. UTC, Marco Martin wrote:

ah, no, apparently depends from where the applet is

On March 27th, 2014, 8 p.m. UTC, Marco Martin wrote:

well, i don't see where locateinsideparent should be true.

right now locateinsideparent = true if the window is a desktop.. and that doesn't seem to make any sense?

if i remove completely locateinsideparent everything seems to just work?

On March 27th, 2014, 9:13 p.m. UTC, David Edmundson wrote:

Without ever setting it to true WidgetExplorer won't work when loaded on a second screen which is to the right of the main screen.

We would try to position it to the left outside the parentItem (which is the entire screen) so it appears on the wrong screen. 
The fact that it works in any other case is just a fortunate set of circumstances as the logic to make sure it fits in the screen ends up putting it back.

I will need to add the locateInsideParent: true to the relevant part of in kde-workspace.

On March 27th, 2014, 9:26 p.m. UTC, Marco Martin wrote:

hmm, to me the proper solution would be trying to always put the dialog in the same screen as the parent view

On March 27th, 2014, 9:45 p.m. UTC, David Edmundson wrote:

>the proper solution would be trying to always put the dialog in the same screen as the parent view

Which is why we need the locateInsideParent. Without it we explicitly calculate that the best position for the widget explorer dialog is off the screen. Calculating something should be completely off the screen and then trying to manipulate it back onto the right screen isn't a very proper solution. We need to fix the initial calculation to be in the right place to start with.

Relative to the parent the ideal position for widget explorer and any other popup are completely different. One is on top of the parent, the other is outside it. We need a way to tell dialog that as determining it automatically (what we had before this patch) doesn't work safely enough.




Bump.
If you're still not convinced ping me on IRC sometime so I can persuade you that I'm totally right. :)

- David


On March 27th, 2014, 5:34 p.m. UTC, David Edmundson wrote:

Review request for Plasma.
By David Edmundson.

Updated March 27, 2014, 5:34 p.m.

Repository: plasma-framework

Description 

Add property to determine if popups should be inside or outside the parentItem

For some cases of dialog we want to position within the parent item for
example widget explorer. For popup applets on the desktop the dialog
should appear outside of the parentItem.

Currently we try to determine it automatically from the window type of
the parentItem. This worked fine for widget explorer and panels, but
breaks for popup applets on the desktop.

Diffs

  • src/plasmaquick/dialog.h (3804d18)
  • src/plasmaquick/dialog.cpp (77c0c8c)

View Diff
--===============0609717258697992271==-- --===============1011012812145352922== 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 --===============1011012812145352922==--