[Interest] Dictation to Qt-Software on Windows-10 Is Broken

[coroberti .]

Hi,
If by chance Qt-Accessibility has a maintainer,
this is the new and even more severe issue with dictation on Windows-10.

You cannot dictate to Qt-software on Windows-10:

https://bugreports.qt.io/browse/QTBUG-83671

Actually, it was always a broken area at least since 2015:

https://bugreports.qt.io/browse/QTBUG-45980

If people on the list have a chance to vote, please vote.

Thanks,

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Rendering UI on H/W and Client browser

[praveen illa]

Hi Team,

I have a query on rendering UI on both hardware display screen and a client
browser on PC simultaneously.

1. Can I use eglfs and WebGL for the same. If not, can anyone suggest me,
what libraries in Qt can be used?

2. Can we open multiple clients with WebGL?

Thanks,
Praveen
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [SPAM] build from source does not build qtsvg

[Hamish Moffatt]

On 21/4/20 9:23 am, Thiago Macieira wrote:

On Monday, 20 April 2020 14:28:45 PDT Hamish Moffatt wrote:

I did, initially. But qtsvg was being silently ignored and I couldn't
figure out why, so eventually I downloaded everything in case there was
a dependency on another module that I'd omitted.

So you're saying you downloaded qtsvg 5.14.2's .tar.gz, typed

   qmake
   make

and it did nothing?



No, I mean downloaded qt 5.12's .tar.gz, ran an out-of-tree configure 
and make, and it didn't build qtsvg. Same for 5.15.0 in git.


In-tree configure and build works though.


Hamish

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [SPAM] build from source does not build qtsvg

[Thiago Macieira]

On Monday, 20 April 2020 14:28:45 PDT Hamish Moffatt wrote:
> I did, initially. But qtsvg was being silently ignored and I couldn't
> figure out why, so eventually I downloaded everything in case there was
> a dependency on another module that I'd omitted.

So you're saying you downloaded qtsvg 5.14.2's .tar.gz, typed

  qmake
  make

and it did nothing?

-- 
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] [SPAM] build from source does not build qtsvg

[Hamish Moffatt]

On 21/4/20 1:56 am, Thiago Macieira wrote:

On Sunday, 19 April 2020 22:45:27 MDT Hamish Moffatt wrote:

  -skip qtactiveqt \

This incredibly long list of skips tells me you're doing something wrong.
Instead of opting out of everything you don't want, opt in to the things yuo
do. Just download and build each module independently and ignore the top-level
configure.



I did, initially. But qtsvg was being silently ignored and I couldn't 
figure out why, so eventually I downloaded everything in case there was 
a dependency on another module that I'd omitted.



Thanks,

Hamish

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] dragging from Qt (KDE) app onto Mac Finder and vice versa

[René J . V . Bertin]

René J.V. Bertin wrote:

> Concretely: I have built KDE Dolphin for Mac, and find I can copy/move files
> by dragging them from the Finder and dropping them onto a destination folder
> in Dolphin (e.g. for copying to a remote server that isn't accessible through
> the Finder). For some reason the reverse operation doesn't work - and I assume
> that is not because of a limitation in Qt (or in the Finder). Or is it?

To answer my own question, in part: dragging from Dolphin onto a Finder window 
actually works if the dragged URI uses the file:// scheme (I don't seem to have 
control over whether the result is a copy or a move, but that's a different 
issue).

After discovering the dropsite example and playing with it I realised that I 
had 
misunderstood my problem. When I drag from a Dolphin window that connects to a 
remote server with a non-standard protocol, that affects the dragged URI, e.g.
sftp://host/path/to/file for browsing remote files via an equivalent of sshfs, 
and 
smb://host/path/to/file for browsing files on a remote Samba share. The Finder 
doesn't support those protocols, so rejects the drop.

KDE uses "kioslaves" behind the scenes that act as impromptu file system 
drivers. 
For "universal" drag support I would thus have to be able to obtain the target 
of the drop (application and in this case, the target directory) and then 
somehow cancel the drop event, converting it to the appropriate kioslave 
invocation that will handle the copy or move.

But I suppose that there's no way to obtain the information required for this 
kind of approach?

Thanks,
R.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] dragging from Qt (KDE) app onto Mac Finder and vice versa

[René J . V . Bertin]

Hi,

Can someone point me to a succinct overview of the basics of drag-and-drop 
support in Qt applications?

