Re: [Interest] Crash with Qt application that use OpenGL

[Xavier Bigand]

Ok, Thank you for suggestions Sergio, I also never used Apitrace.

The black list seems to be a good thing even if it can't work for us as for
the moment we have our homebrew 3D engine that directly call opengl.
If you have tips to migrate our engine to Angle I will be interested
because the last time I took a look I fell on build issues with glew and
other dependencies we have that also includes opengl headers.


Angle seems the way we should take to improve compatibility of our
application under Windows, we have few other issues that might be related
to OpenGL. I hope that Vulkan will get a better support under Windows as it
seems much more well defined.





2017-04-20 21:23 GMT+02:00 Sergio Martins :

> On 2017-04-20 20:04, Xavier Bigand wrote:
>
>> It is not necessary a bug from Nvidia, it can comes from bad
>> parameters to functions like glDrawElements.
>>
>
> Could be, but you'll have to prove it.
>
> I suggest:
> - Create a minimal-testcase which reproduces the problem
> - Run apitrace on it [1] (Never used it on Windows, but there are binaries
> for it)
> - Re-run the trace under apitrace, hopefully it crashes
> - Check if your hypothesis is correct (bad glDrawElements)
> - If it's an nvidia bug: Report to Nvidia, attach trace
> - If it's an nvidia bug: Open a Qt bug report so the card can be
> blacklisted
> - If it's non an nvidia bug: Report a regular Qt bug so it can be fixed,
> attach trace
>
>
>
> [1] - http://apitrace.github.io/#download
>
> Regards,
> --
> Sérgio Martins | sergio.mart...@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
>



-- 
Xavier
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Crash with Qt application that use OpenGL

[Sergio Martins]

On 2017-04-20 20:04, Xavier Bigand wrote:

It is not necessary a bug from Nvidia, it can comes from bad
parameters to functions like glDrawElements.


Could be, but you'll have to prove it.

I suggest:
- Create a minimal-testcase which reproduces the problem
- Run apitrace on it [1] (Never used it on Windows, but there are 
binaries for it)

- Re-run the trace under apitrace, hopefully it crashes
- Check if your hypothesis is correct (bad glDrawElements)
- If it's an nvidia bug: Report to Nvidia, attach trace
- If it's an nvidia bug: Open a Qt bug report so the card can be 
blacklisted
- If it's non an nvidia bug: Report a regular Qt bug so it can be fixed, 
attach trace




[1] - http://apitrace.github.io/#download

Regards,
--
Sérgio Martins | sergio.mart...@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
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Crash with Qt application that use OpenGL

[Tim Blechmann]

>> I think that I have found a crash in the nvidia drivers made by QtQuick.
> 
> Then the bug is in NVidia code. Report to them, please.

broken opengl drivers are a known issue on windows. it may be reasonable
to add this driver/device combination to the qt opengl blacklist and
enforce the use of ANGLE.

while this device seems to be new and chances are good that bugs will be
fixed, not so recent devices won't receive driver updates despite still
being widely in use. chrome and mozilla have extensive driver
blacklists, while qt only blacklists very few devices by default.

so i guess it's a good idea to file a bug report for qt as well ...

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

Re: [Interest] Crash with Qt application that use OpenGL

[Xavier Bigand]

It is not necessary a bug from Nvidia, it can comes from bad parameters to
functions like glDrawElements. Nividia drivers don't check a lot the
parameters and given wrong values can cause buffer overflows,...

2017-04-20 19:35 GMT+02:00 Thiago Macieira :

> On quinta-feira, 20 de abril de 2017 10:27:03 PDT Xavier Bigand wrote:
> > I think that I have found a crash in the nvidia drivers made by QtQuick.
>
> Then the bug is in NVidia code. Report to them, please.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>



-- 
Xavier
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Crash with Qt application that use OpenGL

[Thiago Macieira]

On quinta-feira, 20 de abril de 2017 10:27:03 PDT Xavier Bigand wrote:
> I think that I have found a crash in the nvidia drivers made by QtQuick.

Then the bug is in NVidia code. Report to them, please.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

[Interest] Crash with Qt application that use OpenGL

[Xavier Bigand]

Hi,


I think that I have found a crash in the nvidia drivers made by QtQuick.

On the computer on which our application crash at startup in the
nvoglv32.dll QtCreator crash too in the same way, that it why I suspect
that it comes from Qt.

It seems to be specific to the following configuration:
 - Nvidia geforce 1060 or 1070 at least (can't reproduce with a 980 GTX)
 - driver version 381.65

Other things that may have an impact
 - Windows 10 64bit, with creator update


Does someone have the same issue?

I will made some test with a basic QtQuick application to be sure and
eventually fill a bug.

-- 
Xavier
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] qobject_cast

[Thiago Macieira]

On quinta-feira, 20 de abril de 2017 09:35:15 PDT Igor Mironchik wrote:
> Hi,
> 
> >> QObject has virtual destructor... dynamic_cast will work. But it doesn't
> >> matter, the problem was in another...
> > 
> > If your class has virtual functions or derives from such base class, and
> > have inline (or default) virtual destructor,its  v-table will be emitted
> > in each translation unit. This is undesirable and can lead to subtle
> > problems. See e.g.
> > 
> > http://llvm.org/docs/CodingStandards.html#provide-a-virtual-method-anchor-> 
> > > for-classes-in-headers
> There said that it can lead just to increasing objects size in linking
> time. What problems may appear?

Emitting in multiple places is not usually a problem.

The problem happens when DLL/shared library boundaries appear. Depending on 
your compilation flags, the symbols will not be merged at runtime and ODR 
violations will occur.

I've said this before. A plugin system consists of:
 a) zero or more plugins
 b) zero or more applications
 c) exactly one DLL/shared library

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Interest] qobject_cast

[Till Oliver Knoll]

> Am 20.04.2017 um 08:05 schrieb nikita baryshnikov :
> 
> Hi, Igor
> 
> Your example is incorrect, cause you forget about Q_OBJECT macro in
> Channel class

That's what I just wanted to add as a general remark, because it is a common 
pitfall (at least for me): /every/ class which - directly or indirectly - 
inherits from QObject must have a Q_OBJECT declaration, /even/ if it doesn't 
emit or consume Qt signals or provides slots. IF that class is expected to 
behave nicely with said qobject_cast "and friends" (which is almost alway a 
desireable feature).

Q_OBJECT not only provides the glue to provide "slot" methods, but also 
generates the required meta information.

In fact, IIRC that's another advantage of qobject_cast over dynamic_cast: it 
works by design "across library boundaries" (dynamic_cast might or might not 
work, depending on whether the libraries share the same address space or other 
compiler-specific settings). 

Cheers,
  Oliver
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] qobject_cast

[Igor Mironchik]

20.04.2017 19:35, Igor Mironchik пишет:

Hi,


QObject has virtual destructor... dynamic_cast will work. But it 
doesn't

matter, the problem was in another...
If your class has virtual functions or derives from such base class, 
and have
inline (or default) virtual destructor,its  v-table will be emitted 
in each
translation unit. This is undesirable and can lead to subtle 
problems. See e.g.


http://llvm.org/docs/CodingStandards.html#provide-a-virtual-method-anchor-for-classes-in-headers 



There said that it can lead just to increasing objects size in linking 
time. What problems may appear?


* increasing of .obj file size and linking time *

Yes, it's a problem, but not critical to me.

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

Re: [Interest] qobject_cast

[Igor Mironchik]

Hi,
 


QObject has virtual destructor... dynamic_cast will work. But it doesn't
matter, the problem was in another...

If your class has virtual functions or derives from such base class, and have
inline (or default) virtual destructor,its  v-table will be emitted in each
translation unit. This is undesirable and can lead to subtle problems. See e.g.

http://llvm.org/docs/CodingStandards.html#provide-a-virtual-method-anchor-for-classes-in-headers


There said that it can lead just to increasing objects size in linking 
time. What problems may appear?

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

Re: [Interest] qobject_cast

[Igor Mironchik]

20.04.2017 19:16, Thiago Macieira пишет:

On quinta-feira, 20 de abril de 2017 08:47:46 PDT Igor Mironchik wrote:

Fix it by adding a non-inline virtual destructor to Channel.

Sure. It's just a pseudo code.

Then stop pasting pseudo-code. If you hide the problem, then you won't *see*
the problem.


Ok. I'm sorry.




In real code was virtual destructor and dynamic_cast and static_cast
worked, but qobject_cast failed.

The reason was in static linking of Channel to the application and to
the plugin.

You violated One Definition Rule of C++. Your application has Undefined
Behaviour. You caused this, you pay the price.

Stop violating ODR and it will work.


Yes, it's so.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] qobject_cast

[Konstantin Tokarev]

20.04.2017, 19:09, "Igor Mironchik" :
> 20.04.2017 18:22, Thiago Macieira пишет:
>>  Em quarta-feira, 19 de abril de 2017, às 22:56:46 PDT, Igor Mironchik
>>  escreveu:
>>>  class Channel
>>>
>>>  : public QObject
>>>
>>>  {};
>>>  void mySlot()
>>>  {
>>>  Channel * ch = qobject_cast< Channel* > ( sender() );
>>>  // You are 100% sure that sender() is Channel!!!
>>>  // And this cast will fail!!!
>>>  }
>>  And so will dynamic_cast fail.
>>
>>  Fix it by adding a non-inline virtual destructor to Channel.
>
> QObject has virtual destructor... dynamic_cast will work. But it doesn't
> matter, the problem was in another...

If your class has virtual functions or derives from such base class, and have 
inline (or default) virtual destructor,its  v-table will be emitted in each
translation unit. This is undesirable and can lead to subtle problems. See e.g.

http://llvm.org/docs/CodingStandards.html#provide-a-virtual-method-anchor-for-classes-in-headers

-- 
Regards,
Konstantin
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] qobject_cast

[Thiago Macieira]

On quinta-feira, 20 de abril de 2017 08:47:46 PDT Igor Mironchik wrote:
> > Fix it by adding a non-inline virtual destructor to Channel.
> 
> Sure. It's just a pseudo code.

Then stop pasting pseudo-code. If you hide the problem, then you won't *see* 
the problem.

> In real code was virtual destructor and dynamic_cast and static_cast
> worked, but qobject_cast failed.
> 
> The reason was in static linking of Channel to the application and to
> the plugin.

You violated One Definition Rule of C++. Your application has Undefined 
Behaviour. You caused this, you pay the price.

Stop violating ODR and it will work.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Interest] qobject_cast

