I don't see how QVariant could support a non-copyable type any time in the
future, since QVariant itself is copyable. What is it going to do if it were
holding a non-copyable type and you copied it?
Yes, it would be ugly. It would have to move internally and warn about
it. But let's forget abou
I want to rotate the image to 45 degrees by Y axis, what should I do?
bool func1()
{
QImage image(3840, 2160, QImage::Format_ARGB32_Premultiplied);
image.fill(Qt::red);
QTransform t;
t.translate(image.width() / 2.0, image.height() / 2.0);
t.rotate(-45, Qt::YAxis);
t.transl
On Tuesday, 19 July 2022 12:34:51 PDT Fabian Kosmale wrote:
> besides treating T& and T (which I think is fine for 6.4), anything else
> should probably only be done in 6.5. I don't currently see much
> interdependence in the changes you proposed, however we should carefully
> check that DBus, Qt R
On Tuesday, 19 July 2022 13:16:15 PDT Volker Hilsheimer wrote:
> Ok, so QMetaType::name() will not necessarily return the name that was used
> in QMetaType::fromName, and the name returned might be compiler and C++
> library specific.
>
> That is good to know and should perhaps be mentioned in the
On Tuesday, 19 July 2022 14:50:32 PDT Ulf Hermann wrote:
> "will not change" apparently means "I'm not doing it right now". I'm
> aware that it would be a new feature, but I can imagine someone adding
> support for move-only types to QVariant eventually. We may not actually
> need it though. Your p
Right now, if moc detects the QML macros in the class definition, it forces
the method parameters to be fully defined, not just forward declarations. But
in your case here, the derived class without the macro or the parent will not
get such a treatment and any type that is only forward declared w
> On 19 Jul 2022, at 21:34, Fabian Kosmale wrote:
>
> Hi,
>
> besides treating T& and T (which I think is fine for 6.4), anything else
> should probably only be done in 6.5.
> I don't currently see much interdependence in the changes you proposed,
> however we should carefully
> check that D
Hi,
besides treating T& and T (which I think is fine for 6.4), anything else should
probably only be done in 6.5.
I don't currently see much interdependence in the changes you proposed, however
we should carefully
check that DBus, Qt Remote Objects and QML don't get accidentally broken.
Regardi
> On 19 Jul 2022, at 18:08, Thiago Macieira wrote:
>
>> Lastly, an aside: Q_DECLARE_METATYPE being effectively unnecessary was the
>> goal for Qt 6, but is not the case yet. I consider that a bug that should
>> finally be fixed in 6.5.
>
> Right. There should be exactly one use for Q_DECLARE_ME
On Tuesday, 19 July 2022 00:34:34 PDT Fabian Kosmale wrote:
> Hi,
>
> I think the most uncontroversial part is not treating T& as T; I fully agree
> with it. I think it is fine to reject them in QMetaType::fromType. It is a
> SC breaking change, but I expect it to only affect template code, which
On Monday, 18 July 2022 23:54:13 PDT Ulf Hermann wrote:
> Hi,
>
> for the purpose of QML support, the types of properties and the
> arguments and return types of invokable methods, signals, and slots have
> to be available as metatypes. We need _all_ types with metaobjects to
> observe this rule,
Hi all,
we have released Qt 6.2.5 LTS Commercial today. Please see the blog post:
https://www.qt.io/blog/commercial-lts-qt-6.2.5-released
Big thanks to everyone involved & have a lovely summer!
Best regards
Tarja Sundqvist
Release Manager
___
Dev
Hi,
I think the most uncontroversial part is not treating T& as T; I fully agree
with it. I think it is fine to reject them in QMetaType::fromType. It is a
SC breaking change, but I expect it to only affect template code, which
can rather easily fix it by explicitly using remove_ref. Can be done f
13 matches
Mail list logo