Concretely: I have built KDE Dolphin for Mac, and find I can copy/move files by 
dragging them from the Finder and dropping them onto a destination folder in 
Dolphin (e.g. for copying to a remote server that isn't accessible through the 
Finder). For some reason the reverse operation doesn't work - and I assume that 
is not because of a limitation in Qt (or in the Finder). Or is it?

Thanks,
René
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

[Florian Bruhin]

On Mon, Apr 20, 2020 at 09:50:06AM -0600, Thiago Macieira wrote:
> On Monday, 20 April 2020 03:28:48 MDT Florian Bruhin wrote:
> > FWIW that's the choice Python had taken with Python 2 (ordering different
> > types by their type name). It was widely regarded as a bad decision and
> > replaced by a TypeError exception in Python 3.
> 
> Interesting. Do you have more information on why it is regarded a bad 
> decision? A PEP, hopefully?

I have to admit my "widely regarded as" was perhaps a bit too anecdotal.

It doesn't look like a PEP exists for this, which seems quite surprising. There
was some discussion via email, but it's quite a mess to read, unfortunately:

https://mail.python.org/pipermail/python-dev/2004-June/thread.html
(the "Comparing heterogeneous types" threads)

https://mail.python.org/archives/search?q=Comparing+heterogeneous+types=1=python-dev%40python.org=date-asc
(same content, more modern archive webinterface)

Florian

-- 
m...@the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org 
   https://bruhin.software/ | https://github.com/sponsors/The-Compiler/
   GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
 I love long mails! | https://email.is-not-s.ms/


signature.asc
Description: PGP signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Qt-5.14.2 - iOS - Drag & Drop

[coroberti .]

On Mon, Apr 20, 2020 at 1:04 PM Tor Arne Vestbø  wrote:
>
> This is a missing feature, please file a feature request, thanks!
>
> Tor Arne
>
> > On 20 Apr 2020, at 08:54, coroberti .  wrote:
> >
> > On Sun, Apr 5, 2020 at 1:32 PM coroberti .  wrote:
> >> Trying to allow Drag to my app on iOS (iPad with spitted view)
> >> and working in line with: https://doc.qt.io/qt-5/dnd.html
> >>
> >> I see that dragEnterEvent () and dragMoveEvent () are never called.
> >>
> >> This is in contrast to Mac OS X where it works for the same exactly code 
> >> properly.
> >> (and acceptDrops(true) was set).
> >>
> >> I was using on both platforms QTextEdit widget.
> >>
> >> Is it correct to say that on iOS widgets lack implementation of drap 
> >> events?
> >>
> >> Please, let me know if I'm missing something like configuration missed, 
> >> etc.
> >>
> >> Thanks in advance!
> >>
> >> Kind regards,
> >> Robert Iakobashvili
> >> 
> >
> > Could somebody from iOS of GUI maintainers guide me whether the
> > issue above is a bug or a feature request to open?
> >
> > Thanks in advance!
> >
> > Kind regards,
> > Robert

Thanks, Tor Arne Vestbø.

Here it is:
https://bugreports.qt.io/browse/QTBUG-83665

Please, vote for it. Thanks!

Kind regards,
Robert Iakobashvili

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

[André Pönitz]

On Mon, Apr 20, 2020 at 10:04:38AM -0400, Matthew Woehlke wrote:
> On 19/04/2020 08.23, André Pönitz wrote:
> > QVariant(TypeA) and QVariant(TypeB) can be ordered for different TypeA and
> > TypeB based e.g. on alphabetical order of their .typeName().
> > 
> > If wanted, this can be refined to make e.g. all integral types comparable.
> 
> No:
> 
>   int{5} <=> JsonObject{...} => lesser
>   int{5} <=> long{3} => greater
>   long{3} <=> JsonObject{...} => greater
> 
> ...oops.

"make comparable" means lumping them into a common "type", say
"@integral", with values covering the union set of the values
of the original type.

   int{5} == "@integral"{5} <=> JsonObject{...} => lesser
   int{5} == "@integral"{5} <=> "@integral{3}" == long{3} => greater
   long{3} == "@integral"{3} <=> JsonObject{...} =>  lesser! // not greater

> You'd have to make all integral types sort before (or after) all other
> types, but then you're back to not having a reliable ordering by type name.

No.

> It makes *much* more sense that some comparisons just come back
> "incomparable".

Possible, but not needed on the type level, and restricts use
unnecessarily.

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

Re: [Interest] [SPAM] build from source does not build qtsvg

[Thiago Macieira]

