KRect and KRectF proposal

[Vlad Zahorodnii]

Hi,

On 3/27/26 10:44 PM, Kevin Ottens wrote:
> Hello,
>
> On Friday, 27 March 2026 19:03:01 Central European Standard Time Vlad
> Zahorodnii wrote:
>> I would like to propose adding a new library, e.g. kprimitivetypes, that
>> would host `KRect` and `KRectF`.
> The natural place would be kcoreaddons though as QRect(F) are in QtCore.
>
>> 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?
> Is there any other concrete cases of tier 1 needing to depend on KRect(F)
> beyond KConfig?
Yes, KWindowSystem is another example of a library where such rect types 
will be useful. KWindowSystem is a tier 1 library.
>
> As for KConfig itself, I'm not sure if the dependency is really required, the
> rect types are already going through the templated version of read/writeEntry
> which use QVariant. I think there is a path where we register conversion
> between QRect(F) and KRect(F) in the metatype system and where the internal
> implementation of KConfig leverages it (right now it's mostly limited to
> checking only userType IIRC). I'd expect we could sidestep a dependency from
> KConfig to KCoreAddons like this.

In KWin, we already do it but there are some compile time checks that 
are unaware of QMetaType::registerConvereter(). As a way around it, we 
explicitly convert Rect/RectF to QRect/QRectF.

Regards,
Vlad

> Again, I'm operating mostly from memory (although I checked a couple of
> points), so this likely needs to be investigated more.
>
> Regards.