Re: [Development] QVariant comparison in Qt6

[Thiago Macieira]

On Friday, 18 September 2020 14:51:17 PDT André Pönitz wrote:
> > Because we should push our users to adopt new compiler versions.
> 
> What kind of political agenda is that?
> 
> Pushing for newer anything just means we are leaving people behind.
> 
> This might be justified in some cases if there's a real benefit outweighing
> this loss, but pushing just for the sake of pushing?
> 
> > features in Qt only available when they upgrade is a good way to do that.
> > Want to use old compilers? It costs more.
> 
> The cost is on *our side* because frustrated people leave the ecosystem.

I'm talking about adding new features that are only available with newer 
compiler versions. Not about refactoring existing features so that people have 
to upgrade to keep up with what they already had. The case of QVariant is a 
bit special because it is a feature that used to exist, but was broken in many 
ways, even if people were depending on it.

But for other things, I'm not shy about it. People can't complain that they 
can't use features that didn't exist when they wrote their application.  If 
they want to use new features, it stands to reason they've just upgraded Qt. 
If they can do that, they should be able to upgrade their compiler and 
toolchain too.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QVariant comparison in Qt6

[André Pönitz]

On Fri, Sep 18, 2020 at 11:56:38AM -0700, Thiago Macieira wrote:
> On Friday, 18 September 2020 09:38:12 PDT Ville Voutilainen wrote:
> > > We should use one of the types from [1]. Yes, it's C++20; we can
> > > make our internal API return an integer that is convertible to those types
> > > in the front-end API, under #if __has_include().
> > > 
> > > [1] https://en.cppreference.com/w/cpp/header/compare
> > 
> > Why do people keep pushing C++20 facilities when we decided that C++17 is 
> > our
> > standard version? How does the int say "I can't compare this"?
> > partial_ordering can do that, but what will the int do?
> 
> Because we should push our users to adopt new compiler versions.

What kind of political agenda is that?

Pushing for newer anything just means we are leaving people behind.

This might be justified in some cases if there's a real benefit outweighing
this loss, but pushing just for the sake of pushing?

> features in Qt only available when they upgrade is a good way to do that. 
> Want 
> to use old compilers? It costs more.

The cost is on *our side* because frustrated people leave the ecosystem.

Andre'
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QVariant comparison in Qt6

[Bernhard Lindner]

> What is it you need? Just some total ordering of variants? The method you 
> mentioned in
> QAbstractItemModel also only does ordering for some types, otherwise falling 
> back to
> strings.

I am using QVariant comparison (==, >, <) only for equal types. But not in 
models. I use
it for other code. 

I also use QMaps of QVariants, but also not for mixed types, only for equal 
types.

So I need ==, <, > for equal types, including custom types. 

My preferred solution for error handling wouldn't be a fall back to "return 
false" but a
call to qFatal (or at least qWarning).

-- 
Best Regards,
Bernhard Lindner

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QVariant comparison in Qt6

[Bernhard Lindner]

> > Has anything changed for Qt6 (especially regarding comparison of equal
> > and/or convertible types)? Is the complete deprecation still the latest
> > decision?
> 
> Yes, it's changed; no, it's not deprecation.
> 
> What's been removed is the conversion. Aside from the numeric types, 
> comparing 
> two variants of different types will always result in false. If you want to 
> compare across types, convert one to the other's type or to a common third 
> type. You know what data you put in there and you should know what 
> conversions 
> can be lossy or not.

That would be much better than deprecation.

What about Qt 5.15? If I understood correctly, Qt 5.15 should prepare 
developers for
changes/deprecations/removals in Qt6. So I guess things that will remain part 
of Qt 6
should also be part of Qt 5.15. Still Qt 5.15 gives me warnings about 
deprecation of
operator < for QVariant.

-- 
Best Regards,
Bernhard Lindner

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QVariant comparison in Qt6

[Thiago Macieira]