[Igor Mironchik]

20.04.2017 18:22, Thiago Macieira пишет:

Em quarta-feira, 19 de abril de 2017, às 22:56:46 PDT, Igor Mironchik
escreveu:

class Channel

:  public QObject

{};
void mySlot()
{
Channel * ch = qobject_cast< Channel* > ( sender() );
// You are 100% sure that sender() is Channel!!!
// And this cast will fail!!!
}

And so will dynamic_cast fail.

Fix it by adding a non-inline virtual destructor to Channel.


QObject has virtual destructor... dynamic_cast will work. But it doesn't 
matter, the problem was in another...

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

Re: [Interest] speeding up "make clean" in qt src on OS X?

[Patrick Stinson]

Thank you for that explanation. I pulled Qt from git and don't remember the 
option to download specific modules but will look at the docs to find out how. 
Very good suggestion.

> On Apr 20, 2017, at 11:28 AM, Thiago Macieira  
> wrote:
> 
> Em quinta-feira, 20 de abril de 2017, às 01:34:10 PDT, Patrick Stinson 
> escreveu:
>> Running “make clean” in the root qt src dir calls xcodebuild a whole bunch
>> of times and takes a really, really long time. Is there any faster way to
>> do this? I am already excluding a lot of unnecessary builds in my configure
>> line:
>> 
>> ./configure -static -debug-and-release -nomake examples -xplatform macx-ios-
>> clang -sdk iphoneos -nomake tests
> 
> Konstantin's answer is the best way, but here's what's happening for you. You 
> used -nomake examples -nomake tests, so the Makefiles for the examples were 
> not 
> created. But when you ran make clean, it tried to clean the examples and 
> tests 
> too:
> 
>> cd qopenglwindow/ && ( test -e Makefile ||
>> /Users/patrick/dev/vendor/pyqt-sysroot-ios-64/src/qt5/qtbase/bin/qmake -o
>> Makefile
>> /Users/patrick/dev/vendor/pyqt-sysroot-ios-64/src/qt5/qtbase/tests/auto/gui
>> /kernel/qopenglwindow/qopenglwindow.pro )
> 
> In order to clean there, it needs to create the Makefile there first. Yes, 
> it's 
> wasteful because obviously there's nothing to be cleaned if there's no 
> Makefile 
> in the first place.
> 
> It's a qmake shortcoming. So there's nothing you can do to speed up make 
> clean 
> in the top dir.
> 
> Do what Konstantin said.
> 
> One more thing: your configure line had a LOT of -skip. If you didn't want 
> those modules, why did you download them? If all you wanted was qtbase, 
> download qtbase only.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Is freshly created QNetworkReply guaranteed to be in non-finished state and emit finished signal?

[Thiago Macieira]

On quinta-feira, 20 de abril de 2017 01:00:23 PDT ekke wrote:
> Am 19.04.17 um 22:58 schrieb Thiago Macieira:
> > On quarta-feira, 19 de abril de 2017 13:15:23 PDT Reinhardt Behm wrote:
> >> On Wednesday 19 April 2017 11:03:48 Thiago Macieira wrote:
> >>> It's guaranteed not to be finished.
> >> 
> >> Doesn't QAN use it's own thread?
> > 
> > Irrelevant.
> > 
> >> Then it could already be finished before the connection is made.
> > 
> > It can't happen. This is a design guarantee and will continue to work
> > however much we change QNAM.
> > 
> > That said, for certain URLs (namely, "file:///"), isFinished() may return
> > true, in which case you can obtain the data immediately. But even if that
> > is the case, finished() will still be emitted.
> 
> what happens on mobile platforms if APP is suspended, then coming back
> to active
> will finished() always be received ?

Yes. I don't see how scheduling the application out or suspending the system 
can affect the execution.

If the application exits, that's another story. If you exited the application, 
that's your problem.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Interest] Can the new Qt 5 (function pointer based) connections ever fail?

[Thiago Macieira]

Em quinta-feira, 20 de abril de 2017, às 02:14:24 PDT, Sze Howe Koh escreveu:
> Someone posted the quested at http://stackoverflow.com/
> questions/43487752/when-qt-5-will-fail-the-connect and I'm curious to know
> the answer.
> 
> Since the connections are checked at compile-time, does that mean
> QObject::connect() is guaranteed to succeed at run-time unless a duplicate
> connection is attempted with Qt::UniqueConnection?

No, it's not guaranteed. There's a normal problem and an ABI problem that can 
intervene.

First, remember that you pass the pointer to a signal, but what if the pointer 
you passed is not a signal? In that case, the connection will fail at runtime.

Second, the ABI problem. We've found that PMFs across DLLs/shared libraries 
don't work very well. Many compilers do not implement them properly and allow 
for unintended violations of the One Defintion Rule. What happens is that you 
pass the PMF of a signal, but when the meta object code tries to compare that 
PMF to itself, the comparison fails and so the connection fails.

We have disabled some optimisations that caused these violations and reported 
bugs to compilers that caused them in other situations. All issues I know of 
have been fixed, but that doesn't mean that there aren't more to be found.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Interest] speeding up "make clean" in qt src on OS X?

[Thiago Macieira]

Em quinta-feira, 20 de abril de 2017, às 01:34:10 PDT, Patrick Stinson 
escreveu:
> Running “make clean” in the root qt src dir calls xcodebuild a whole bunch
> of times and takes a really, really long time. Is there any faster way to
> do this? I am already excluding a lot of unnecessary builds in my configure
> line:
> 
> ./configure -static -debug-and-release -nomake examples -xplatform macx-ios-
> clang -sdk iphoneos -nomake tests

Konstantin's answer is the best way, but here's what's happening for you. You 
used -nomake examples -nomake tests, so the Makefiles for the examples were not 
created. But when you ran make clean, it tried to clean the examples and tests 
too:

> cd qopenglwindow/ && ( test -e Makefile ||
> /Users/patrick/dev/vendor/pyqt-sysroot-ios-64/src/qt5/qtbase/bin/qmake -o
> Makefile
> /Users/patrick/dev/vendor/pyqt-sysroot-ios-64/src/qt5/qtbase/tests/auto/gui
> /kernel/qopenglwindow/qopenglwindow.pro )

In order to clean there, it needs to create the Makefile there first. Yes, it's 
wasteful because obviously there's nothing to be cleaned if there's no Makefile 
in the first place.

It's a qmake shortcoming. So there's nothing you can do to speed up make clean 
in the top dir.

Do what Konstantin said.

One more thing: your configure line had a LOT of -skip. If you didn't want 
those modules, why did you download them? If all you wanted was qtbase, 
download qtbase only.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Interest] qobject_cast

[Thiago Macieira]

Em quarta-feira, 19 de abril de 2017, às 22:56:46 PDT, Igor Mironchik 
escreveu:
> class Channel
> 
>:  public QObject
> 
> {};

> void mySlot()
> {
>Channel * ch = qobject_cast< Channel* > ( sender() );
>// You are 100% sure that sender() is Channel!!!
>// And this cast will fail!!!
> }

And so will dynamic_cast fail.

Fix it by adding a non-inline virtual destructor to Channel.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Interest] Qt/QML fullscreen app not visible through Teamviewer on Windows

[Simon Everts]

Hi Cornelius,

Did you find a solution to this problem? I'm having the same issue.
When using Angle I can see the application using Teamviewer, but under
Angle the application freezes randomly so that's not really an option (it
actually unfreezes as soon I login with Teamviewer, so that's a little
weird too).

Best regards,
Simon

Op vr 8 jan. 2016 om 11:14 schreef Cornelius Hald :