On Sunday, 19 April 2020 22:45:27 MDT Hamish Moffatt wrote:
>  -skip qtactiveqt \
>  -skip qtandroidextras \
>  -skip qtcharts \
>  -skip qtconnectivity \
>  -skip qtdatavis3d \
>  -skip qtdeclarative \
>  -skip qtdoc \
>  -skip qtgamepad \
>  -skip qtgraphicaleffects \
>  -skip qtlocation \
>  -skip qtlottie \
>  -skip qtnetworkauth \
>  -skip qtpurchasing \
>  -skip qtqa \
>  -skip qtquick3d \
>  -skip qtquickcontrols \
>  -skip qtquickcontrols2 \
>  -skip qtquicktimeline \
>  -skip qtremoteobjects \
>  -skip qtscxml \
>  -skip qtsensors \
>  -skip qtserialbus \
>  -skip qtserialport \
>  -skip qtspeech \
>  -skip qtvirtualkeyboard \
>  -skip qtwayland \
>  -skip qtwebchannel \
>  -skip qtwebglplugin \
>  -skip qtwebsockets \
>  -skip qtwebview \
>  -skip qtwinextras \
>  -skip qtx11extras \

This incredibly long list of skips tells me you're doing something wrong. 
Instead of opting out of everything you don't want, opt in to the things yuo 
do. Just download and build each module independently and ignore the top-level 
configure.

-- 
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

[Thiago Macieira]

On Monday, 20 April 2020 08:04:38 MDT Matthew Woehlke wrote:
> On 19/04/2020 08.23, André Pönitz wrote:
> > QVariant(TypeA) and QVariant(TypeB) can be ordered for different TypeA and
> > TypeB based e.g. on alphabetical order of their .typeName().
> > 
> > If wanted, this can be refined to make e.g. all integral types comparable.
> 
> No:
> 
>int{5} <=> JsonObject{...} => lesser
>int{5} <=> long{3} => greater
>long{3} <=> JsonObject{...} => greater
> 
> ...oops.

I think, whatever we do, we will keep numeric type conversion. That code is 
already there and is the least contentious part of the comparison code. When I 
wrote it half a decade ago, I was very careful to follow the C++ integral type 
promotion rules. The only new thing I'd do to that code is fix the comparison 
of a negative qint64 to a quint64: type promotion rules and expectation don't 
match (there's a new function in C++ to do that comparison in the "expected" 
manner; can't recall the name).

I would argue that a new QVariant shouldn't even have multiple, different 
numeric types, but just one or two (integral and floating point), like 
QCborValue does. But since QVariant is built on top of QMetaType, which is 
supposed to relate to concrete types in C++ so you can manipulate them in an 
erased manner, that's not possible.

-- 
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

[Thiago Macieira]

On Monday, 20 April 2020 03:28:48 MDT Florian Bruhin wrote:
> FWIW that's the choice Python had taken with Python 2 (ordering different
> types by their type name). It was widely regarded as a bad decision and
> replaced by a TypeError exception in Python 3.

Interesting. Do you have more information on why it is regarded a bad 
decision? A PEP, hopefully?

Either solution can be dealt with by the surrounding code. If one wants not to 
sort across types and QVariant does, then all you need to do is to compare the 
types before. If one want to sort by type and QVariant doesn't, then one needs 
to convert to a specific common type before issuing the comparisons.

The pros of having that conversion inside QVariant is that it reduces the 
chance of someone getting it wrong. This reduces code duplication in favour of 
a well-tested implementation.

The drawback is that it might not be the order you want because the conversion 
isnt the one you wanted. Some conversions are lossy and may result in spurious 
or nonsensical comparisons. That means some applications may need to deploy 
their own conversion code regardless of what QVariant does. For those and the 
others that don't need comparisons across types, QVariant has unnecessary 
complexity.

So, again, it boils down to choice. I'm really interested in Python's 
rationale to see if it applies to us too.

-- 
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

[Matthew Woehlke]

On 19/04/2020 08.23, André Pönitz wrote:

QVariant(TypeA) and QVariant(TypeB) can be ordered for different TypeA and
TypeB based e.g. on alphabetical order of their .typeName().

If wanted, this can be refined to make e.g. all integral types comparable.


No:

  int{5} <=> JsonObject{...} => lesser
  int{5} <=> long{3} => greater
  long{3} <=> JsonObject{...} => greater

...oops.

You'd have to make all integral types sort before (or after) all other 
types, but then you're back to not having a reliable ordering by type name.


It makes *much* more sense that some comparisons just come back 
"incomparable".


--
Matthew
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

[Bernhard Lindner]

Hi!

> In other cases this such silent breakage is called "bug fix"
> and has a positive connotation.

