Re: KRect and KRectF proposal

Hello,

On 4/9/26 7:43 AM, Thiago Macieira wrote:
> On Wednesday, 8 April 2026 07:29:11 Pacific Daylight Time Vlad Zahorodnii
> wrote:
>> Negative width and height are a corner case. I'm sure you can encounter
>> them, e.g. in some drawing applications when the user presses and drags
>> the pointer to draw a rectangle, but I don't think they are so common
>> that the core abstraction needs to handle that. For example, in KWin, we
>> have no valid case where rectangles with negative sizes are okay, and it
>> is a project that uses rectangles heavily.
> I don't know why they were added to QRect/QRectF. It was before the public
> history. But regardless, it's API now and may be in use. So unless you declare
> it broken/misfeature, it should be supported.
Ack, this nuance can be documented, so the difference is more explicit.
>>> Consider:
>>> top() = -0.4999
>>> left() = -0.4999
>>> bottom() = 0.4999
>>> right() = 0.4999
>>>
>>> width() and height() are 0.9998, which clearly rounds to 1.0. But all of
>>> the four coordinates round to 0.
>> Correct, whether it's fine depends on the context though.
> And I'm arguing it shouldn't be context-dependent. You can easily round in
> such a way that it prevents becoming empty. Just round towards positive
> infinity.

The issue is that QRectF::toRect() trying to be helpful is what caused 
the issues in the first place. When looking into fractional scaling 
issues ourselves, we looked for a way to make ::toRect() work for us. It 
just can't, both gaps+overlaps and disappearing elements cannot be 
addressed by toRect() alone. If you want something to look uniform or 
prevent from disappearing, it needs to be addressed an abstraction layer 
higher, for example when computing the layout. That's what web browsers 
do (e.g. to ensure borders have consistent thickness, they snap logical 
pixels to the device pixels) and that's also what we do with our 
decorations.

And as I said previously, we also need a function whose behavior is well 
understood and that produces predictable values. I see the reasoning 
behind the current implementation of ::toRect(), but it's not exactly 
what we want in practice.

Regards,
Vlad