On Friday, 18 September 2020 09:38:12 PDT Ville Voutilainen wrote:
> > We should use one of the types from [1]. Yes, it's C++20; we can
> > make our internal API return an integer that is convertible to those
> > types in the front-end API, under #if __has_include().
> > 
> > [1] https://en.cppreference.com/w/cpp/header/compare
> 
> Why do people keep pushing C++20 facilities when we decided that C++17
> is our standard
> version? How does the int say "I can't compare this"? partial_ordering
> can do that, but what
> will the int do?

Because we should push our users to adopt new compiler versions. Having 
features in Qt only available when they upgrade is a good way to do that. Want 
to use old compilers? It costs more.

We can also use this to provide spaceship operator for QVariant and other 
classes.

Anyway, the int suffices because we only need four values: equal/equivalent, 
less than, greater than, unordered. We can even adopt the same values:
// less=0xff, equiv=0x00, greater=0x01, unordered=0x02
or we can use -127 for unordered like libc++ does or -128 like Microsoft STL.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QVariant comparison in Qt6

[Ville Voutilainen]

On Fri, 18 Sep 2020 at 18:13, Thiago Macieira  wrote:
>
> On Friday, 18 September 2020 06:48:50 PDT Lars Knoll wrote:
> > std::optional QVariant::compare(const QVariant );
> >
> > Would that be good enough?
>
> Why the optional?
>
> We should use one of the types from [1]. Yes, it's C++20; we can make
> our internal API return an integer that is convertible to those types in the
> front-end API, under #if __has_include().
>
> [1] https://en.cppreference.com/w/cpp/header/compare

Why do people keep pushing C++20 facilities when we decided that C++17
is our standard
version? How does the int say "I can't compare this"? partial_ordering
can do that, but what
will the int do?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QVariant comparison in Qt6

[Thiago Macieira]

On Friday, 18 September 2020 01:44:36 PDT Giuseppe D'Angelo via Development 
wrote:
> Il 18/09/20 02:54, Thiago Macieira ha scritto:
> > What's been removed is the conversion. Aside from the numeric types,
> > comparing two variants of different types will always result in false. If
> > you want to compare across types, convert one to the other's type or to a
> > common third type. You know what data you put in there and you should
> > know what conversions can be lossy or not.
> 
> In other words even mixed comparisons between strings, string views,
> byte array, etc. are unsupported now?

Between byte arrays and strings, they should be unsupported, since they are 
different types. We can argue that the views and non-view containers should be 
comparable.

But neither QStringView nor QByteArrayView have meta types.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QVariant comparison in Qt6

[Thiago Macieira]

On Friday, 18 September 2020 06:48:50 PDT Lars Knoll wrote:
> std::optional QVariant::compare(const QVariant );
> 
> Would that be good enough?

Why the optional?

We should use one of the types from [1]. Yes, it's C++20; we can make 
our internal API return an integer that is convertible to those types in the 
front-end API, under #if __has_include().

[1] https://en.cppreference.com/w/cpp/header/compare

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QVariant comparison in Qt6

[Thiago Macieira]

On Friday, 18 September 2020 01:59:50 PDT Albert Astals Cid via Development 
wrote:
> We have a few generic item models and proxy models that implement sorting,
> they did so by using operator< of QVariant.
> 
> I want a way to be able to do the same in Qt6 in a way that ideally doesn't
> involve having to copy the QAbstractItemModelPrivate::isVariantLessThan
> code.

Perform an unconditional conversion to string and sort that.

In a model, where you're likely to *display* the element, this is probably the 
right thing to do, as you don't want to explain to your users why your list 
shows items like

1
10
11
2
3
21

A few of the above are strings and the others are numbers. It should always 
lexicographically sort or use numeric/natural sorting.
 
> Maybe making QAbstractItemModelPrivate::isVariantLessThan public and clearly
> defining what it was would be good enough (i mean if it is good enough for
> QAbstractItemModel it could be enough for most of the other
> implementations).

That's a good idea.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QVariant comparison in Qt6

[Thiago Macieira]

On Friday, 18 September 2020 01:50:50 PDT Konstantin Tokarev wrote:
> In Qt4 times comparison operators for QVariant were missing and from my
> experience main limitation was that it wasn't possible to have QVariant as
> a key in QMap without defining one manually.

