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 p
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.
In
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 uncomparabl
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 QtQu
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 dur
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,
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 plea
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
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 e
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. The
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 compari
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
__
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 awa
13 matches
Mail list logo
