KRect and KRectF proposal

[Thiago Macieira]

On Tuesday, 7 April 2026 12:56:19 Pacific Daylight Time Vlad Zahorodnii wrote:
> > Speaking of negative, what happens if you have negative height and width?
> > Which edge is exclusive?
> 
> Such rectangles will be considered invalid. So `::contains()` will
> return false. You'll need to use either `::normalized()` or `::span()`
> to get a proper rectangle. That's another (intentional) change that I
> forgot to mention in the original message.

Ok, so it means it's not a good replacement for QRect because it removes a 
functionality, in addition to fixing the known issue.

> >> - `RectF::toRect()` rounds the coordinates of top, left, right, and
> >> bottom edges;
> > 
> > Away from each other, towards each other, or towards a particular
> > direction? In other words, how do the height() and width() get rounded?
> 
> The final coordinates will be as follows:
> 
> - left = std::round(rect.x())
> - right = std::round(rect.x() + rect.width())
> - top = std::round(rect.y())
> - bottom = std::round(rect.y() + rect.height())
> 
> or
> 
> - x = std::round(rect.x())
> - y = std::round(rect.y())
> - width = std::round(rect.x() + rect.width()) - std::round(rect.x())
> - height = std::round(rect.y() + rect.height()) - std::round(rect.y())

So you may end up with a zero-sized integer rectangle when the original FP one 
isn't. Consider rounding fixing the rounding directions and in opposite of each 
other.

> The main reasoning behind this is HiDPI or fractional scaling to be
> specific. We need a predictable rounding algorithm, which doesn't tend
> to introduce gaps, and that's universal for both apps and compositors.

Agreed, which is why it shouldn't be rounding to nearest.

> Although note that the rectangles are stored as (left, top, right,
> bottom) tuples rather than (x, y, width, height) tuples, so it's just
> four std::round() calls. The reasoning behind it is that the LTRB format
> is nicer for contains(), intersects(), Region, etc.

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.

> >> I would like to propose adding a new library, e.g. kprimitivetypes, that
> >> would host `KRect` and `KRectF`. There is a slight challenge with KF
> >> though. It will be nice if KConfig and maybe other tier 1 libraries are
> >> able use `KRect(F)`. In order to achieve that, the new library will need
> >> to live either outside of KF or perhaps there could be tier 0 in KF?
> > 
> > Bring this discussion to the Qt dev mailing list so we can discuss having
> > it in QtCore.
> 
> Okay, will do.

You'll need to offer an convincing reason why negative sizes aren't allowed.
-- 
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-frameworks-devel/attachments/20260407/3d5715a9/attachment.sig>