Correct. That's because you shouldn't do that.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QVariant comparison in Qt6

[Lars Knoll]

On 18 Sep 2020, at 14:19, Albert Astals Cid 
mailto:albert.astals@kdab.com>> wrote:
[snip]

I’m not really in favour of adding an operator<() to QVariant again, as it
would need to provide some decent ordering, and that would probably cause
conflicts with operator=() that does somewhat loose comparisons for numeric
types.

But we could provide a compare() method similar to QMetaType. I don’t think
we can provide total ordering here as some types stored in a QVariant do
not provide comparison operators, but we could basically provide the same
as QMetaType:

std::optional QVariant::compare(const QVariant );

Would that be good enough?

I think that would solve some (probably even most) of the pain, yes :)

Here we go:

https://codereview.qt-project.org/c/qt/qtbase/+/314463

Cheers,
Lars
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QVariant comparison in Qt6

[Albert Astals Cid via Development]

El divendres, 18 de setembre de 2020, a les 13:25:45 CEST, Lars Knoll va 
escriure:
> > On 18 Sep 2020, at 11:23, Albert Astals Cid via Development
> >  wrote:
 
> > El divendres, 18 de setembre de 2020, a les 11:00:23 CEST, André Somers va
> > 
 escriure:
> > 
> >> On 18-09-2020 09:12, Albert Astals Cid via Development wrote:
> >> 
> >>> El divendres, 18 de setembre de 2020, a les 2:54:53 CEST, Thiago
> >>> Macieira
> >>> va> 
> >>> escriure:
> >>> 
>  On Thursday, 17 September 2020 16:15:47 PDT Bernhard Lindner wrote:
>  
> > Hi!
> > 
> > There was a discussion about the decision to deprecate (remove?)
> > QVariant
> > comparison (<,>) in Qt6 completely.
> > 
> > Has anything changed for Qt6 (especially regarding comparison of
> > equal
> > and/or convertible types)? Is the complete deprecation still the
> > latest
> > decision?
>  
>  
>  Yes, it's changed; no, it's not deprecation.
>  
>  What's been removed is the conversion. Aside from the numeric types,
>  comparing two variants of different types will always result in false.
>  If
>  you want to compare across types, convert one to the other's type or to
>  a
>  common third type. You know what data you put in there and you should
>  know
>  what conversions can be lossy or not.
> >>> 
> >>> 
> >>> But i don't what data someone else put it in a QVariant.
> >>> 
> >>> The fact that QAbstractItemModelPrivate::isVariantLessThan exists
> >>> should
> >>> be
> >>> proof enough that you can't expect my class to know what someone else
> >>> put
> >>> inside a QVariant, i mean that's basically the defining feature of
> >>> QVariant "it can hold random things for you".
> >>> 
> >>> 
> >>>  Is the official Qt position that we should all "copy"
> >>> 
> >>> 
> >>> QAbstractItemModelPrivate::isVariantLessThan into our item model
> >>> classes
> >>> that need sorting?
> >> 
> >> 
> >> How often do you really have items of different QVariant types in a
> >> single column and and role in a model?
> > 
> > 
> > Probably not often, but that means adding new API to classes forcing users
> > of 
 those classes to specify either a single type for each role/column
> > (so the comparison can be done internally in the class) or a comparer
> > function for each role/column and offloading the comparison back to the
> > user, makes things a bit annoying.
> > 
> > 
> >> 
> >> From what I understand, in Qt 6 you can still compare QVariants if they
> >> contain the same type - be that a user type or not - for both equality
> >> and lessThan provided the type in QVariant supports such comparisons.
> >> Right?
> 
> > 
> > There's no lessThan in Qt6 for QVariant, so no, you can't do that [unless
> > you 
 unbox the data from the QVariant, but then you're not comparing
> > QVariants anymore :)].
> 
> 
> I’m not really in favour of adding an operator<() to QVariant again, as it
> would need to provide some decent ordering, and that would probably cause
> conflicts with operator=() that does somewhat loose comparisons for numeric
> types.
 
