[vbox-dev] [SPAM] 5.0.16 regression: window position not saved

[Santosh Kumar]

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 at virtualbox.org
>>>> https://www.virtualbox.org/mailman/listinfo/vbox-dev
>>>>     
>>>>     
>>>>     
>>>>    
>