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

[Власов Константин]

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
>>>    
>>>    
>>>    
>>>   


-- 
Bye.                                    With best regards,
                                        Konstantin Vlasov.