> But we could provide a compare() method similar to QMetaType. I don’t think
> we can provide total ordering here as some types stored in a QVariant do
> not provide comparison operators, but we could basically provide the same
> as QMetaType:
 
> std::optional QVariant::compare(const QVariant );
> 
> Would that be good enough?

I think that would solve some (probably even most) of the pain, yes :)

Cheers,
  Albert

> 
> Cheers,
> Lars
> 
> 
> 
> > Cheers,
> > 
> >  Albert
> > 
> > 
> > 
> >> 
> >> André
> >> 
> >> 
> >> ___
> >> Development mailing list
> >> Development@qt-project.org
> >> https://lists.qt-project.org/listinfo/development
> > 
> > 
> > 
> > -- 
> > Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
> > Klarälvdalens Datakonsult AB, a KDAB Group company
> > Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> > KDAB - The Qt, C++ and OpenGL Experts
> > 
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> 
> 


-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing Alex Trotsenko as approver

[Lars Knoll]

Another +1.

Cheers,
Lars

> On 18 Sep 2020, at 10:52, Joerg Bornemann  wrote:
> 
> On 9/17/20 11:37 AM, André Hartmann wrote:
> 
>> I like to propose Alex Trotsenko as approver.
> 
> +1 from me as well
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QVariant comparison in Qt6

[Lars Knoll]

> On 18 Sep 2020, at 11:23, Albert Astals Cid via Development 
>  wrote:
> 
> El divendres, 18 de setembre de 2020, a les 11:00:23 CEST, André Somers va 
> escriure:
>> On 18-09-2020 09:12, Albert Astals Cid via Development wrote:
>>> El divendres, 18 de setembre de 2020, a les 2:54:53 CEST, Thiago Macieira
>>> va> 
>>> escriure:
 On Thursday, 17 September 2020 16:15:47 PDT Bernhard Lindner wrote:
> Hi!
> 
> There was a discussion about the decision to deprecate (remove?)
> QVariant
> comparison (<,>) in Qt6 completely.
> 
> Has anything changed for Qt6 (especially regarding comparison of equal
> and/or convertible types)? Is the complete deprecation still the latest
> decision?
 
 Yes, it's changed; no, it's not deprecation.
 
 What's been removed is the conversion. Aside from the numeric types,
 comparing two variants of different types will always result in false. If
 you want to compare across types, convert one to the other's type or to a
 common third type. You know what data you put in there and you should
 know
 what conversions can be lossy or not.
>>> 
>>> But i don't what data someone else put it in a QVariant.
>>> 
>>> The fact that QAbstractItemModelPrivate::isVariantLessThan exists should
>>> be
>>> proof enough that you can't expect my class to know what someone else put
>>> inside a QVariant, i mean that's basically the defining feature of
>>> QVariant "it can hold random things for you".
>>> 
>>>  Is the official Qt position that we should all "copy"
>>> 
>>> QAbstractItemModelPrivate::isVariantLessThan into our item model classes
>>> that need sorting?
>> 
>> How often do you really have items of different QVariant types in a
>> single column and and role in a model?
> 
> Probably not often, but that means adding new API to classes forcing users of 
> those classes to specify either a single type for each role/column (so the 
> comparison can be done internally in the class) or a comparer function for 
> each role/column and offloading the comparison back to the user, makes things 
> a 
> bit annoying.
> 
>> 
>> From what I understand, in Qt 6 you can still compare QVariants if they
>> contain the same type - be that a user type or not - for both equality
>> and lessThan provided the type in QVariant supports such comparisons. Right?
> 
> There's no lessThan in Qt6 for QVariant, so no, you can't do that [unless you 
> unbox the data from the QVariant, but then you're not comparing QVariants 
> anymore :)].

I’m not really in favour of adding an operator<() to QVariant again, as it 
would need to provide some decent ordering, and that would probably cause 
conflicts with operator=() that does somewhat loose comparisons for numeric 
types.