YMMD :-)

For this reason, Qt does not have a formal requirements engineering 
sub-process. Without
requirements, everything is debatable and you can pretty much do what you want. 
Including
defining bugs and features :-)

-- 
Best Regards,
Bernhard Lindner

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Jira-admin] Jira upgrade with planned downtime on 28th April (07:00 CEST)

[Alex Blasche]

Well, the date in the mail subject is correct. The mail body is not correct. 
The update is on 28thApril and *NOT* on 10th May. The time remains unchanged.

--
Alex



From: Jira-admin  on behalf of Alex Blasche 

Sent: Monday, 20 April 2020 13:44
To: developm...@qt-project.org; interest@qt-project.org Interest
Cc: jira-ad...@qt-project.org
Subject: [Jira-admin] Jira upgrade with planned downtime on 28th April  (07:00 
CEST)

Hi,

We will upgrade Jira on 10th May starting at 7:00 am CEST. Current expectation 
is that Jira will be back in business about 2 hrs later. I apologize for any 
inconvenience that this downtime might bring along.

For those interested in more details, we'll upgrade from current Jira v8.2.5 to 
Jira v8.5.4 (latest Enterprise release). If you are interested in feature 
changes check out 
https://confluence.atlassian.com/jirasoftware/jira-software-release-notes-776821069.html
 .

If you have any questions beforehand or after the upgrade, please contact 
jira-ad...@qt-project.org.

--
Alex
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Jira upgrade with planned downtime on 28th April (07:00 CEST)

[Alex Blasche]

Hi,

We will upgrade Jira on 10th May starting at 7:00 am CEST. Current expectation 
is that Jira will be back in business about 2 hrs later. I apologize for any 
inconvenience that this downtime might bring along.

For those interested in more details, we'll upgrade from current Jira v8.2.5 to 
Jira v8.5.4 (latest Enterprise release). If you are interested in feature 
changes check out 
https://confluence.atlassian.com/jirasoftware/jira-software-release-notes-776821069.html
 .

If you have any questions beforehand or after the upgrade, please contact 
jira-ad...@qt-project.org.

--
Alex
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

[André Pönitz]

On Mon, Apr 20, 2020 at 11:40:24AM +0200, Giuseppe D'Angelo via Interest wrote:
> Before bikeshedding on the actual semantics we _want_ to have: if they
> don't 100% match the ones we have right now, then it's a silent breakage
> for end-users, which is a very bad idea.

In other cases this such silent breakage is called "bug fix"
and has a positive connotation.

> So, if we ever want to have the relational operators in QVariant with
> "better" semantics, we need an upgrade path that clearly signals the
> breakage. Any proposals for that?

One could start with free functions qSomehowLessThan() doing that, and
use them in cases where the current convenience conversions and
operator==() implementations fail. 

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

Re: [Interest] QVariant compare operator

[Bernhard Lindner]

> So, if we ever want to have the relational operators in QVariant with
> "better" semantics, we need an upgrade path that clearly signals the
> breakage. Any proposals for that?

qFatal() would be a clear signal. It depends from the actual solution if all 
changes
result in qFatal.

-- 
Best Regards,
Bernhard Lindner

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

[Giuseppe D'Angelo via Interest]

(Sorry, this was meant to go to the list!)

On 4/19/20 2:21 PM, Allan Sandfeld Jensen wrote:

I don't think we need "incomparable" here.

QVariant(TypeA) and QVariant(TypeB) can be ordered for different TypeA and
TypeB based e.g. on alphabetical order of their .typeName().

If wanted, this can be refined to make e.g. all integral types comparable.


What about non-integral types? QVariants can't really be anything but weakly
ordered as I see it, as some of the things it contains are either non-
comparable or weakly ordered themselves.



Before bikeshedding on the actual semantics we _want_ to have: if they
don't 100% match the ones we have right now, then it's a silent breakage
for end-users, which is a very bad idea.

So, if we ever want to have the relational operators in QVariant with
"better" semantics, we need an upgrade path that clearly signals the
breakage. Any proposals for that?

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: S/MIME Cryptographic Signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

[Florian Bruhin]

On Sun, Apr 19, 2020 at 12:42:16PM -0300, Thiago Macieira wrote:
> On Sunday, 19 April 2020 09:39:40 -03 André Pönitz wrote:
> > > What about non-integral types?
> > 
> > They are compared by typeName(). So any QChar would be less-than any
> > QRegularExpression.
> 
> We can order by type, but I don't think we should. But that's a choice.

FWIW that's the choice Python had taken with Python 2 (ordering different types
by their type name). It was widely regarded as a bad decision and replaced by a
TypeError exception in Python 3.

