Re: KRect and KRectF proposal

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?

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.

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

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud supporting member of KDE
https://haute-couture.enioka.com/en

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQQXFmpSdcX6bxpI/XgHS7vLjezJ4gUCacbsPgAKCRAHS7vLjezJ
4ukxAJ9ckiQ68YmsZYVaN8eOXBK2oncu+gCgkch6eIAajuQhUGFfVOj9+v1RSdc=
=lCoV
-----END PGP SIGNATURE-----