KRect and KRectF proposal

[Kevin Ottens]

Hello,

On Saturday, 28 March 2026 15:29:02 Central European Summer Time Vlad 
Zahorodnii wrote:
> On 3/27/26 10:44 PM, Kevin Ottens wrote:
> > 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.

So, I did a quick search on what uses QRect(F) in tier 1. Hopefully I didn't 
miss any...

The list seems to be:
- KConfig
- KGuiAddons
- Kirigami
- KItemViews
- KWidgetAddons
- KWindowSystem
- Prison

For KConfig, see below.

For KGuiAddons, KItemsViews, KWidgetAddons and Prison, I'd argue the 
corresponding code is so tied to the quirks of QPainter that it'd be 
counterproductive to attempt a switch to a KRect(F).

Kirigami could benefit a bit internally, but I'm not sure that's worth the 
cost.

KWindowSystem is likely the most natural user of such a KRect(F).

Now if we look at the consumers of KWindowSystem... do we really care if it 
moves to tier 2 because it starts depending on KCoreAddons? I'm not sure we'd 
care much.

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

I think I was unclear, my point was that KConfig current implementation 
doesn't look at converters at all. It might be what we miss here, that 
anything which can convert to QRect(F) is stored as QRect(F). Currently 
KConfig only looks at "is it exactly QRect(F)".

Without such adjustments we'd indeed have to convert to QRect(F) before 
passing to KConfig.

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

enioka Haute Couture - proud supporting member of KDE
https://haute-couture.enioka.com/en
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20260330/5109cdab/attachment.sig>