Florian

-- 
m...@the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org 
   https://bruhin.software/ | https://github.com/sponsors/The-Compiler/
   GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
 I love long mails! | https://email.is-not-s.ms/


signature.asc
Description: PGP signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] build from source does not build qtsvg

[Hamish Moffatt]

On 20/4/20 2:45 pm, Hamish Moffatt wrote:
I haven't built Qt5 from source in ages, but I need to test something 
on 5.15.


Everything builds OK, but QtSVG doesn't get built, and I can't figure 
out why. There's absolutely no mention of it in config.log. It seems 
to be just being ignored. It's listed in the makefile: 



It looks like QtSVG just gets ignored when you do an out of tree build. 
For an in-tree build, it's built just fine. QTBUG-83658.




Hamish

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Handling stylus input on a tablet in QML/QtQuick

[Thorsten Hofer-Schmitz]

Hi

I have seen that bug report, but didn't understand at as "try Qt5.15". 
Just tried it and it seems to work mostly. Hovering also works. But 
there is a bug somewhere. On my Huawei, finger touch causes a hover 
event to start/end (happend in 5.14.2 as well). In the example, if you 
start hover, you can touch the tile once and it becomes red to indicate 
hovering, and a second touch ends it. I can also use my pen for 
hovering, and just like finger touch a press makes the tile permanently 
red. But with my pen I can't end hovering, I have to touch it with my 
finger for that.


I don't understand the problems with pen input in QtQuick. QTabletEvent 
works just fine, in QWidget and QtQuick. The engine just converts the 
event. Why not just use that, unlike HandlerPoint it supports tilt and 
tangetial pressure as well. It's just missing hovering, which Qt for 
some reason tied to QApplication/QWidget. And that code should be 
movable to QGuiApplication, the events come from the host after all, Qt 
is just processing them. That doesn't make sense to me (as someone who 
doesn't know much about the interals of this).


Am 20.04.2020 um 06:07 schrieb Shawn Rutledge:



On 19 Apr 2020, at 01:16, Thorsten Hofer-Schmitz 
 wrote:

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")
}

}

It should work in 5.15: see also QTBUG-79660 and the tablet manual test in 
qtdeclarative/tests/manual/pointer.


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.

Those are currently not delivered to the main window, only to the application.  
So you still need a C++ subclass in Qt 5, as in 
qtbase/examples/widgets/widgets/tablet/tabletapplication.cpp.  I’m hoping to 
get more complete proximity event delivery in place in Qt 6.



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

[Yves Maurischat]

Hi Yuri,

I assume you're implementing a QSortFilterProxyModel for sorting and 
filtering: you can reimplement QSortFilterProxyModel::lessThan() 
. Basically 
you'll do the following (in pseudo code):


bool  YourSortModel::lessThan(constQModelIndex   
&/source_left/, constQModelIndex   
&/source_right/)
{
auto left =/source_left.data(someRole);/
auto right=/source_right//.data(///someRole/);/

return (left.toByteArray() < right.toByteArray());
}



Mit freundlichen Grüßen | Kind regards,

*Yves Maurischat*
Senior Software Engineer

basysKom GmbH
Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany
Tel: +49 6151 870 589 -144 | Fax: -199
yves.maurisc...@basyskom.com | www.basyskom.com

Handelsregister: Darmstadt HRB 9352
Geschaeftsfuehrende Partner: Heike Ziegler, Alexander Sorg


Am 18.04.2020 um 11:43 schrieb evilruff:

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] Qt-5.14.2 - iOS - Drag & Drop

[coroberti .]

On Sun, Apr 5, 2020 at 1:32 PM coroberti .  wrote:
> Trying to allow Drag to my app on iOS (iPad with spitted view)
> and working in line with: https://doc.qt.io/qt-5/dnd.html
>
> I see that dragEnterEvent () and dragMoveEvent () are never called.
>
> This is in contrast to Mac OS X where it works for the same exactly code 
> properly.
> (and acceptDrops(true) was set).
>
> I was using on both platforms QTextEdit widget.
>
> Is it correct to say that on iOS widgets lack implementation of drap 
> events?
>
> Please, let me know if I'm missing something like configuration missed, etc.
>
> Thanks in advance!
>
> Kind regards,
> Robert Iakobashvili
> 

Could somebody from iOS of GUI maintainers guide me whether the
issue above is a bug or a feature request to open?

Thanks in advance!

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest