Re: KRect and KRectF proposal

Thiago Macieira <[email protected]> Fri, 10 Apr 2026 09:56:01 -0700

Newsgroups	gmane.comp.kde.devel.general
Message-ID	<2927328.Hq7AAxBmiT@tjmaciei-mobl5>

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.

signature.asc (application/pgp-signature, 870 B)