Re: KRect and KRectF proposal

Thiago Macieira <[email protected]> Mon, 06 Apr 2026 13:31:34 -0700
Newsgroups	gmane.comp.kde.devel.general
Message-ID	<5826678.IbC2pHGDlb@tjmaciei-mobl5>
On Friday, 27 March 2026 11:03:01 Pacific Daylight Time Vlad Zahorodnii wrote:
> - `Rect::right()` and `Rect::bottom()` represent the true right and
> bottom edges, respectively. In other words, `x() + width()` and `y() +
> height()`;

In other words, it's like containers: one-past-the-end. For a 1920x1080 
rectangle with the origin at 0,0, this would show right = 1920 and bottom = 
1080, and yet the last pixel is actually (1919,1079). That's the semantic 
problem of QRect.

Except you're doing:
> - `RectF::contains()` does not consider the right and bottom edges
> inside the rectangle. Current `QRectF::contains()` can lead to issues
> with input handling;

This is the big difference: the right and bottom edges (assuming positive) are 
not part of the surface. You have two edges that are inclusive and two that 
are exclusive.

Speaking of negative, what happens if you have negative height and width? 
Which edge is exclusive?

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

Suppose a rectangle of 1x1+0.5+0.5: do you round to 1x1+0+0 or 0x0+0+0?

> Our long term hope is that Qt developers would see what KDE does with
> `KRect` and `KRectF` and consider either fixing `QRect` and `QRectF` or
> incorporating them as is to Qt. Right now, if we go with our list of
> issues, we will likely be turned around with the reason that `QRect` and
> `QRectF` have been working like this since the beginning and there is a
> lot of software that can be broken, which is a really fair argument!
> Still, it won't make the issues go away...

The problem is legacy code, which is why it hasn't been fixed in 20 years that 
the pitfalls have been known. Therefore, not going to happen any time in the 
near future.

What may happen is adding a new class that has the right semantics and hope 
that over time it replaces the old. This class could be added at any time, 
which is when transition could start. And if it is in QtCore, then Qt classes 
in other modules could begin using it. If it's in a KF6 library, Qt classes 
can't.

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

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