> Sorry, I found that setting but it seems to make no difference :(
>
> Cheers,
> Conny
>
> On Fri, 2016-01-08 at 09:47 +0100, Cornelius Hald wrote:
> > Hi Kulias,
> >
> > thanks for your input and sorry for the delay (been on vacation).
> >
> > Which version of Teamviewer are you using? With Teamviewer 10 it
> > looks
> > like there is no such setting.
> >
> > Cheers,
> > Conny
> >
> >
> > On Fri, 2015-12-18 at 04:15 +, Kulias wrote:
> > > Hi,
> > >
> > > Try unchecked "Ignore alpha blending on this computer" in
> > > teamviewer
> > > host options:
> > > [Advance]->[Advanced settings for connections to this computer]
> > >
> > > It works in my case
> > >
> > > Cheers
> > > - Kulias
> > >
> > >
> > >
> > > ___
> > > Interest mailing list
> > > Interest@qt-project.org
> > > http://lists.qt-project.org/mailman/listinfo/interest
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to handle Touch Input on C++ side when extending QQuickItem

[Shawn Rutledge]

> On 20 Apr 2017, at 11:31, Alexandru Croitor  wrote:
> 
> So I found out about this recently as well, but touch events are not sent to 
> QQuickItems on macOS by default, because QNativeGestures are sent instead, 
> due to receiving high-precision gestures from the OS itself.
> 
> To receive touch events you need to use private API at the moment. Have a 
> look at the implementation of
> void QQuickMultiPointTouchArea::setTouchEventsEnabled(bool enable)
> 
> You would need to get the relevant function pointer and call 
> registerTouchWindow on your custom QQuickItem.

Right, that’s because of an unfortunate OS limitation that you can either get 
touchpoints from the trackpad, or gesture events (pinches, swipes, etc.), but 
not both.  A trackpad isn’t a touchscreen.  The first finger which you lightly 
put down on the surface moves the virtual mouse cursor, and generates only 
mouse move events.  The second finger doesn’t generate a touchpoint, because 
the OS is trying to detect 2-finger gestures (there are so many, and it’s not 
practical to disable that).  When you do the 2-finger flick, you normally get 
QWheelEvents in Qt, and those can drive the Flickable, so that it has a fairly 
native feel, like flicking text in Mail or Safari or whatever.  But because 
MultiPointTouchArea enables touch events via that private API, that disables 
the gesture detection just for that one NSView (which is normally the window 
containing the whole QtQuick scene), and that means you can get the touchpoints 
when you place 2 or more fingers on the trackpad.  It's not a direct touch 
device, so you know where the first point is (it’s the cursor), and the 
remaining ones will be nearby, based on how far away they are on the trackpad.  
But you will have trouble trying to tap on something onscreen with the second 
or third finger, say, because there is no visual feedback about where that 
finger is onscreen until you put down the finger - and then the feedback is up 
to the application.  And if you have some 3-finger OS gestures enabled in 
Preferences, those will occur simultaneously when you have 3 fingers in play, 
and interfere with what you are trying to do in the MPTA.

With all those limitations, MPTA isn’t actually that useful (except to just 
visualize the finger positions for a demo), and most likely you’re not going to 
have a great experience with a custom Item either (if you enable touchpoints 
via the private API, and thus disable gestures, that applies to the whole 
scene).  We prefer to have the OS-generated gesture events by default, because 
they enable smoother interaction with a native feel.  PinchArea works great 
with gesture events, and it doesn’t even have to do as much calculation, 
because the pinch event tells it exactly what to do: how much to zoom and how 
much to rotate.  (It may be that later on we will prefer native gesture events 
whenever possible on other platforms, but we were practically forced to do it 
on macOS.)

What I wish Apple would have done instead is send tentative touchpoints right 
away, then recall them whenever a gesture is detected, and let you either veto 
the recall to keep getting touchpoints, or accept the recall to switch over to 
gesture events for the duration of the gesture.  Then we could have quality 
data either way; it would be more flexible, but more complex.  If done right, 
an API like that could maybe even be portable between iOS and macOS.  But the 
trackpad evolved as more of a mouse-with-gestures than a touch device.  
Touchpad drivers on other platforms tend to be that way too, for that matter, 
with some exceptions.

On iOS the native APIs are different; you’ve got a real touchscreen after all.

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

[Interest] How to set a QObject extended type to a property var on Qml from C++

[Nuno Santos]

Hi,

I’m creating a new kind of GridView because the one bundled with Qt/Qml doesn’t 
offer 2D high performance scrolling.

GridView layouts items in a flow style, breaking line when it overflows. This 
allows scrolling in just 1D. Two make it 2D, you will be force to draw items 
that you don’t see by extending the grid view width/height and using a 
flickable over it to control GridView scrolling. The second problem is that the 
binding is already made for all items. If you have thousands of items this can 
cost valuable CPU cycles. This is specially important when you are running on 
mobile devices.

I need a high performance 2D scrollable grid that is able to show thousands of 
items without rendering and binding them all at the same time. Therefore, it 
performs a culling operation to show only the visible ones.

I have analysed the source code for GridView but it has a massive amount of 
work not even taking into consideration the fact it extends flickable. I’m 
trying to make things more simple and I have a working prototype for this but 
now I’m facing some problems.

- While I was able to create the delegate concept, modelData and index 
properties are not available on the delegate. How do you make that magic 
happen? Simple way alternatives.

- Considering I’m not able to replicate the modelData and index mechanism. How 
can I pass a QObject extended type to a property var on Qml. The idea is to 
enable/disable the binding for the visible/not visible items at each update

Instead of explaining all I am doing, you will find the source code here -> 
https://pastebin.com/4cgrpbdX 

Right now, I have a really simple Rectangle delegate on my grid. It has a 
property var model property to which I want to assign my custom type LKClipSlot 
which extends QObject, however, doing:

item->setProperty("model", QVariant(static_cast(slot)));

doesn’t seem to be valid... 

Suggestions?

Thanks,

Regards,

Nuno



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

[Interest] QtConcurrent::mappedReduced

[Michael Sué]

Hi,

two questions:

1) should the following code compile

QVector slices;
QFuture result=QtConcurrent::mappedReduced(slices,
[=](const int iSlice) -> bool {
bool ok=true
//
return ok;
},
[=](bool , const bool ok) {
endok= endok && ok;
},
QtConcurrent::UnorderedReduce);

QFutureWatcher futureWatcher;
futureWatcher.setFuture(result);
bool ok=result.result();

with VS 2015 it produces a lot of template based error messages; see below. 

Or maybe someone sees what's wrong with the code?

2) How to initialize endok in the second lambda function. 

Or should I always work with two functors and use their operator()? That way it 
compiles and works without problem.

Best, Michael.


VS output:

1>E:\Qt\5.8.0\include\QtConcurrent/qtconcurrentmapkernel.h(124): error C2039: 
'result_type': is not a member of 
'VSaveECAT7Image::saveSpecificFileFormat::'
1>  saveecat7image.cpp(405): note: see declaration of 
'VSaveECAT7Image::saveSpecificFileFormat::'
1>  E:\Qt\5.8.0\include\QtConcurrent/qtconcurrentmapkernel.h(123): note: while 
compiling class template member function 'bool 
QtConcurrent::MappedReducedKernel::runIterations(Iterator,int,int,ReducedResultType
 *)'
1>  with
1>  [
1>  ResultType=bool,
1>  
MapFunctor=VSaveECAT7Image::saveSpecificFileFormat::,
1>  
ReduceFunctor=VSaveECAT7Image::saveSpecificFileFormat::,
1>  Iterator=Iterator,
1>  ReducedResultType=bool
1>  ]
1>  E:\Qt\5.8.0\include\QtConcurrent/qtconcurrentreducekernel.h(222): note: see 
reference to class template instantiation 
'QtConcurrent::MappedReducedKernel'
 being compiled
1>  with
1>  [
1>  ResultType=bool,
1>  
MapFunctor=VSaveECAT7Image::saveSpecificFileFormat::,
1>  
ReduceFunctor=VSaveECAT7Image::saveSpecificFileFormat::
1>  ]
1>  E:\Qt\5.8.0\include\QtConcurrent/qtconcurrentmapkernel.h(247): note: see 
reference to class template instantiation 
'QtConcurrent::SequenceHolder2'
 being compiled
1>  with
1>  [
1>  Sequence=QVector,
1>  
MapFunctor=VSaveECAT7Image::saveSpecificFileFormat::,
1>  
ReduceFunctor=VSaveECAT7Image::saveSpecificFileFormat::
1>  ]
1>  e:\qt\5.8.0\include\qtconcurrent\qtconcurrentmap.h(130): note: see 
reference to function template instantiation 
'QtConcurrent::ThreadEngineStarter 
QtConcurrent::startMappedReduced(const
 Sequence &,MapFunctor,ReduceFunctor,QtConcurrent::ReduceOptions)' being 
compiled
1>  with
1>  [
1>  ResultType=bool,
1>  Sequence=QVector,
1>  
T=VSaveECAT7Image::saveSpecificFileFormat::,
1>  
MapFunctor=VSaveECAT7Image::saveSpecificFileFormat::,
1>  
ReduceFunctor=VSaveECAT7Image::saveSpecificFileFormat::
1>  ]
1>  saveecat7image.cpp(407): note: see reference to function template 
instantiation 'QFuture 
QtConcurrent::mappedReduced(const
 Sequence &,MapFunctor,ReduceFunctor,QtConcurrent::ReduceOptions)' being 
compiled
1>  with
1>  [
1>  Sequence=QVector,
1>  
MapFunctor=VSaveECAT7Image::saveSpecificFileFormat::,
1>  
ReduceFunctor=VSaveECAT7Image::saveSpecificFileFormat::
1>  ]
1>E:\Qt\5.8.0\include\QtConcurrent/qtconcurrentmapkernel.h(124): error C2146: 
syntax error: missing '>' before identifier 'result_type'
1>E:\Qt\5.8.0\include\QtCore/qvector.h(73): error C2182: 't': illegal use of 
type 'void'
1>  E:\Qt\5.8.0\include\QtConcurrent/qtconcurrentreducekernel.h(82): note: see 
reference to class template instantiation 'QVector' being compiled
1>  E:\Qt\5.8.0\include\QtConcurrent/qtconcurrentmapkernel.h(136): note: see 
reference to class template instantiation 
'QtConcurrent::IntermediateResults' being compiled
1>  with
1>  [
1>  T=void
1>  ]
1>E:\Qt\5.8.0\include\QtCore/qvector.h(134): error C2182: 'at': illegal use of 
type 'void'
1>E:\Qt\5.8.0\include\QtCore/qvector.h(135): error C2182: '[]': illegal use of 
type 'void'
1>E:\Qt\5.8.0\include\QtCore/qvector.h(136): error C2182: '[]': illegal use of 
type 'void'
1>E:\Qt\5.8.0\include\QtCore/qvector.h(137): error C2182: 't': illegal use of 
type 'void'
1>E:\Qt\5.8.0\include\QtCore/qvector.h(139): error C2182: 't': illegal use of 
type 'void'
1>E:\Qt\5.8.0\include\QtCore/qvector.h(142): error C2182: 't': illegal use of 
type 'void'
1>E:\Qt\5.8.0\include\QtCore/qvector.h(143): error C2182: 't': illegal use of 
type 'void'
1>E:\Qt\5.8.0\include\QtCore/qvector.h(144): error C2182: 't': illegal use of 
type 'void'

Re: [Interest] qobject_cast

[Igor Mironchik]

Hi,



If sender() is a Channel*, then qobject_cast should not fail.

Try to add this to your slot, this will print the inheritance list

 qDebug() << "Looking for" << ::staticMetaObject <<
Channel::staticMetaObject.className() << "on" << sender() <<
qobject_cast< Channel* > ( sender() )
 const QMetaObject *mo = sender->metaObject();
while (mo != nullptr) {
 qDebug() << mo << mo->className() << (mo ==
::staticMetaObject ? "<-" : "");
 mo = mo->superClass();
 }

This is roughly how QMetaObject::inherits() works. if you get the
"<-", then qobject_cast should work as expected.


I moved code to dlls and now qobject_cast<> works

Looking for 0xf39b050 Globe::Channel on Globe::ComoChannel(0x4210270, 
name = "Channel") Globe::ComoChannel(0x4210270, name = "Channel")


0xf04c018 Globe::ComoChannel

0xf39b050 Globe::Channel <-

0x663fc44c QObject


Thank you for the explanations...
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to handle Touch Input on C++ side when extending QQuickItem

[Alexandru Croitor]

So I found out about this recently as well, but touch events are not sent to 
QQuickItems on macOS by default, because QNativeGestures are sent instead, due 
to receiving high-precision gestures from the OS itself.

To receive touch events you need to use private API at the moment. Have a look 
at the implementation of

void QQuickMultiPointTouchArea::setTouchEventsEnabled(bool enable)

You would need to get the relevant function pointer and call 
registerTouchWindow on your custom QQuickItem.

On 20 Apr 2017, at 10:59, Nuno Santos 
> wrote:

Alexandru,

Mac OSX, testing with trackpad and mouse.

Regards,

Nuno

On 20 Apr 2017, at 09:36, Alexandru Croitor 
> wrote:

Hi.

What platform are you testing on?


On 20 Apr 2017, at 10:26, Nuno Santos 
> wrote:

Hi,