But we could provide a compare() method similar to QMetaType. I don’t think we 
can provide total ordering here as some types stored in a QVariant do not 
provide comparison operators, but we could basically provide the same as 
QMetaType:

std::optional QVariant::compare(const QVariant );

Would that be good enough?

Cheers,
Lars


> Cheers,
>  Albert
> 
>> 
>> André
>> 
>> 
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
> 
> 
> -- 
> Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - The Qt, C++ and OpenGL Experts
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QVariant comparison in Qt6

[Albert Astals Cid via Development]

El divendres, 18 de setembre de 2020, a les 11:00:23 CEST, André Somers va 
escriure:
> On 18-09-2020 09:12, Albert Astals Cid via Development wrote:
> > El divendres, 18 de setembre de 2020, a les 2:54:53 CEST, Thiago Macieira
> > va> 
> > escriure:
> >> On Thursday, 17 September 2020 16:15:47 PDT Bernhard Lindner wrote:
> >>> Hi!
> >>> 
> >>> There was a discussion about the decision to deprecate (remove?)
> >>> QVariant
> >>> comparison (<,>) in Qt6 completely.
> >>> 
> >>> Has anything changed for Qt6 (especially regarding comparison of equal
> >>> and/or convertible types)? Is the complete deprecation still the latest
> >>> decision?
> >> 
> >> Yes, it's changed; no, it's not deprecation.
> >> 
> >> What's been removed is the conversion. Aside from the numeric types,
> >> comparing two variants of different types will always result in false. If
> >> you want to compare across types, convert one to the other's type or to a
> >> common third type. You know what data you put in there and you should
> >> know
> >> what conversions can be lossy or not.
> > 
> > But i don't what data someone else put it in a QVariant.
> > 
> > The fact that QAbstractItemModelPrivate::isVariantLessThan exists should
> > be
> > proof enough that you can't expect my class to know what someone else put
> > inside a QVariant, i mean that's basically the defining feature of
> > QVariant "it can hold random things for you".
> > 
> >   Is the official Qt position that we should all "copy"
> > 
> > QAbstractItemModelPrivate::isVariantLessThan into our item model classes
> > that need sorting?
> 
> How often do you really have items of different QVariant types in a
> single column and and role in a model?

Probably not often, but that means adding new API to classes forcing users of 
those classes to specify either a single type for each role/column (so the 
comparison can be done internally in the class) or a comparer function for 
each role/column and offloading the comparison back to the user, makes things a 
bit annoying.

> 
>  From what I understand, in Qt 6 you can still compare QVariants if they
> contain the same type - be that a user type or not - for both equality
> and lessThan provided the type in QVariant supports such comparisons. Right?

There's no lessThan in Qt6 for QVariant, so no, you can't do that [unless you 
unbox the data from the QVariant, but then you're not comparing QVariants 
anymore :)].

Cheers,
  Albert

> 
> André
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development


-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QVariant comparison in Qt6

[Allan Sandfeld Jensen]

On Freitag, 18. September 2020 10:28:06 CEST Albert Astals Cid via Development 
wrote:
> El divendres, 18 de setembre de 2020, a les 10:22:16 CEST, Lars Knoll va 
escriure:
> > Sorting and equality are two different things. QVariant has never
> > supported
> > a lessThan operator.
> 
> Yes, it has
> 
> https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kernel/qvariant.h?h=5
> .15#n467
> 
But it wasn't reliable or compliant(*), so it wasn't suitable for sorting and 
especially not to be used as a key in a QMap.

*) A < B did not guarantee B > A, even A == B, didn't imply B == A


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QVariant comparison in Qt6

