KRect and KRectF proposal

[Thiago Macieira]

On Thursday, 9 April 2026 00:43:13 Pacific Daylight Time Vlad Zahorodnii wrote:
> 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.

That's fair and I do agree. But also orthogonal as to how floating-point 
rounding should work when context is absent.

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

Agreed again, but still orthogonal. I am arguing for a predictable result with 
*less* surprise than what you've implemented.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 870 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20260410/4b35652c/attachment.sig>