I would like to understand how can I handle a QQuickItem touch input when 
extending QQuickItem and creating my own item in C++

I can’t find documentation that explains this, neither examples. I have tried 
the following and none have worked.

What am I missing?

// Implementation

MyItem::MyItem(QQuickItem* parent) :
 QQuickItem(parent)
{
 setAcceptedMouseButtons(Qt::LeftButton);
 setFiltersChildMouseEvents(true);
 setKeepTouchGrab(true);
}

// Header

protected:
 void mousePressEvent(QMouseEvent *event) {
 QQuickItem::mousePressEvent(event);

 qDebug() << "mousePressEvent" << event->pos();
 }

 void mouseMoveEvent(QMouseEvent *event) {
 QQuickItem::mouseMoveEvent(event);

 qDebug() << "mouseMoveEvent" << event->pos();
 }

 void mouseReleaseEvent(QMouseEvent *event) {
 QQuickItem::mouseReleaseEvent(event);

 qDebug() << "mouseReleaseEvent" << event->pos();
 }

 void mouseReleaseEvent();

 void touchEvent(QTouchEvent* event) {
 qDebug() << "touch event" << event;
 }

 bool eventFilter(QObject *, QEvent *event)
 {
 qDebug() << "processing TouchUpdate...";

 if (event->type() == QEvent::TouchUpdate) {
 }
 // other Touch events here...

 return false;
 }

Thanks,

Regards,

Nuno
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest



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

[Interest] Can the new Qt 5 (function pointer based) connections ever fail?

[Sze Howe Koh]

Someone posted the quested at http://stackoverflow.com/
questions/43487752/when-qt-5-will-fail-the-connect and I'm curious to know
the answer.

Since the connections are checked at compile-time, does that mean
QObject::connect() is guaranteed to succeed at run-time unless a duplicate
connection is attempted with Qt::UniqueConnection?


Regards,
Sze-Howe
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] speeding up "make clean" in qt src on OS X?

[Konstantin Tokarev]

20.04.2017, 12:07, "Patrick Stinson" :
> I googled it. Just start with a clean or distclean'ed qt src dir

Yep, leftovers of generated files inside source dir would misguide qmake

> and call configure from another dir.
>
> cd my-qt5-build && ../path/to/qt/src/configure && make
>
>> On Apr 20, 2017, at 5:02 AM, Nuno Santos  wrote:
>>
>> How do you make out of the tree builds? How should one call the configure 
>> command for that?
>>
>>> On 20 Apr 2017, at 09:58, Patrick Stinson  wrote:
>>>
>>> Ah! I was not aware that you could do that. Thank you!
>>>
>>> -P
>>>
 On Apr 20, 2017, at 4:48 AM, Konstantin Tokarev  wrote:

 out-of-tree
>>> ___
>>> Interest mailing list
>>> Interest@qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/interest


-- 
Regards,
Konstantin
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] speeding up "make clean" in qt src on OS X?

[Konstantin Tokarev]

20.04.2017, 12:02, "Nuno Santos" :
> How do you make out of the tree builds? How should one call the configure 
> command for that?

Just like with autotools, call configure with pwd being build directory instead 
of source:

mkdir qt5-build
cd qt5-build
../qt5/configure

>
>> On 20 Apr 2017, at 09:58, Patrick Stinson  wrote:
>>
>> Ah! I was not aware that you could do that. Thank you!
>>
>> -P
>>
>>> On Apr 20, 2017, at 4:48 AM, Konstantin Tokarev  wrote:
>>>
>>> out-of-tree
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest


-- 
Regards,
Konstantin
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] speeding up "make clean" in qt src on OS X?

[Patrick Stinson]

I googled it. Just start with a clean or distclean'ed qt src dir and call 
configure from another dir.

cd my-qt5-build && ../path/to/qt/src/configure && make


> On Apr 20, 2017, at 5:02 AM, Nuno Santos  wrote:
> 
> How do you make out of the tree builds? How should one call the configure 
> command for that? 
> 
>> On 20 Apr 2017, at 09:58, Patrick Stinson > > wrote:
>> 
>> Ah! I was not aware that you could do that. Thank you!
>> 
>> -P
>> 
>>> On Apr 20, 2017, at 4:48 AM, Konstantin Tokarev >> > wrote:
>>> 
>>> out-of-tree
>> 
>> ___
>> Interest mailing list
>> Interest@qt-project.org 
>> http://lists.qt-project.org/mailman/listinfo/interest
> 



smime.p7s
Description: S/MIME cryptographic signature
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] speeding up "make clean" in qt src on OS X?

[Nuno Santos]

How do you make out of the tree builds? How should one call the configure 
command for that? 

> On 20 Apr 2017, at 09:58, Patrick Stinson  wrote:
> 
> Ah! I was not aware that you could do that. Thank you!
> 
> -P
> 
>> On Apr 20, 2017, at 4:48 AM, Konstantin Tokarev > > wrote:
>> 
>> out-of-tree
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

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

Re: [Interest] How to handle Touch Input on C++ side when extending QQuickItem

[Nuno Santos]

Alexandru,

Mac OSX, testing with trackpad and mouse.

Regards,

Nuno

> On 20 Apr 2017, at 09:36, Alexandru Croitor  wrote:
> 
> Hi.
> 
> What platform are you testing on?
> 
> 
>> On 20 Apr 2017, at 10:26, Nuno Santos  wrote:
>> 
>> Hi,
>> 
>> I would like to understand how can I handle a QQuickItem touch input when 
>> extending QQuickItem and creating my own item in C++
>> 
>> I can’t find documentation that explains this, neither examples. I have 
>> tried the following and none have worked.
>> 
>> What am I missing?
>> 
>> // Implementation
>> 
>> MyItem::MyItem(QQuickItem* parent) :
>>   QQuickItem(parent)
>> {
>>   setAcceptedMouseButtons(Qt::LeftButton);
>>   setFiltersChildMouseEvents(true);
>>   setKeepTouchGrab(true);
>> }
>> 
>> // Header
>> 
>> protected:
>>   void mousePressEvent(QMouseEvent *event) {
>>   QQuickItem::mousePressEvent(event);
>> 
>>   qDebug() << "mousePressEvent" << event->pos();
>>   }
>> 
>>   void mouseMoveEvent(QMouseEvent *event) {
>>   QQuickItem::mouseMoveEvent(event);
>> 
>>   qDebug() << "mouseMoveEvent" << event->pos();
>>   }
>> 
>>   void mouseReleaseEvent(QMouseEvent *event) {
>>   QQuickItem::mouseReleaseEvent(event);
>> 
>>   qDebug() << "mouseReleaseEvent" << event->pos();
>>   }
>> 
>>   void mouseReleaseEvent();
>> 
>>   void touchEvent(QTouchEvent* event) {
>>   qDebug() << "touch event" << event;
>>   }
>> 
>>   bool eventFilter(QObject *, QEvent *event)
>>   {
>>   qDebug() << "processing TouchUpdate...";
>> 
>>   if (event->type() == QEvent::TouchUpdate) {
>>   }
>>   // other Touch events here...
>> 
>>   return false;
>>   }
>> 
>> Thanks,
>> 
>> Regards,
>> 
>> Nuno
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
> 

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

[Interest] Qt3d - on any embedded board?

[Pierre Chicoine]

Has anyone tried getting Qt3d running on any embedded board? I've tried it
on Raspberry Pi. Doesn't work. Maybe a Mali GPU with an Arm processor
board? Anyone?
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] speeding up "make clean" in qt src on OS X?

[Patrick Stinson]

Ah! I was not aware that you could do that. Thank you!

-P

> On Apr 20, 2017, at 4:48 AM, Konstantin Tokarev  wrote:
> 
> out-of-tree



smime.p7s
Description: S/MIME cryptographic signature
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] speeding up "make clean" in qt src on OS X?

[Konstantin Tokarev]

20.04.2017, 11:34, "Patrick Stinson" :
> Hello!
>
> Running “make clean” in the root qt src dir calls xcodebuild a whole bunch of 
> times and takes a really, really long time. Is there any faster way to do 
> this?

Yes, use out-of-tree build and remove contents of build directory.

>I am already excluding a lot of unnecessary builds in my configure line:
>
> ./configure -static -debug-and-release -nomake examples -xplatform 
> macx-ios-clang -sdk iphoneos -nomake tests -skip qt3d -skip qtactiveqt -skip 
> qtandroidextras -skip qtcanvas3d -skip qtcharts -skip qtconnectivity -skip 
> qtdatavis3d -skip qtdeclarative -skip qtdoc -skip qtdocgallery -skip 
> qtenginio -skip qtfeedback -skip qtgamepad -skip qtgraphicaleffects -skip 
> qtimageformats -skip qtlocation -skip qtmacextras -skip qtmultimedia -skip 
> qtnetworkauth -skip qtpim -skip qtqa -skip qtquick1 -skip qtquickcontrols 
> -skip qtquickcontrols2 -skip qtrepotools -skip qtscript -skip qtscxml -skip 
> qtserialbus -skip qtserialport -skip qtspeech -skip qtsvg -skip qtsystems 
> -skip qttools -skip qttranslations -skip qtvirtualkeyboard -skip qtwayland 
> -skip qtwebchannel -skip qtwebengine -skip qtwebkit -skip qtwebkit-examples 
> -skip qtwebsockets -skip qtwebview -skip qtwinextras -skip qtx11extras 
> -developer-build -opensource -confirm-license
>
> and it still runs a bunch of xcodebuild calls like this:
>
> rm -f .obj/tst_qpixelformat_plugin_import.o
> rm -f *~ core *.core
> cd qopenglwindow/ && ( test -e Makefile || 
> /Users/patrick/dev/vendor/pyqt-sysroot-ios-64/src/qt5/qtbase/bin/qmake -o 
> Makefile 
> /Users/patrick/dev/vendor/pyqt-sysroot-ios-64/src/qt5/qtbase/tests/auto/gui/kernel/qopenglwindow/qopenglwindow.pro
>  ) && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f Makefile 
> clean
> xcodebuild clean  -project tst_qopenglwindow.xcodeproj -scheme 
> tst_qopenglwindow   -configuration Debug  -destination generic/platform=iOS 
> -destination-timeout 1
> === CLEAN AGGREGATE TARGET Qt Preprocess OF PROJECT tst_qopenglwindow WITH 
> CONFIGURATION Debug ===
>
> Check dependencies
>
> Clean.Remove clean .obj/tst_qopenglwindow.build/Debug-iphoneos/Qt\ 
> Preprocess.build
>     builtin-rm -rf 
> /Users/patrick/dev/vendor/pyqt-sysroot-ios-64/src/qt5/qtbase/tests/auto/gui/kernel/qopenglwindow/.obj/tst_qopenglwindow.build/Debug-iphoneos/Qt\
>  Preprocess.build
>
> === CLEAN TARGET tst_qopenglwindow OF PROJECT tst_qopenglwindow WITH 
> CONFIGURATION Debug ===
>
> Check dependencies
>
> Create product structure
> /bin/mkdir -p 
> /Users/patrick/dev/vendor/pyqt-sysroot-ios-64/src/qt5/qtbase/tests/auto/gui/kernel/qopenglwindow/Debug-iphoneos/tst_qopenglwindow.app
>
> Clean.Remove clean Debug-iphoneos/tst_qopenglwindow.app
>     builtin-rm -rf 
> /Users/patrick/dev/vendor/pyqt-sysroot-ios-64/src/qt5/qtbase/tests/auto/gui/kernel/qopenglwindow/Debug-iphoneos/tst_qopenglwindow.app
>
> Clean.Remove clean 
> .obj/tst_qopenglwindow.build/Debug-iphoneos/tst_qopenglwindow.build
>     builtin-rm -rf 
> /Users/patrick/dev/vendor/pyqt-sysroot-ios-64/src/qt5/qtbase/tests/auto/gui/kernel/qopenglwindow/.obj/tst_qopenglwindow.build/Debug-iphoneos/tst_qopenglwindow.build
>
> ** CLEAN SUCCEEDED **
>
> Thanks!
> -P
> ,
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest


-- 
Regards,
Konstantin
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to handle Touch Input on C++ side when extending QQuickItem

[Alexandru Croitor]

Hi.

What platform are you testing on?


> On 20 Apr 2017, at 10:26, Nuno Santos  wrote:
> 
> Hi,
> 
> I would like to understand how can I handle a QQuickItem touch input when 
> extending QQuickItem and creating my own item in C++
> 
> I can’t find documentation that explains this, neither examples. I have tried 
> the following and none have worked.
> 
> What am I missing?
> 
> // Implementation
> 
> MyItem::MyItem(QQuickItem* parent) :
>QQuickItem(parent)
> {
>setAcceptedMouseButtons(Qt::LeftButton);
>setFiltersChildMouseEvents(true);
>setKeepTouchGrab(true);
> }
> 
> // Header
> 
> protected:
>void mousePressEvent(QMouseEvent *event) {
>QQuickItem::mousePressEvent(event);
> 
>qDebug() << "mousePressEvent" << event->pos();
>}
> 
>void mouseMoveEvent(QMouseEvent *event) {
>QQuickItem::mouseMoveEvent(event);
> 
>qDebug() << "mouseMoveEvent" << event->pos();
>}
> 
>void mouseReleaseEvent(QMouseEvent *event) {
>QQuickItem::mouseReleaseEvent(event);
> 
>qDebug() << "mouseReleaseEvent" << event->pos();
>}
> 
>void mouseReleaseEvent();
> 
>void touchEvent(QTouchEvent* event) {
>qDebug() << "touch event" << event;
>}
> 
>bool eventFilter(QObject *, QEvent *event)
>{
>qDebug() << "processing TouchUpdate...";
> 
>if (event->type() == QEvent::TouchUpdate) {
>}
>// other Touch events here...
> 
>return false;
>}
> 
> Thanks,
> 
> Regards,
> 
> Nuno
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

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

[Interest] speeding up "make clean" in qt src on OS X?

[Patrick Stinson]

Hello!

Running “make clean” in the root qt src dir calls xcodebuild a whole bunch of 
times and takes a really, really long time. Is there any faster way to do this? 
I am already excluding a lot of unnecessary builds in my configure line:

./configure -static -debug-and-release -nomake examples -xplatform 
macx-ios-clang -sdk iphoneos -nomake tests -skip qt3d -skip qtactiveqt -skip 
qtandroidextras -skip qtcanvas3d -skip qtcharts -skip qtconnectivity -skip 
qtdatavis3d -skip qtdeclarative -skip qtdoc -skip qtdocgallery -skip qtenginio 
-skip qtfeedback -skip qtgamepad -skip qtgraphicaleffects -skip qtimageformats 
-skip qtlocation -skip qtmacextras -skip qtmultimedia -skip qtnetworkauth -skip 
qtpim -skip qtqa -skip qtquick1 -skip qtquickcontrols -skip qtquickcontrols2 
-skip qtrepotools -skip qtscript -skip qtscxml -skip qtserialbus -skip 
qtserialport -skip qtspeech -skip qtsvg -skip qtsystems -skip qttools -skip 
qttranslations -skip qtvirtualkeyboard -skip qtwayland -skip qtwebchannel -skip 
qtwebengine -skip qtwebkit -skip qtwebkit-examples -skip qtwebsockets -skip 
qtwebview -skip qtwinextras -skip qtx11extras -developer-build -opensource 
-confirm-license

and it still runs a bunch of xcodebuild calls like this:

rm -f .obj/tst_qpixelformat_plugin_import.o
rm -f *~ core *.core
cd qopenglwindow/ && ( test -e Makefile || 
/Users/patrick/dev/vendor/pyqt-sysroot-ios-64/src/qt5/qtbase/bin/qmake -o 
Makefile 
/Users/patrick/dev/vendor/pyqt-sysroot-ios-64/src/qt5/qtbase/tests/auto/gui/kernel/qopenglwindow/qopenglwindow.pro
 ) && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f Makefile clean
xcodebuild clean  -project tst_qopenglwindow.xcodeproj -scheme 
tst_qopenglwindow   -configuration Debug  -destination generic/platform=iOS 
-destination-timeout 1 
=== CLEAN AGGREGATE TARGET Qt Preprocess OF PROJECT tst_qopenglwindow WITH 
CONFIGURATION Debug ===

Check dependencies

Clean.Remove clean .obj/tst_qopenglwindow.build/Debug-iphoneos/Qt\ 
Preprocess.build
builtin-rm -rf 
/Users/patrick/dev/vendor/pyqt-sysroot-ios-64/src/qt5/qtbase/tests/auto/gui/kernel/qopenglwindow/.obj/tst_qopenglwindow.build/Debug-iphoneos/Qt\
 Preprocess.build

=== CLEAN TARGET tst_qopenglwindow OF PROJECT tst_qopenglwindow WITH 
CONFIGURATION Debug ===

Check dependencies

Create product structure
/bin/mkdir -p 
/Users/patrick/dev/vendor/pyqt-sysroot-ios-64/src/qt5/qtbase/tests/auto/gui/kernel/qopenglwindow/Debug-iphoneos/tst_qopenglwindow.app

Clean.Remove clean Debug-iphoneos/tst_qopenglwindow.app
builtin-rm -rf 
/Users/patrick/dev/vendor/pyqt-sysroot-ios-64/src/qt5/qtbase/tests/auto/gui/kernel/qopenglwindow/Debug-iphoneos/tst_qopenglwindow.app

Clean.Remove clean 
.obj/tst_qopenglwindow.build/Debug-iphoneos/tst_qopenglwindow.build
builtin-rm -rf 
/Users/patrick/dev/vendor/pyqt-sysroot-ios-64/src/qt5/qtbase/tests/auto/gui/kernel/qopenglwindow/.obj/tst_qopenglwindow.build/Debug-iphoneos/tst_qopenglwindow.build

** CLEAN SUCCEEDED **


Thanks!
-P

smime.p7s
Description: S/MIME cryptographic signature
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] How to handle Touch Input on C++ side when extending QQuickItem

[Nuno Santos]

Hi,

I would like to understand how can I handle a QQuickItem touch input when 
extending QQuickItem and creating my own item in C++

I can’t find documentation that explains this, neither examples. I have tried 
the following and none have worked.

What am I missing?

// Implementation

MyItem::MyItem(QQuickItem* parent) :
QQuickItem(parent)
{
setAcceptedMouseButtons(Qt::LeftButton);
setFiltersChildMouseEvents(true);
setKeepTouchGrab(true);
}

// Header

protected:
void mousePressEvent(QMouseEvent *event) {
QQuickItem::mousePressEvent(event);

qDebug() << "mousePressEvent" << event->pos();
}

void mouseMoveEvent(QMouseEvent *event) {
QQuickItem::mouseMoveEvent(event);

qDebug() << "mouseMoveEvent" << event->pos();
}

void mouseReleaseEvent(QMouseEvent *event) {
QQuickItem::mouseReleaseEvent(event);

qDebug() << "mouseReleaseEvent" << event->pos();
}

void mouseReleaseEvent();

void touchEvent(QTouchEvent* event) {
qDebug() << "touch event" << event;
}

bool eventFilter(QObject *, QEvent *event)
{
qDebug() << "processing TouchUpdate...";

if (event->type() == QEvent::TouchUpdate) {
}
// other Touch events here...

return false;
}

Thanks,

Regards,

Nuno
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Is freshly created QNetworkReply guaranteed to be in non-finished state and emit finished signal?

[ekke]

Am 19.04.17 um 22:58 schrieb Thiago Macieira:
> On quarta-feira, 19 de abril de 2017 13:15:23 PDT Reinhardt Behm wrote:
>> On Wednesday 19 April 2017 11:03:48 Thiago Macieira wrote:
>>> It's guaranteed not to be finished.
>> Doesn't QAN use it's own thread? 
> Irrelevant.
>
>> Then it could already be finished before the connection is made.
> It can't happen. This is a design guarantee and will continue to work however 
> much we change QNAM.
>
> That said, for certain URLs (namely, "file:///"), isFinished() may return 
> true, 
> in which case you can obtain the data immediately. But even if that is the 
> case, finished() will still be emitted.
>
what happens on mobile platforms if APP is suspended, then coming back
to active
will finished() always be received ?

haven't tested this in detail yet for QNAM requests

I already tested QNetworkConfigurationManager on Android, where signals
(onlineStateChanged) are queued while suspended
coming back to active all signals are received.
tested this with App 10 minutes suspended and switching airplane mode
on- off

ekke
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QtQuick import question

[Mitch Curtis]

In the meantime, you could create a suggestion for it so we have some way of 
tracking it.

From: Interest [mailto:interest-bounces+mitch.curtis=qt...@qt-project.org] On 
Behalf Of Mitch Curtis
Sent: Thursday, 20 April 2017 9:22 AM
To: Elvis Stansvik 
Cc: interest@qt-project.org Interest 
Subject: Re: [Interest] QtQuick import question