[Giuseppe D'Angelo via Development]

Il 18/09/20 10:22, Lars Knoll ha scritto:


Sorting and equality are two different things. QVariant has never 
supported a lessThan operator.


That's not accurate. Q5Variant has operator<, and Q5MetaType allowed to 
register comparators (op== and op<) for a user type. I don't know how 
much software relied on this magic for user defined types, certainly 
reimplementing it in one's code is going to be slightly annoying but 
doable. The big problem is the logic for builtin types which is now 
broken without much of a replacement...


--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QVariant comparison in Qt6

[André Somers]

On 18-09-2020 09:12, Albert Astals Cid via Development wrote:

El divendres, 18 de setembre de 2020, a les 2:54:53 CEST, Thiago Macieira va
escriure:

On Thursday, 17 September 2020 16:15:47 PDT Bernhard Lindner wrote:

Hi!

There was a discussion about the decision to deprecate (remove?) QVariant
comparison (<,>) in Qt6 completely.

Has anything changed for Qt6 (especially regarding comparison of equal
and/or convertible types)? Is the complete deprecation still the latest
decision?

Yes, it's changed; no, it's not deprecation.

What's been removed is the conversion. Aside from the numeric types,
comparing two variants of different types will always result in false. If
you want to compare across types, convert one to the other's type or to a
common third type. You know what data you put in there and you should know
what conversions can be lossy or not.

But i don't what data someone else put it in a QVariant.

The fact that QAbstractItemModelPrivate::isVariantLessThan exists should be
proof enough that you can't expect my class to know what someone else put
inside a QVariant, i mean that's basically the defining feature of QVariant "it
can hold random things for you".

  Is the official Qt position that we should all "copy"
QAbstractItemModelPrivate::isVariantLessThan into our item model classes that
need sorting?


How often do you really have items of different QVariant types in a 
single column and and role in a model?


From what I understand, in Qt 6 you can still compare QVariants if they 
contain the same type - be that a user type or not - for both equality 
and lessThan provided the type in QVariant supports such comparisons. Right?


André


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QVariant comparison in Qt6

[Albert Astals Cid via Development]

El divendres, 18 de setembre de 2020, a les 10:37:36 CEST, Lars Knoll va 
escriure:
> > On 18 Sep 2020, at 10:28, Albert Astals Cid 
> > wrote:
 
> > El divendres, 18 de setembre de 2020, a les 10:22:16 CEST, Lars Knoll va
> > escriure:
> 
> >> Sorting and equality are two different things. QVariant has never
> >> supported
 a lessThan operator.
> > 
> > 
> > Yes, it has
> > 
> > https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kernel/qvariant.h?h
> > =5.15#n467
> 
> You’re right. I thought it didn’t support that.
> 
> What is it you need? Just some total ordering of variants? The method you
> mentioned in QAbstractItemModel also only does ordering for some types,
> otherwise falling back to strings.

We have a few generic item models and proxy models that implement sorting, 
they did so by using operator< of QVariant.

I want a way to be able to do the same in Qt6 in a way that ideally doesn't 
involve having to copy the QAbstractItemModelPrivate::isVariantLessThan code.

But i'll understand if you say "it is how it is, either copy 
QAbstractItemModelPrivate::isVariantLessThan or force the users of your 
generic item model classes to provide their own QVariant lessThan operator".

It's not the end of the world, but it's one of those things that was 
convenient in Qt5 and seems it will not be as convenient in Qt6.

Maybe making QAbstractItemModelPrivate::isVariantLessThan public and clearly 
defining what it was would be good enough (i mean if it is good enough for 
QAbstractItemModel it could be enough for most of the other implementations).

Best Regards,
  Albert

 
> Cheers,
> Lars
> 
> 
> > 
> > Cheers,
> > 
> >  Albert
> > 
> > 
> > 
> >> Cheers,
> >> Lars
> >> 
> >> 
> >> Cheers,
> >> Albert
> >> 
> >> --
> >> Albert Astals Cid |
> >> albert.astals@kdab.com | Senior
> >> Software Engineer
> > 
> > Klarälvdalens Datakonsult AB, a KDAB Group company
> > 
> >> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> >> KDAB - The Qt, C++ and OpenGL Experts
> >> 
> >> ___
> >> Development mailing list
> >> Development@qt-project.org
> >> https://lists.qt-project.org/listinfo/development
> >> 
> > 
> > 
> > 
> > -- 
> > Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
> > Klarälvdalens Datakonsult AB, a KDAB Group company
> > Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> > KDAB - The Qt, C++ and OpenGL Experts
> > 
> 
> 


-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing Alex Trotsenko as approver

[Joerg Bornemann]

On 9/17/20 11:37 AM, André Hartmann wrote:


I like to propose Alex Trotsenko as approver.


+1 from me as well
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QVariant comparison in Qt6

[Konstantin Tokarev]

18.09.2020, 11:40, "Lars Knoll" :
>>  On 18 Sep 2020, at 10:28, Albert Astals Cid  
>> wrote:
>>
>>  El divendres, 18 de setembre de 2020, a les 10:22:16 CEST, Lars Knoll va 
>> escriure:
>>>  Sorting and equality are two different things. QVariant has never supported
>>>  a lessThan operator.
>>
>>  Yes, it has
>>
>>  
>> https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kernel/qvariant.h?h=5.15#n467
>
> You’re right. I thought it didn’t support that.
>
> What is it you need? Just some total ordering of variants? The method you 
> mentioned in QAbstractItemModel also only does ordering for some types, 
> otherwise falling back to strings.

In Qt4 times comparison operators for QVariant were missing and from my 
experience main limitation was that it wasn't possible to have QVariant as a 
key in QMap without defining one manually.

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QVariant comparison in Qt6

[Giuseppe D'Angelo via Development]

Il 18/09/20 02:54, Thiago Macieira ha scritto:

What's been removed is the conversion. Aside from the numeric types, comparing
two variants of different types will always result in false. If you want to
compare across types, convert one to the other's type or to a common third
type. You know what data you put in there and you should know what conversions
can be lossy or not.


In other words even mixed comparisons between strings, string views, 
byte array, etc. are unsupported now?


Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QVariant comparison in Qt6

[Lars Knoll]

> On 18 Sep 2020, at 10:28, Albert Astals Cid  
> wrote:
> 
> El divendres, 18 de setembre de 2020, a les 10:22:16 CEST, Lars Knoll va 
> escriure:
>> Sorting and equality are two different things. QVariant has never supported
>> a lessThan operator.
> 
> Yes, it has
> 
> https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kernel/qvariant.h?h=5.15#n467

You’re right. I thought it didn’t support that.

What is it you need? Just some total ordering of variants? The method you 
mentioned in QAbstractItemModel also only does ordering for some types, 
otherwise falling back to strings.

Cheers,
Lars

> 
> Cheers,
>  Albert
> 
>> Cheers,
>> Lars
>> 
>> 
>> Cheers,
>> Albert
>> 
>> --
>> Albert Astals Cid |
>> albert.astals@kdab.com | Senior
>> Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
>> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
>> KDAB - The Qt, C++ and OpenGL Experts
>> 
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
>> 
> 
> 
> -- 
> Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - The Qt, C++ and OpenGL Experts
> 

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QVariant comparison in Qt6

[Albert Astals Cid via Development]

El divendres, 18 de setembre de 2020, a les 10:22:16 CEST, Lars Knoll va 
escriure:
> Sorting and equality are two different things. QVariant has never supported
> a lessThan operator.

Yes, it has

https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kernel/qvariant.h?h=5.15#n467

Cheers,
  Albert
 
> Cheers,
> Lars
> 
> 
> Cheers,
>  Albert
> 
> --
> Albert Astals Cid |
> albert.astals@kdab.com | Senior
> Software Engineer
 Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - The Qt, C++ and OpenGL Experts
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
> 


-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QVariant comparison in Qt6

[Lars Knoll]

On 18 Sep 2020, at 09:12, Albert Astals Cid via Development 
mailto:development@qt-project.org>> wrote:

El divendres, 18 de setembre de 2020, a les 2:54:53 CEST, Thiago Macieira va
escriure:
On Thursday, 17 September 2020 16:15:47 PDT Bernhard Lindner wrote:
Hi!

There was a discussion about the decision to deprecate (remove?) QVariant
comparison (<,>) in Qt6 completely.

Has anything changed for Qt6 (especially regarding comparison of equal
and/or convertible types)? Is the complete deprecation still the latest
decision?

Yes, it's changed; no, it's not deprecation.

What's been removed is the conversion. Aside from the numeric types,
comparing two variants of different types will always result in false. If
you want to compare across types, convert one to the other's type or to a
common third type. You know what data you put in there and you should know
what conversions can be lossy or not.

But i don't what data someone else put it in a QVariant.

The fact that QAbstractItemModelPrivate::isVariantLessThan exists should be
proof enough that you can't expect my class to know what someone else put
inside a QVariant, i mean that's basically the defining feature of QVariant "it
can hold random things for you".

The problem with the old comparisons was that it was rather random what 
compared to true and what compared to false. A bit like the much hated equality 
operator in JavaScript.

We’ve basically now said, that (with some exceptions for pointers of related 
types and numerical types) that those will not compare equal.

Is the official Qt position that we should all "copy"
QAbstractItemModelPrivate::isVariantLessThan into our item model classes that
need sorting?

Sorting and equality are two different things. QVariant has never supported a 
lessThan operator.

Cheers,
Lars


Cheers,
 Albert

--
Albert Astals Cid | 
albert.astals@kdab.com | Senior Software 
Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QVariant comparison in Qt6

[Allan Sandfeld Jensen]

On Freitag, 18. September 2020 02:54:53 CEST Thiago Macieira wrote:
> On Thursday, 17 September 2020 16:15:47 PDT Bernhard Lindner wrote:
> > Hi!
> > 
> > There was a discussion about the decision to deprecate (remove?) QVariant
> > comparison (<,>) in Qt6 completely.
> > 
> > Has anything changed for Qt6 (especially regarding comparison of equal
> > and/or convertible types)? Is the complete deprecation still the latest
> > decision?
> 
> Yes, it's changed; no, it's not deprecation.
> 
> What's been removed is the conversion. Aside from the numeric types,
> comparing two variants of different types will always result in false. If
> you want to compare across types, convert one to the other's type or to a
> common third type. You know what data you put in there and you should know
> what conversions can be lossy or not.

I found comparing two variants of the same type also always returned false, 
perhaps because it wasn't a native qvariant type?

See https://codereview.qt-project.org/c/qt/qtwebengine/+/312364/7/tests/auto/
widgets/qwebengineview/tst_qwebengineview.cpp

'Allan



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] 정건일 (Keonil Jeong) is out of office.

[정건일]

Period : 2020/09/18 13:30 ~ 2020/09/18 23:55 [Korea Standard Time]

부재중입니다.
이수철 선임 (soocheol@lge.com) 님께 연락 부탁드립니다.
Please contact Soocheol Lee (soocheol@lge.com)
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QVariant comparison in Qt6

[Albert Astals Cid via Development]

El divendres, 18 de setembre de 2020, a les 2:54:53 CEST, Thiago Macieira va 
escriure:
> On Thursday, 17 September 2020 16:15:47 PDT Bernhard Lindner wrote:
> > Hi!
> > 
> > There was a discussion about the decision to deprecate (remove?) QVariant
> > comparison (<,>) in Qt6 completely.
> > 
> > Has anything changed for Qt6 (especially regarding comparison of equal
> > and/or convertible types)? Is the complete deprecation still the latest
> > decision?
> 
> Yes, it's changed; no, it's not deprecation.
> 
> What's been removed is the conversion. Aside from the numeric types,
> comparing two variants of different types will always result in false. If
> you want to compare across types, convert one to the other's type or to a
> common third type. You know what data you put in there and you should know
> what conversions can be lossy or not.

But i don't what data someone else put it in a QVariant.

The fact that QAbstractItemModelPrivate::isVariantLessThan exists should be 
proof enough that you can't expect my class to know what someone else put 
inside a QVariant, i mean that's basically the defining feature of QVariant "it 
can hold random things for you".

 Is the official Qt position that we should all "copy" 
QAbstractItemModelPrivate::isVariantLessThan into our item model classes that 
need sorting?

Cheers,
  Albert

-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development