To Volker's point: I also mentioned in my post that Qt Quick never had a 
Triangle. Or Circle. Or any other primitive shapes. It has come up before that 
the use of ShapePath is one solution for such cases, but that also it isn't the 
most performant.
To that end I would recommend this thread focus on the tidying up of the so 
called "radiiiiiii" properties and close it off as a finished convenience so 
long as backwards compatibility is kept and property assignments make sense 
(e.g. clamping).

My other point was the interaction with the existing radius property - nobody 
has yet mentioned that Rectangle has always had a radius (so we can make a 
circle!).
Taking a lesson from QtQuick.Controls, the padding property is considered a 
"shortcut" to setting four other sub properties (which, by the way, don't have 
a group - and nobody complains... Matthias point was not to introduce another 
QObject to every Rectangle))
The padding property is this ignored if one of the sub properties are set. I'm 
assuming that negative values are handled well in this case. A negative radius 
might simple give you knobbles instead - like the rounded corners of a flight 
case.
Setting the existing radius property would become a shortcut to setting all the 
other four if not set (internally) such that they behave well together like the 
padding on a control.

Btw the fill of the proposed asymmetrical radiused rectangle appears to be 
correct from the images in Matthias' post so I don't think that is an issue.

________________________________
From: Development <development-boun...@qt-project.org> on behalf of Lars Knoll 
via Development <development@qt-project.org>
Sent: Saturday, December 23, 2023 3:40:32 AM
To: Giuseppe D'Angelo <giuseppe.dang...@kdab.com>
Cc: development@qt-project.org <development@qt-project.org>
Subject: Re: [Development] QML Rectangle corner radius API for Qt 6.7

> On 22 Dec 2023, at 17:48, Giuseppe D'Angelo via Development 
> <development@qt-project.org> wrote:
>
> Il 22/12/23 17:08, Pierre-Yves Siret ha scritto:
>> I wouldn't want a radii grouped property just because of its name.
>> I much prefer writing topLeftRadius: 10 than radii.topLeft: 10.
>> The pedantic latin syntax doesn't help with the readability. Maybe that's 
>> just because I am not a native English speaker.
>
>
> It might be pedantic, but here's an excerpt from the docs:
>
>> Individual corner **radii** can be set as well (see below).
>
>
> Anyhow, something like:
>
>  borderRadius: { topLeft: 10; bottomRight: 10 }
>
> (or cornerRadius or whatever) fixes the API issue I was mentioning, it's 
> discoverable, it's "obvious", has minimal impact (1 property on Rectangle 
> instead of 4), and it's also compact to write.

Yes, that’s what I had in mind.

Naming wise I would vote for borderRadius, simply because that name and its 
behaviour is well known for most developers and designers from CSS. 
cornerRadius could be an alternative (I think Figma uses that name).

Cheers,
Lars
--
Development mailing list
Development@qt-project.org
https://urldefense.com/v3/__https://lists.qt-project.org/listinfo/development__;!!Nbma_1s!phv0VmW2IryOl2G3D2VdsNkqbiOPt05vEJJGhE7gqcPUpal7mxAHB0cXEPsNgE1rvjgbKWeQG6mNX1vDZIkZnWhf7g$
Confidentiality Notice: This message (including attachments) is a private 
communication solely for use of the intended recipient(s). If you are not the 
intended recipient(s) or believe you received this message in error, notify the 
sender immediately and then delete this message. Any other use, retention, 
dissemination or copying is prohibited and may be a violation of law, including 
the Electronic Communication Privacy Act of 1986.   ­­
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to