I don’t know. CCing JP who wrote it.

From: Elvis Stansvik [mailto:elvst...@gmail.com]
Sent: Thursday, 20 April 2017 8:42 AM
To: Mitch Curtis >
Cc: interest@qt-project.org Interest 
>; Viktor Engelmann 
>
Subject: RE: [Interest] QtQuick import question


Den 19 apr. 2017 11:07 fm skrev "Mitch Curtis" 
>:
>
> For what it’s worth, the documentation for Qt Quick Controls 2 has (or will 
> have) such a table (although starting at Qt 5.7, which is when they were 
> released):
>
>
>
> https://doc-snapshots.qt.io/qt5-5.9/qtquickcontrols2-index.html#versions

That's great to see. Do you know if the table will be extended to cover all 
imports (QtQuick.Window, QtQuick.Layout, ...)?

Elvis

>
>
>
> From: Interest 
> [mailto:interest-bounces+mitch.curtis=qt...@qt-project.org]
>  On Behalf Of Elvis Stansvik
> Sent: Thursday, 13 April 2017 7:02 PM
> To: Viktor Engelmann >
> Cc: interest@qt-project.org Interest 
> >
> Subject: Re: [Interest] QtQuick import question
>
>
>
>
> Den 13 apr. 2017 10:13 fm skrev "Viktor Engelmann" 
> >:
> >
> > The _version_ only affects which properties/methods are visible, so you 
> > should always go for the minimal version that has all the interfaces you 
> > use.
> >
> > say there is a qml class foo. in version 1.0 it has method bar, in 1.1 it 
> > also has method ham and in 1.2 method eggs.
> >
> > if you import 1.2 although you only use bar and ham, it won't run on 
> > systems that only have version 1.1 although it could. On systems that have 
> > 1.2, you still have all the bugfixes that went into bar and ham between 1.1 
> > and 1.2 - again, the version only affects which parts of the interface are 
> > visible.
>
> Right, I know how the versioning works, and I can sort of see the need/reason 
> for individual versioning of the Quick modules. I also agree that it's my 
> responsibility as a developer, packager and distributor of my software to 
> keep track of these things. I just wish that
>
> a) I could have more support from the Qt docs in this, like a table mapping 
> Qt versions to the QML versions included in that release, and
>
> b) A shorthand was available where I could say that "I'm targeting Qt >= 
> x.y.z" and be allowed to leave out the version in my QML imports (they would 
> default to the version included in Qt x.y.z)
>
> All this to avoid having to repeatedly specify the version while importing, 
> and having to remember a bunch of 2.2, 2.4, 1.4,... numbers in my head while 
> coding, which is something I've never had to do with other frameworks, no 
> matter how modularized.
>
> Elvis
>
> >
> > Viktor
> >
> > p.s. I don't think that other languages "get away without having a 
> > version". In other languages, you only push the trouble onto someone else. 
> > So you have for example a windows 9x, a win NT, a win vista,... version of 
> > your program and the customer must know which windows version he has (plus 
> > you need to bundle all the non-OS libraries you use, polluting the 
> > customers hard drive). And that approach only works for OSes that have a 
> > very limited set of releases, which isn't the case for linux.
> > On linux, it's the packagers' job to know which version of which library 
> > has which interface. That's why you have versioned dependencies in .deb 
> > packages for example (and that makes things a lot more difficult without 
> > any benefit).
> >
> >
> >
> > On 13.04.2017 08:48, Elvis Stansvik wrote:
> >>
> >> Den 13 apr. 2017 2:52 fm skrev "Jason H" 
> >> >:
> >> >
> >> >
> >> >
> >> > > Sent: Wednesday, April 12, 2017 at 12:05 PM
> >> > > From: "VStevenP via Interest" 
> >> > > >
> >> > > To: interest@qt-project.org
> >> > > Subject: [Interest] QtQuick import question
> >> > >
> >> > > When importing a QtQuick version, is it best to import the most recent 
> >> > > version, or the minimum version that supports the features 
> >> > > (properties, etc.) of the components being used?
> >> >
> >> > I've asked this before as well, I don't remember 

Re: [Interest] QtQuick import question

[Mitch Curtis]

I don’t know. CCing JP who wrote it.

From: Elvis Stansvik [mailto:elvst...@gmail.com]
Sent: Thursday, 20 April 2017 8:42 AM
To: Mitch Curtis 
Cc: interest@qt-project.org Interest ; Viktor 
Engelmann 
Subject: RE: [Interest] QtQuick import question


Den 19 apr. 2017 11:07 fm skrev "Mitch Curtis" 
>:
>
> For what it’s worth, the documentation for Qt Quick Controls 2 has (or will 
> have) such a table (although starting at Qt 5.7, which is when they were 
> released):
>
>
>
> https://doc-snapshots.qt.io/qt5-5.9/qtquickcontrols2-index.html#versions

That's great to see. Do you know if the table will be extended to cover all 
imports (QtQuick.Window, QtQuick.Layout, ...)?

Elvis

>
>
>
> From: Interest 
> [mailto:interest-bounces+mitch.curtis=qt...@qt-project.org]
>  On Behalf Of Elvis Stansvik
> Sent: Thursday, 13 April 2017 7:02 PM
> To: Viktor Engelmann >
> Cc: interest@qt-project.org Interest 
> >
> Subject: Re: [Interest] QtQuick import question
>
>
>
>
> Den 13 apr. 2017 10:13 fm skrev "Viktor Engelmann" 
> >:
> >
> > The _version_ only affects which properties/methods are visible, so you 
> > should always go for the minimal version that has all the interfaces you 
> > use.
> >
> > say there is a qml class foo. in version 1.0 it has method bar, in 1.1 it 
> > also has method ham and in 1.2 method eggs.
> >
> > if you import 1.2 although you only use bar and ham, it won't run on 
> > systems that only have version 1.1 although it could. On systems that have 
> > 1.2, you still have all the bugfixes that went into bar and ham between 1.1 
> > and 1.2 - again, the version only affects which parts of the interface are 
> > visible.
>
> Right, I know how the versioning works, and I can sort of see the need/reason 
> for individual versioning of the Quick modules. I also agree that it's my 
> responsibility as a developer, packager and distributor of my software to 
> keep track of these things. I just wish that
>
> a) I could have more support from the Qt docs in this, like a table mapping 
> Qt versions to the QML versions included in that release, and
>
> b) A shorthand was available where I could say that "I'm targeting Qt >= 
> x.y.z" and be allowed to leave out the version in my QML imports (they would 
> default to the version included in Qt x.y.z)
>
> All this to avoid having to repeatedly specify the version while importing, 
> and having to remember a bunch of 2.2, 2.4, 1.4,... numbers in my head while 
> coding, which is something I've never had to do with other frameworks, no 
> matter how modularized.
>
> Elvis
>
> >
> > Viktor
> >
> > p.s. I don't think that other languages "get away without having a 
> > version". In other languages, you only push the trouble onto someone else. 
> > So you have for example a windows 9x, a win NT, a win vista,... version of 
> > your program and the customer must know which windows version he has (plus 
> > you need to bundle all the non-OS libraries you use, polluting the 
> > customers hard drive). And that approach only works for OSes that have a 
> > very limited set of releases, which isn't the case for linux.
> > On linux, it's the packagers' job to know which version of which library 
> > has which interface. That's why you have versioned dependencies in .deb 
> > packages for example (and that makes things a lot more difficult without 
> > any benefit).
> >
> >
> >
> > On 13.04.2017 08:48, Elvis Stansvik wrote:
> >>
> >> Den 13 apr. 2017 2:52 fm skrev "Jason H" 
> >> >:
> >> >
> >> >
> >> >
> >> > > Sent: Wednesday, April 12, 2017 at 12:05 PM
> >> > > From: "VStevenP via Interest" 
> >> > > >
> >> > > To: interest@qt-project.org
> >> > > Subject: [Interest] QtQuick import question
> >> > >
> >> > > When importing a QtQuick version, is it best to import the most recent 
> >> > > version, or the minimum version that supports the features 
> >> > > (properties, etc.) of the components being used?
> >> >
> >> > I've asked this before as well, I don't remember getting an answer. I go 
> >> > with whatever the documentation for the Qt version I'm using says, 
> >> > because there is no substantive table of what is in what version.
> >> >
> >> > I'd love to use min version, but sometimes you just don't know. Also, 
> >> > there is no clear reason (that I can tell) to have a version.  I think 
> >> > it would be nightmareish if Qt backeded every version of QML import that 
> >> > is actually listed in my app, so I assume the version is min version.  
> >> > Every 

Re: [Interest] qobject_cast

[Ch'Gans]

On 20 April 2017 at 19:04, Igor Mironchik  wrote:
> Hi,
>
> If sender() is a Channel*, then qobject_cast should not fail.
>
> Try to add this to your slot, this will print the inheritance list
>
> qDebug() << "Looking for" << ::staticMetaObject <<
> Channel::staticMetaObject.className() << "on" << sender() <<
> qobject_cast< Channel* > ( sender() )
> const QMetaObject *mo = sender->metaObject();
>while (mo != nullptr) {
> qDebug() << mo << mo->className() << (mo ==
> ::staticMetaObject ? "<-" : "");
> mo = mo->superClass();
> }
>
> This is roughly how QMetaObject::inherits() works. if you get the
> "<-", then qobject_cast should work as expected.
>
>
> I got:
>
> Looking for 0xe6b188 Globe::Channel on Globe::ComoChannel(0x4500270, name =
> "Channel") QObject(0x0)
>
> 0xd49548 Globe::ComoChannel
>
> 0xd4f060 Globe::Channel
>
> 0x6683c44c QObject
>
>
> And as I can guess it's because of static linking. I.e. I have static lib
> where Channel defined. And this lib linking to app and to plugin.

Sounds like a bad idea indeed! You have two copies of the same meta-data
Use dynamic libraries instead.

Chris

>
>
> Am I right that I should use dynamic libs?
>
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] qobject_cast

[Igor Mironchik]

Hi,


If sender() is a Channel*, then qobject_cast should not fail.

Try to add this to your slot, this will print the inheritance list

 qDebug() << "Looking for" << ::staticMetaObject <<
Channel::staticMetaObject.className() << "on" << sender() <<
qobject_cast< Channel* > ( sender() )
 const QMetaObject *mo = sender->metaObject();
while (mo != nullptr) {
 qDebug() << mo << mo->className() << (mo ==
::staticMetaObject ? "<-" : "");
 mo = mo->superClass();
 }

