Hi, Yes, you are right. I misunderstood the documentation of "contains()" API. Thanks for clarification, I will take care of it in the fix.
Thanks and Best Regards Santosh On 10.03.2016 19:12, Власов Константин wrote: > Hi, Santosh. > > You are welcome. Sorry that I didn't notice an existing function, of course > reusing existing code is better. > > But I'm not sure I'm following you. Proper containment is just condition that > the border of the tested rectangle must be "submerged" into the insides of the > external rectangle, that their borders may not touch each other. But even when > proper=false, contains() returns true only for real, valid containments. > > Example: > > #include <QtCore> > int main(void) > { > QRect r(0, 0, 10, 20); > QRect s(0, 0, 10, 30); > printf("Contains: %d\nContains proper: %d\n", > s.contains(r, false), > s.contains(r, true)); > return 0; > } > > If prints: > > Contains: 1 > Contains proper: 0 > > You can see by the coordinates that rectangle (0,0)-(10,20) is absolutely > inside > (0,0)-(10,30), that's why the normal containment returns true. But since there > is no gap between their respective left and right borders, the 'proper > containment' returns false. So if you require proper=true, you treat this > example as invalid containment, as if the 'r' rect was not inside the 's' > rect, > which does not look right to me. > > From my point of view, normal containment is more logical here than the > proper > one. What proper=true requires is not only the containment, but actually that > there must be a gap between the borders, that the internal rect must be at > least > 1 pixel away from all the borders of the external rect. > > I don't see why you see this as a requirement. I myself would prefer putting > my > window exactly at the edge of the screen, nice and smooth, and not have 1 > pixel > gap between my window and the screen edge... > > >> I was talking about implementing fix something like in your second patch. >> Though we already have utility function which does the same job as your >> moveRectInto() method, so we will use that already existing method. >> Also our idea was to make even *partially off-screen" windows to be >> fully visible again, so that's why >> "!availableGeometry.contains(geometry, true)" is required (notice >> passing true)). >> Thanks for finding the issue and helping to push the solution in right >> direction. >> Thanks and Best Regards >> Santosh >> On 10.03.2016 12:46, Власов Константин wrote: >>> Hi, Santosh. >>> >>> Would you mind describing a bit more detailed what exactly looks wrong in my >>> solution, please? >>> >>> Actually, I thought that the idea of centering the window is not so good. >>> Suppose I close the window a tiny bit outside of my screen edge (maybe not >>> even >>> noticing it), and next start I'm going to get it centered, totally away >>> from the >>> previous position. I think it would be better to move the window just into >>> the >>> screen so that it located at the very edge it was earlier crossing. >>> >>> Sending you another patch with implementation of this idea, it replaces the >>> previously sent patch. MIT license. >>> >>> >>>> Thanks for noticing the issue. >>>> Our idea was to make off-screen windows to be *fully* visible again in >>>> consistent with default behavior on other platforms. However your >>>> patch does not take care of this fully. >>>> We will fix this from our side. >>>> Thanks and Best Regards >>>> Santosh. >>>> On 09.03.2016 13:40, Власов Константин wrote: >>>> >>>> >>>> >>>> Hi, >>>> There is a regression in 5.0.16: VB window position is not restored >>>> correctly on >>>> start-up. I created a ticket for this: >>>> https://www.virtualbox.org/ticket/15226 >>>> But I think I found the source of the problem and solution to it. >>>> The version 5.0.16 introduces a very strange piece of code: >>>> if (fOk && geometry.intersects(availableGeometry)) >>>> geometry.moveCenter(availableGeometry.center()); >>>> That is: If the currently calculated VB window position intersects with the >>>> screen which contains the window's top left corner, then move the window to >>>> the center of the screen. >>>> Where's logic in that? Of course the window will ALWAYS intersect with the >>>> screen it's top left corner is located on. Therefore, the window will >>>> always be >>>> centered. >>>> I'm not sure what it was intended to implement here. Most probably: If the >>>> window is not fully located within the screen, then move it to the center. >>>> I implemented this solution, quick test showed that it indeed fixes the >>>> problem. >>>> Patch is attached, MIT licensed. >>>> P.S. As you can see, the logWindowGeometry() already uses the same >>>> algorithm, >>>> though I'm not sure why it required proper containment - being just on the >>>> edge >>>> of the screen may be very convenient, and I wouldn't want VB to reset my >>>> window >>>> position from the edge to the center, so I replaced true with false. >>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> vbox-dev mailing list >>>> vbox-dev@virtualbox.org >>>> https://www.virtualbox.org/mailman/listinfo/vbox-dev >>>> >>>> >>>> >>>> > _______________________________________________ vbox-dev mailing list vbox-dev@virtualbox.org https://www.virtualbox.org/mailman/listinfo/vbox-dev