Re: [Interest] QVariant compare operator
On Sun, 19 Apr 2020 at 10:48, Thiago Macieira wrote: > > On Saturday, 18 April 2020 12:57:55 -03 Giuseppe D'Angelo via Interest wrote: > > I guess that's the reason for dropping the comparisons in 6.0 and, > > eventually, reintroduce it in 7.0. With the hope that we've learned the > > lesson and proceed at _specifying_ the behaviour before implementing it. > > Indeed, and implement the QVariant comparator on top of each underlying type's > spaceship operator. That way, we could order elements of the same type. For > mismatched types, QVariant can return std::partial_ordering::unordered. > > We can't do that right now because we can't rely on C++20. In fact, no current > compiler supports the spaceship operator. So that has to be Qt 7. > > For now, the feature is badly implemented and yet too many people are using > it. We can't simply remove it without giving fair warning. The warning is > given. Just to clarify -- are you saying it's been deprecated IN qt 6, or removed in qt 6? Nyall ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QVariant compare operator
On Saturday, 18 April 2020 12:57:55 -03 Giuseppe D'Angelo via Interest wrote: > I guess that's the reason for dropping the comparisons in 6.0 and, > eventually, reintroduce it in 7.0. With the hope that we've learned the > lesson and proceed at _specifying_ the behaviour before implementing it. Indeed, and implement the QVariant comparator on top of each underlying type's spaceship operator. That way, we could order elements of the same type. For mismatched types, QVariant can return std::partial_ordering::unordered. We can't do that right now because we can't rely on C++20. In fact, no current compiler supports the spaceship operator. So that has to be Qt 7. For now, the feature is badly implemented and yet too many people are using it. We can't simply remove it without giving fair warning. The warning is given. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QVariant compare operator
With all respect to Thiago opinion I coldnt agree with it. There is nothing wrong at all with forwarding comparison of the values with the same data types to original classes within universal coontainer like QVariant as mentioned in the previous answer. However I agree that comparing uncomparable should lead to qFatal.. Problem is that even if I support idea of clean and tidy architectures and designs -main goal of the frameworks is to make life simple and easier to the end user - developer.. I looked in 5.15 sources. Ok idea clear - compare logic moved to virtual lessThen of the sortind model with QModelIndex's as parameters. Thats exactly an approach i have in my code for now with all extra switches to handle what was forgotten in QVariant implementation, but as for me its not a way to go. QVariant is a class exists for ages in the Qt and it has all the features even now to provide a decent way to compare typed related objects it contains including custom implementations.As for me 5.15 implementation is not better, its just moving same code to other classes provoking develor to extra inheritance or to copy paste this code to other places where QVariant stored values requires comparation..Why on earth then not to change this in existing branches used in production rather then declare that its a bad desing. I am not even talking about QtScript which is also QVariant based and where it was really convinient way to handle abstract types. I know that answer probably will be that we deprecated QtScript decades ago, but again up to me thats was one on the worsest decision made although its a bit other subject.It would take 15-20 lines of code to add native comparations to already existing classes to current QVariant which will make things consistent where of course < operator is applicable but only answer received sounds more like... ( skipped due to probable violation of some rules).. ;)And as we started about versions.. its nice to hear that something going to change in 5.15, 6.0 etc, but are Qt developers really assume that stable production code will easily 'just go' over major branches to update or will start adjusting current designs to potentially fullfil some guidelines of far away releases? Well, if QVariant::canConvert() says right operand can be converted to type of left, thenconvert and compare the result. If it can't convert, behavior should be undefined andqFatal() should be called (or whatever Qt 5.15 prefers to do in detectable cases ofundefined behavior).___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Handling stylus input on a tablet in QML/QtQuick
Hi
I'm trying to handle the input of a stylus on a tablet. Qt has an
example on how to do this using a QWidget-based application. I tested it
on my tablet and everything works fine.
I would like to do this in QML/QtQuick. The documentation suggests that
PointHandler, like this:
import QtQuick 2.14
import QtQuick.Window 2.14
Window {
visible: true
width: 640
height: 480
title: qsTr("Hello World")
PointHandler
{
acceptedDevices: PointerDevice.Stylus
acceptedPointerTypes: PointerDevice.Pen
onActiveChanged: console.log("Pen Input")
}
}
But it doesn't work, and I can't find out how to make it work.
I experimented with eventFilter's to intercept QTabletEvent's before
they are converted into mouse events by the QQuickWindow (as far as I
can tell). But unless there is a QWidget with WA_TabletTracking=true as
target (and some other options as it seems, because just a QMainWindow
with a widget isn't enough) I can't recieve TabletEnterProximity-events
for hovering.
Does someone know how to do this?
Regards
Thorsten
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] QVariant compare operator
Hi! > The biggest problem right now is that the behaviour of QVariant > comparisons is largely undocumented, that is, dictated by the > implementation. Any change to the these behaviours, as sensible as it > could be, will lead to silent breakages. Well, if the chance to create documention during requirements phase was missed it should at least be documented now. -- Best Regards, Bernhard Lindner ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QVariant compare operator
Hi! > The problem are not missing conversions, but too many conversions. If it is not possible to document and fix conversions to behave consistently (which should be possible), it still is reasonable to allow >/< comparisons for equal types only. That is easy to implement, simple to document, simple to understand and propably better than removing the feature completely. However, considering the fact that even ==/!= comparisons with implicit conversion do not work as expected, it is obvious that removing >/< comparison isn't a solution to the underlying problem. -- Best Regards, Bernhard Lindner ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QVariant compare operator
On Sat, Apr 18, 2020 at 04:53:04PM +0200, Bernhard Lindner wrote:
> Hi!
>
> > > > Relational comparisons with QVariant are deprecated in 5.15 and will be
> > > > removed because they are a misfeaure.
> > > > Redesign your code so your question does not need to be asked.
> > >
> > > Could you please explain why comparing two QVariants is a misfeature?
> >
> > Not comparing for equality. Comparing for ordering.
> >
> > What comes first, QSize(1, 1) or QRegularExpression("^$") ?
>
> Well, if QVariant::canConvert() says right operand can be converted to type
> of left, then
> convert and compare the result.
The main problem with QVariant conversions is that in the way they are
implemented
currently does not make them suitable even for equality comparision, leading to
effects like
#include
#include
int main()
{
QVariant v1 = QString("a");
QVariant v2 = QChar('a');
QVariant v3 = QByteArray("a");
qDebug() << QMap{{v1, 0}, {v2, 0}, {v3, 0}}.size();
qDebug() << QMap{{v2, 0}, {v1, 0}, {v3, 0}}.size();
}
producing
1
2
In theory, that's solvable, in practice you will always find someone adding yet
another conversion for "convenience" breaking that again.
> If it can't convert, behavior should be undefined and
> qFatal() should be called (or whatever Qt 5.15 prefers to do in detectable
> cases of
> undefined behavior).
The problem are not missing conversions, but too many conversions.
Andre'
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] QVariant compare operator
Il 18/04/20 16:53, Bernhard Lindner ha scritto:
Not comparing for equality. Comparing for ordering.
What comes first, QSize(1, 1) or QRegularExpression("^$") ?
Well, if QVariant::canConvert() says right operand can be converted to type of
left, then
convert and compare the result. If it can't convert, behavior should be
undefined and
qFatal() should be called (or whatever Qt 5.15 prefers to do in detectable
cases of
undefined behavior).
The biggest problem right now is that the behaviour of QVariant
comparisons is largely undocumented, that is, dictated by the
implementation. Any change to the these behaviours, as sensible as it
could be, will lead to silent breakages.
I guess that's the reason for dropping the comparisons in 6.0 and,
eventually, reintroduce it in 7.0. With the hope that we've learned the
lesson and proceed at _specifying_ the behaviour before implementing it.
My 2 c,
--
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
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] QVariant compare operator
Hi!
> > > Relational comparisons with QVariant are deprecated in 5.15 and will be
> > > removed because they are a misfeaure.
> > > Redesign your code so your question does not need to be asked.
> >
> > Could you please explain why comparing two QVariants is a misfeature?
>
> Not comparing for equality. Comparing for ordering.
>
> What comes first, QSize(1, 1) or QRegularExpression("^$") ?
Well, if QVariant::canConvert() says right operand can be converted to type of
left, then
convert and compare the result. If it can't convert, behavior should be
undefined and
qFatal() should be called (or whatever Qt 5.15 prefers to do in detectable
cases of
undefined behavior).
--
Best Regards,
Bernhard Lindner
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] QVariant compare operator
Probably the best way to handle this is for the model to maintain a map of column affinity, specified as QMetaType::Type, to compare items. The items themselves should also have an individual type. A database application will only need column affinity, a spreadsheet app will need item affinity. Then the model (as part of the model classes ( filter, sort)) should implement the automatic comparisons. Python's repr() function is ideal for this. Not sure how Qt could support this, but I really enjoy repr() Sent: Saturday, April 18, 2020 at 5:43 AM From: "evilruff" To: interest@qt-project.org Subject: Re: [Interest] QVariant compare operator Hi Thiago, I am happy ro redesign my code, but how then sorting/filtering models will work? As data() returns QVariant. Or you plan to use setSorting based on lambda's and std::function to provide strict types sorting? And what if from API point of view user want just to specify column without aware of data types. Am I missing something? Woukd really appreceate if you can point me to some direction to look at. Regards, Yuri Relational comparisons with QVariant are deprecated in 5.15 and will be removed because they are a misfeaure. Redesign your code so your question does not need to be asked. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QVariant compare operator
On Saturday, 18 April 2020 07:28:59 -03 Bernhard Lindner wrote:
> Hi!
>
> > Relational comparisons with QVariant are deprecated in 5.15 and will be
> > removed because they are a misfeaure.
> > Redesign your code so your question does not need to be asked.
>
> Could you please explain why comparing two QVariants is a misfeature?
Not comparing for equality. Comparing for ordering.
What comes first, QSize(1, 1) or QRegularExpression("^$") ?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] QVariant compare operator
Hi! > Relational comparisons with QVariant are deprecated in 5.15 and will be > removed because they are a misfeaure. > Redesign your code so your question does not need to be asked. Could you please explain why comparing two QVariants is a misfeature? -- Best Regards, Bernhard Lindner ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QVariant compare operator
Hi Thiago,I am happy ro redesign my code, but how then sorting/filtering models will work? As data() returns QVariant. Or you plan to use setSorting based on lambda's and std::function to provide strict types sorting?And what if from API point of view user want just to specify column without aware of data types.Am I missing something? Woukd really appreceate if you can point me to some direction to look at. Regards, Yuri Relational comparisons with QVariant are deprecated in 5.15 and will be removed because they are a misfeaure. Redesign your code so your question does not need to be asked.___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