This is roughly how QMetaObject::inherits() works. if you get the
"<-", then qobject_cast should work as expected.


I got:

Looking for 0xe6b188 Globe::Channel on Globe::ComoChannel(0x4500270, 
name = "Channel") QObject(0x0)


0xd49548 Globe::ComoChannel

0xd4f060 Globe::Channel

0x6683c44c QObject


And as I can guess it's because of static linking. I.e. I have static 
lib where Channel defined. And this lib linking to app and to plugin.



Am I right that I should use dynamic libs?


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

Re: [Interest] qobject_cast

[Ch'Gans]

On 20 April 2017 at 18:10, Igor Mironchik  wrote:
>
>
> 20.04.2017 9:01, Ch'Gans пишет:
>
> On 20 April 2017 at 17:56, Igor Mironchik  wrote:
>
> 20.04.2017 8:47, Ch'Gans пишет:
>
> On 20 April 2017 at 17:03, Igor Mironchik 
> wrote:
>
> Hi,
>
>
> 20.04.2017 7:52, Ch'Gans пишет:
>
> On 20 April 2017 at 16:38, Igor Mironchik 
> wrote:
>
> Hi,
>
> What the benefits of qobject_cast<> on simple static_cast<>? Or there
> is
> no
>
> qobject_cast
> - works only on QObject (obviously)
> - returns nullptr if the object cannot be casted to the required type
>
> And it can fail if QObject derived pointer was returned from plugin.
>
> Is this a statement or a question?
>
> if I'm not wrong, qobject_cast relies on QMetaObject
> (object->metaObject() and Class::staticMetaObject()).
>
> Actually, i've just checked the sources and qobject_cast(object)
> returns "static_cast(T::staticMetaObject().cast(object))" and
> QMetaObject::cast(obj) returns "(obj &&
> obj->metaObject()->inherits(this)) ? obj : nullptr"
>
> QMetaObject allows you to walk the class inheritance hierarchy, and
> inherits() does exactly this.
> I don't think that the fact that the object comes from a plugin can
> make inherits() fail.
> If you are able to load the plugin successfully, it means that you
> have no unresolved symbols.
>
> Exactly! qobject_cast<> will fail.
>
> Look in application you have:
>
> class Channel
>   :  public QObject
> {};
>
> In plugin you have:
>
> class MyChannel
>   :  public Channel
> {};
>
> Channel * create();
>
> In application you call:
>
> Channel * ch = create();
>
> And use this object in your application.
>
> Then in one slot in application you can have:
>
> void mySlot()
> {
>   Channel * ch = qobject_cast< Channel* > ( sender() );
>   // You are 100% sure that sender() is Channel!!!
>   // And this cast will fail!!!
>
> Try to call dumpObjectInfo(sender());
>
>
> OBJECT Globe::ComoChannel::Channel

If sender() is a Channel*, then qobject_cast should not fail.

Try to add this to your slot, this will print the inheritance list

qDebug() << "Looking for" << ::staticMetaObject <<
Channel::staticMetaObject.className() << "on" << sender() <<
qobject_cast< Channel* > ( sender() )
const QMetaObject *mo = sender->metaObject();
   while (mo != nullptr) {
qDebug() << mo << mo->className() << (mo ==
::staticMetaObject ? "<-" : "");
mo = mo->superClass();
}

This is roughly how QMetaObject::inherits() works. if you get the
"<-", then qobject_cast should work as expected.

Chris

>
> SIGNALS OUT
>
> signal: destroyed(QObject*)
>
> signal: destroyed()
>
> signal: objectNameChanged(QString)
>
> signal: sourceUpdated(Como::Source)
>
> 
>
> signal: sourceDeregistered(Como::Source)
>
> 
>
> signal: connected()
>
> 
>
> 
>
> signal: disconnected()
>
> 
>
> 
>
> 
>
> signal: messagesRate(int)
>
> 
>
> signal: aboutToConnectToHost(QHostAddress,ushort)
>
> 
>
> signal: aboutToDisconnectFromHost()
>
> 
>
> signal: aboutToSendGetListOfSources()
>
> 
>
> SIGNALS IN
>
> <-- QTimer::unnamed 
>
> <-- QTimer::unnamed 
>
> <-- Como::ClientSocket::unnamed 
>
> <-- Como::ClientSocket::unnamed 
>
> <-- Como::ClientSocket::unnamed 
>
> <-- Como::ClientSocket::unnamed 
>
> <-- Como::ClientSocket::unnamed 
>
>
>
>
>
> Chris
>
> }
>
> AFAIK, the only problems with plugins is meta-type registration that
> has to be done explicitly by calling qRegisterMataType(...);
> I don't think that QMetaObject suffers from this. Maybe someone can
> confirm this.
>
> - doesn't relies on RTTI, and is way faster than dynamic cast
>
> This is understandable. But with comparison with static cast there are no
> benefits?
>
> My point was: dynamic_cast is safer than static_cast, and qobject_cast
> is faster than dynamic_cast.
>
> So qobject_cast is a "double win" over static_cast and dynamic_cast.
>
> Chris
>
> Chris
>
> one?
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QtQuick import question

[Elvis Stansvik]

Den 19 apr. 2017 11:07 fm skrev "Mitch Curtis" :
>
> For what it’s worth, the documentation for Qt Quick Controls 2 has (or
will have) such a table (although starting at Qt 5.7, which is when they
were released):
>
>
>
> https://doc-snapshots.qt.io/qt5-5.9/qtquickcontrols2-index.html#versions

That's great to see. Do you know if the table will be extended to cover all
imports (QtQuick.Window, QtQuick.Layout, ...)?

Elvis

>
>
>
> From: Interest [mailto:interest-bounces+mitch.curtis=qt...@qt-project.org]
On Behalf Of Elvis Stansvik
> Sent: Thursday, 13 April 2017 7:02 PM
> To: Viktor Engelmann 
> Cc: interest@qt-project.org Interest 
> Subject: Re: [Interest] QtQuick import question
>
>
>
>
> Den 13 apr. 2017 10:13 fm skrev "Viktor Engelmann" :
> >
> > The _version_ only affects which properties/methods are visible, so you
should always go for the minimal version that has all the interfaces you
use.
> >
> > say there is a qml class foo. in version 1.0 it has method bar, in 1.1
it also has method ham and in 1.2 method eggs.
> >
> > if you import 1.2 although you only use bar and ham, it won't run on
systems that only have version 1.1 although it could. On systems that have
1.2, you still have all the bugfixes that went into bar and ham between 1.1
and 1.2 - again, the version only affects which parts of the interface are
visible.
>
> Right, I know how the versioning works, and I can sort of see the
need/reason for individual versioning of the Quick modules. I also agree
that it's my responsibility as a developer, packager and distributor of my
software to keep track of these things. I just wish that
>
> a) I could have more support from the Qt docs in this, like a table
mapping Qt versions to the QML versions included in that release, and
>
> b) A shorthand was available where I could say that "I'm targeting Qt >=
x.y.z" and be allowed to leave out the version in my QML imports (they
would default to the version included in Qt x.y.z)
>
> All this to avoid having to repeatedly specify the version while
importing, and having to remember a bunch of 2.2, 2.4, 1.4,... numbers in
my head while coding, which is something I've never had to do with other
frameworks, no matter how modularized.
>
> Elvis
>
> >
> > Viktor
> >
> > p.s. I don't think that other languages "get away without having a
version". In other languages, you only push the trouble onto someone else.
So you have for example a windows 9x, a win NT, a win vista,... version of
your program and the customer must know which windows version he has (plus
you need to bundle all the non-OS libraries you use, polluting the
customers hard drive). And that approach only works for OSes that have a
very limited set of releases, which isn't the case for linux.
> > On linux, it's the packagers' job to know which version of which
library has which interface. That's why you have versioned dependencies in
.deb packages for example (and that makes things a lot more difficult
without any benefit).
> >
> >
> >
> > On 13.04.2017 08:48, Elvis Stansvik wrote:
> >>
> >> Den 13 apr. 2017 2:52 fm skrev "Jason H" :
> >> >
> >> >
> >> >
> >> > > Sent: Wednesday, April 12, 2017 at 12:05 PM
> >> > > From: "VStevenP via Interest" 
> >> > > To: interest@qt-project.org
> >> > > Subject: [Interest] QtQuick import question
> >> > >
> >> > > When importing a QtQuick version, is it best to import the most
recent version, or the minimum version that supports the features
(properties, etc.) of the components being used?
> >> >
> >> > I've asked this before as well, I don't remember getting an answer.
I go with whatever the documentation for the Qt version I'm using says,
because there is no substantive table of what is in what version.
> >> >
> >> > I'd love to use min version, but sometimes you just don't know.
Also, there is no clear reason (that I can tell) to have a version.  I
think it would be nightmareish if Qt backeded every version of QML import
that is actually listed in my app, so I assume the version is min version.
Every other language gets away without having a version, I wonder why Qt
requires it in the source?
> >>
> >> +10, I would love if in our Quick application, we could just say "this
is the minimum Qt version we support" and avoid having to specify cryptic
versions on each QML import.
> >>
> >> The lack of docs on when/in which Qt version a particular QML version
of a certain module was added doesn't help.
> >>
> >> Elvis
> >>
> >> >
> >> >
> >> >
> >> >
> >> > ___
> >> > Interest mailing list
> >> > Interest@qt-project.org
> >> > http://lists.qt-project.org/mailman/listinfo/interest
> >>
> >>
> >>
> >> ___ Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
> >
> >
> > -- Viktor Engelmann Software 

Re: [Interest] qobject_cast

[Igor Mironchik]

20.04.2017 9:01, Ch'Gans пишет:

On 20 April 2017 at 17:56, Igor Mironchik  wrote:


20.04.2017 8:47, Ch'Gans пишет:


On 20 April 2017 at 17:03, Igor Mironchik 
wrote:

Hi,


20.04.2017 7:52, Ch'Gans пишет:

On 20 April 2017 at 16:38, Igor Mironchik 
wrote:

Hi,

What the benefits of qobject_cast<> on simple static_cast<>? Or there
is
no

qobject_cast
- works only on QObject (obviously)
- returns nullptr if the object cannot be casted to the required type


And it can fail if QObject derived pointer was returned from plugin.

Is this a statement or a question?

if I'm not wrong, qobject_cast relies on QMetaObject
(object->metaObject() and Class::staticMetaObject()).

Actually, i've just checked the sources and qobject_cast(object)
returns "static_cast(T::staticMetaObject().cast(object))" and
QMetaObject::cast(obj) returns "(obj &&
obj->metaObject()->inherits(this)) ? obj : nullptr"

QMetaObject allows you to walk the class inheritance hierarchy, and
inherits() does exactly this.
I don't think that the fact that the object comes from a plugin can
make inherits() fail.
If you are able to load the plugin successfully, it means that you
have no unresolved symbols.


Exactly! qobject_cast<> will fail.

Look in application you have:

class Channel
   :  public QObject
{};

In plugin you have:

class MyChannel
   :  public Channel
{};

Channel * create();

In application you call:

Channel * ch = create();

And use this object in your application.

Then in one slot in application you can have:

void mySlot()
{
   Channel * ch = qobject_cast< Channel* > ( sender() );
   // You are 100% sure that sender() is Channel!!!
   // And this cast will fail!!!

Try to call dumpObjectInfo(sender());


OBJECT Globe::ComoChannel::Channel

SIGNALS OUT

signal: destroyed(QObject*)

signal: destroyed()

signal: objectNameChanged(QString)

signal: sourceUpdated(Como::Source)



signal: sourceDeregistered(Como::Source)



signal: connected()





signal: disconnected()







signal: messagesRate(int)



signal: aboutToConnectToHost(QHostAddress,ushort)



signal: aboutToDisconnectFromHost()



signal: aboutToSendGetListOfSources()



SIGNALS IN

<-- QTimer::unnamed 

<-- QTimer::unnamed 

<-- Como::ClientSocket::unnamed 

<-- Como::ClientSocket::unnamed 

<-- Como::ClientSocket::unnamed 

<-- Como::ClientSocket::unnamed 

<-- Como::ClientSocket::unnamed 






Chris


}


AFAIK, the only problems with plugins is meta-type registration that
has to be done explicitly by calling qRegisterMataType(...);
I don't think that QMetaObject suffers from this. Maybe someone can
confirm this.


- doesn't relies on RTTI, and is way faster than dynamic cast


This is understandable. But with comparison with static cast there are no
benefits?

My point was: dynamic_cast is safer than static_cast, and qobject_cast
is faster than dynamic_cast.

So qobject_cast is a "double win" over static_cast and dynamic_cast.

Chris


Chris


one?

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




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

Re: [Interest] qobject_cast

[Igor Mironchik]

Hi,

All is ok with Q_OBJECT in real code. This is just pseudo code...


20.04.2017 9:05, nikita baryshnikov пишет:

Hi, Igor

Your example is incorrect, cause you forget about Q_OBJECT macro in
Channel class

On Thu, Apr 20, 2017 at 8:56 AM, Igor Mironchik
 wrote:


20.04.2017 8:47, Ch'Gans пишет:


On 20 April 2017 at 17:03, Igor Mironchik 
wrote:

Hi,


20.04.2017 7:52, Ch'Gans пишет:

On 20 April 2017 at 16:38, Igor Mironchik 
wrote:

Hi,

What the benefits of qobject_cast<> on simple static_cast<>? Or there
is
no

qobject_cast
- works only on QObject (obviously)
- returns nullptr if the object cannot be casted to the required type


And it can fail if QObject derived pointer was returned from plugin.

Is this a statement or a question?

if I'm not wrong, qobject_cast relies on QMetaObject
(object->metaObject() and Class::staticMetaObject()).

Actually, i've just checked the sources and qobject_cast(object)
returns "static_cast(T::staticMetaObject().cast(object))" and
QMetaObject::cast(obj) returns "(obj &&
obj->metaObject()->inherits(this)) ? obj : nullptr"

QMetaObject allows you to walk the class inheritance hierarchy, and
inherits() does exactly this.
I don't think that the fact that the object comes from a plugin can
make inherits() fail.
If you are able to load the plugin successfully, it means that you
have no unresolved symbols.


Exactly! qobject_cast<> will fail.

Look in application you have:

class Channel
   :  public QObject
{};

In plugin you have:

class MyChannel
   :  public Channel
{};

Channel * create();

In application you call:

Channel * ch = create();

And use this object in your application.

Then in one slot in application you can have:

void mySlot()
{
   Channel * ch = qobject_cast< Channel* > ( sender() );
   // You are 100% sure that sender() is Channel!!!
   // And this cast will fail!!!

}


AFAIK, the only problems with plugins is meta-type registration that
has to be done explicitly by calling qRegisterMataType(...);
I don't think that QMetaObject suffers from this. Maybe someone can
confirm this.


- doesn't relies on RTTI, and is way faster than dynamic cast


This is understandable. But with comparison with static cast there are no
benefits?

My point was: dynamic_cast is safer than static_cast, and qobject_cast
is faster than dynamic_cast.

So qobject_cast is a "double win" over static_cast and dynamic_cast.

Chris


Chris


one?

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



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


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

Re: [Interest] qobject_cast

[nikita baryshnikov]

Hi, Igor

Your example is incorrect, cause you forget about Q_OBJECT macro in
Channel class

On Thu, Apr 20, 2017 at 8:56 AM, Igor Mironchik
 wrote:
>
>
> 20.04.2017 8:47, Ch'Gans пишет:
>
>> On 20 April 2017 at 17:03, Igor Mironchik 
>> wrote:
>>>
>>> Hi,
>>>
>>>
>>> 20.04.2017 7:52, Ch'Gans пишет:

 On 20 April 2017 at 16:38, Igor Mironchik 
 wrote:
>
> Hi,
>
> What the benefits of qobject_cast<> on simple static_cast<>? Or there
> is
> no

 qobject_cast
 - works only on QObject (obviously)
 - returns nullptr if the object cannot be casted to the required type
>>>
>>>
>>> And it can fail if QObject derived pointer was returned from plugin.
>>
>> Is this a statement or a question?
>>
>> if I'm not wrong, qobject_cast relies on QMetaObject
>> (object->metaObject() and Class::staticMetaObject()).
>>
>> Actually, i've just checked the sources and qobject_cast(object)
>> returns "static_cast(T::staticMetaObject().cast(object))" and
>> QMetaObject::cast(obj) returns "(obj &&
>> obj->metaObject()->inherits(this)) ? obj : nullptr"
>>
>> QMetaObject allows you to walk the class inheritance hierarchy, and
>> inherits() does exactly this.
>> I don't think that the fact that the object comes from a plugin can
>> make inherits() fail.
>> If you are able to load the plugin successfully, it means that you
>> have no unresolved symbols.
>
>
> Exactly! qobject_cast<> will fail.
>
> Look in application you have:
>
> class Channel
>   :  public QObject
> {};
>
> In plugin you have:
>
> class MyChannel
>   :  public Channel
> {};
>
> Channel * create();
>
> In application you call:
>
> Channel * ch = create();
>
> And use this object in your application.
>
> Then in one slot in application you can have:
>
> void mySlot()
> {
>   Channel * ch = qobject_cast< Channel* > ( sender() );
>   // You are 100% sure that sender() is Channel!!!
>   // And this cast will fail!!!
>
> }
>
>>
>> AFAIK, the only problems with plugins is meta-type registration that
>> has to be done explicitly by calling qRegisterMataType(...);
>> I don't think that QMetaObject suffers from this. Maybe someone can
>> confirm this.
>>
 - doesn't relies on RTTI, and is way faster than dynamic cast
>>>
>>>
>>> This is understandable. But with comparison with static cast there are no
>>> benefits?
>>
>> My point was: dynamic_cast is safer than static_cast, and qobject_cast
>> is faster than dynamic_cast.
>>
>> So qobject_cast is a "double win" over static_cast and dynamic_cast.
>>
>> Chris
>>
>>>
 Chris

> one?
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>>>
>>>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] qobject_cast

[Ch'Gans]

On 20 April 2017 at 17:56, Igor Mironchik  wrote:
>
>
> 20.04.2017 8:47, Ch'Gans пишет:
>
>> On 20 April 2017 at 17:03, Igor Mironchik 
>> wrote:
>>>
>>> Hi,
>>>
>>>
>>> 20.04.2017 7:52, Ch'Gans пишет:

 On 20 April 2017 at 16:38, Igor Mironchik 
 wrote:
>
> Hi,
>
> What the benefits of qobject_cast<> on simple static_cast<>? Or there
> is
> no

 qobject_cast
 - works only on QObject (obviously)
 - returns nullptr if the object cannot be casted to the required type
>>>
>>>
>>> And it can fail if QObject derived pointer was returned from plugin.
>>
>> Is this a statement or a question?
>>
>> if I'm not wrong, qobject_cast relies on QMetaObject
>> (object->metaObject() and Class::staticMetaObject()).
>>
>> Actually, i've just checked the sources and qobject_cast(object)
>> returns "static_cast(T::staticMetaObject().cast(object))" and
>> QMetaObject::cast(obj) returns "(obj &&
>> obj->metaObject()->inherits(this)) ? obj : nullptr"
>>
>> QMetaObject allows you to walk the class inheritance hierarchy, and
>> inherits() does exactly this.
>> I don't think that the fact that the object comes from a plugin can
>> make inherits() fail.
>> If you are able to load the plugin successfully, it means that you
>> have no unresolved symbols.
>
>
> Exactly! qobject_cast<> will fail.
>
> Look in application you have:
>
> class Channel
>   :  public QObject
> {};
>
> In plugin you have:
>
> class MyChannel
>   :  public Channel
> {};
>
> Channel * create();
>
> In application you call:
>
> Channel * ch = create();
>
> And use this object in your application.
>
> Then in one slot in application you can have:
>
> void mySlot()
> {
>   Channel * ch = qobject_cast< Channel* > ( sender() );
>   // You are 100% sure that sender() is Channel!!!
>   // And this cast will fail!!!

Try to call dumpObjectInfo(sender());

Chris

>
> }
>
>>
>> AFAIK, the only problems with plugins is meta-type registration that
>> has to be done explicitly by calling qRegisterMataType(...);
>> I don't think that QMetaObject suffers from this. Maybe someone can
>> confirm this.
>>
 - doesn't relies on RTTI, and is way faster than dynamic cast
>>>
>>>
>>> This is understandable. But with comparison with static cast there are no
>>> benefits?
>>
>> My point was: dynamic_cast is safer than static_cast, and qobject_cast
>> is faster than dynamic_cast.
>>
>> So qobject_cast is a "double win" over static_cast and dynamic_cast.
>>
>> Chris
>>
>>>
 Chris

> one?
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>>>
>>>
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest