Re: [Interest] QWebView vs. QWebEngine

[Walter Stefan]

Okay, thanks. This could have been written more clear on the webpage 

From: Jean-Michaël Celerier [mailto:jeanmichael.celer...@gmail.com]
Sent: Montag, 29. Jänner 2018 19:57
To: Walter Stefan 
Cc: Konstantin Tokarev ; interest@qt-project.org
Subject: Re: [Interest] QWebView vs. QWebEngine

> At this page there is written next to Qt Web Engine (under LGPL only). 
> Therefore I concluded that the rest is GPL.

If I am not mistaken it means instead that the rest is LGPL + commercial, which 
is Qt's "normal" license.

Best,
Jean-Michaël

On Mon, Jan 29, 2018 at 3:27 PM, Walter Stefan 
> wrote:
Thanks, because the web-page of Qt is confusing.

At this page there is written next to Qt Web Engine (under LGPL only). 
Therefore I concluded that the rest is GPL.

-Original Message-
From: Konstantin Tokarev [mailto:annu...@yandex.ru]
Sent: Montag, 29. Jänner 2018 18:20
To: Walter Stefan >; 
interest@qt-project.org
Subject: Re: [Interest] QWebView vs. QWebEngine



29.01.2018, 17:08, "Walter Stefan" 
>:
> Thanks for the quick response.
>
> Is there a web-link that supports this, or where can I seen the licenses to 
> the Qt modules?

https://webkit.org/licensing-webkit/
http://code.qt.io/cgit/qt/qtwebkit.git/tree/LICENSE.LGPLv21

>
> Best Regards,
> Stefan
>
> -Original Message-
> From: Konstantin Tokarev [mailto:annu...@yandex.ru]
> Sent: Montag, 29. Jänner 2018 18:05
> To: Walter Stefan >; 
> interest@qt-project.org
> Subject: Re: [Interest] QWebView vs. QWebEngine
>
> 29.01.2018, 16:58, "Walter Stefan" 
> >:
>>  Hi,
>>
>>  I’ve done some research about QWebView and QWebEngine and came to the 
>> following conclusion:
>>
>>  QWebView is under GPL and uses internally WebKit.
>
> Incorrect. QtWebKit code is LGPL+BSD.
>
>>  QWebEngine is under LGPL and uses internally Chromium.
>>
>>  Please let me know if this is correct, because I don’t want to disclose my 
>> source and that would mean I have to use QWebEngine.
>>
>>  Is there beside the license other limitations to be aware of?
>>
>>  Thanks and Regards,
>>
>>  Stefan
>>  ,
>>
>>  ___
>>  Interest mailing list
>>  Interest@qt-project.org
>>  http://lists.qt-project.org/mailman/listinfo/interest
>
> --
> Regards,
> Konstantin

--
Regards,
Konstantin

___
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] Lifetime of QNetworkReply from QNetworkAccessManager

[Tom Isaacson]

Nothing. But Visual Studio says the QNetworkReply pointer is set to 0xfeeefeee 
so someone's freeing it.

On segunda-feira, 29 de janeiro de 2018 20:06:37 PST Tom Isaacson wrote:
> Ah thanks! Now I just have to figure out why calling deleteLater() is 
> causing a crash...

What does valgrind say?
--
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] Lifetime of QNetworkReply from QNetworkAccessManager

[Thiago Macieira]

On segunda-feira, 29 de janeiro de 2018 20:06:37 PST Tom Isaacson wrote:
> Ah thanks! Now I just have to figure out why calling deleteLater() is
> causing a crash...

What does valgrind say?
-- 
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] Nice blog posts about cross-compiling Qt apps from windows to linux & mac

[Nikos Chantziaras]

On 29/01/18 19:56, David M. Cotter wrote:

You can just use this:

  http://mxe.cc


hmm

this appears to allow you to develop on MacOS X

are you saying that this lets you cross-compille to Windows?

ie: build on MacOS the actual windows binary?


Yes. That's exactly what it does.



but i don’t expect it can debug windows (remotely) from the mac. :(


Haven't tried it. But it might work. Google gives some hits on this. 
Example:


  http://mingw-cross.sourceforge.net/cross_debug.html

If you can run gdbserver on the VM, it might even be possible to debug 
it running in the VM. But again, I don't know and I didn't try.


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

Re: [Interest] Lifetime of QNetworkReply from QNetworkAccessManager

[Tom Isaacson]

Ah thanks! Now I just have to figure out why calling deleteLater() is causing a 
crash...

On 30/01/18, 4:48 PM, "Jason H"  wrote:


> Sent: Monday, January 29, 2018 at 10:44 PM
> From: "Tom Isaacson" 
> To: "Interest@qt-project.org" 
> Subject: [Interest] Lifetime of QNetworkReply from QNetworkAccessManager
>
> If I call a function like QNetworkAccessManager::head() with a 
QNetworkRequest I get a pointer to a QNetworkReply. But who's responsible for 
clearing up the QNetworkReply? Is it me, is it parented to the QNetworkReply, 
is it parented to the QNetworkAccessManager? If the latter, if the 
QNetworkAccessManager lasts for the lifetime of my application are all the 
QNetworkReply's going to take memory for the lifetime of the app?
> 
> I'd expect this to be covered in the documentation but I can't see 
anything:
> https://doc.qt.io/qt-5/qnetworkaccessmanager.html#head
> 

It's in there:
"Note: After the request has finished, it is the responsibility of the user 
to delete the QNetworkReply object at an appropriate time. Do not directly 
delete it inside the slot connected to finished(). You can use the 
deleteLater() function."



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

Re: [Interest] Lifetime of QNetworkReply from QNetworkAccessManager

[Jason H]

> Sent: Monday, January 29, 2018 at 10:44 PM
> From: "Tom Isaacson" 
> To: "Interest@qt-project.org" 
> Subject: [Interest] Lifetime of QNetworkReply from QNetworkAccessManager
>
> If I call a function like QNetworkAccessManager::head() with a 
> QNetworkRequest I get a pointer to a QNetworkReply. But who's responsible for 
> clearing up the QNetworkReply? Is it me, is it parented to the QNetworkReply, 
> is it parented to the QNetworkAccessManager? If the latter, if the 
> QNetworkAccessManager lasts for the lifetime of my application are all the 
> QNetworkReply's going to take memory for the lifetime of the app?
> 
> I'd expect this to be covered in the documentation but I can't see anything:
> https://doc.qt.io/qt-5/qnetworkaccessmanager.html#head
> 

It's in there:
"Note: After the request has finished, it is the responsibility of the user to 
delete the QNetworkReply object at an appropriate time. Do not directly delete 
it inside the slot connected to finished(). You can use the deleteLater() 
function."
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Lifetime of QNetworkReply from QNetworkAccessManager

[Tom Isaacson]

If I call a function like QNetworkAccessManager::head() with a QNetworkRequest 
I get a pointer to a QNetworkReply. But who's responsible for clearing up the 
QNetworkReply? Is it me, is it parented to the QNetworkReply, is it parented to 
the QNetworkAccessManager? If the latter, if the QNetworkAccessManager lasts 
for the lifetime of my application are all the QNetworkReply's going to take 
memory for the lifetime of the app?

I'd expect this to be covered in the documentation but I can't see anything:
https://doc.qt.io/qt-5/qnetworkaccessmanager.html#head

Thanks,

Tom Isaacson


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

Re: [Interest] QML Rotation sensor readings [images]

[Jason H]

https://developer.android.com/guide/topics/sensors/sensors_position.html
"Pitch (degrees of rotation about the x axis). This is the angle between a 
plane parallel to the device's screen and a plane parallel to the ground. If 
you hold the device parallel to the ground with the bottom edge closest to you 
and tilt the top edge of the device toward the ground, the pitch angle becomes 
positive. Tilting in the opposite direction— moving the top edge of the device 
away from the ground—causes the pitch angle to become negative. The range of 
values is -180 degrees to 180 degrees."

https://developer.apple.com/documentation/coremotion/getting_processed_device_motion_data/understanding_reference_frames_and_device_attitude
"Rotation values may be positive or negative and are in the range -∏ to ∏."

At's docs however:
http://doc.qt.io/qt-5/qrotationreading.html
"Right-handed rotation x [-90, 90]. Starting from the new (once-rotated) y-axis 
and incrementing towards the z-axis."

It seems that Qt's implementation does not possess the full range of reading 
that it should, since both mobile platforms support greater (and necessary 
values) beyond a quarter circle. 

> Sent: Monday, January 29, 2018 at 7:43 PM
> From: "Jason H" 
> To: "Jason H" 
> Cc: "interestqt-project.org" 
> Subject: Re: [Interest] QML Rotation sensor readings [images]
>
> I have continued to search on how to rectify this, does anyone have any 
> experience with the rotation sensor 2-readings issue?
> 
> 
> > Sent: Sunday, January 28, 2018 at 3:34 PM
> > From: "Jason H" 
> > To: "Jason H" 
> > Cc: "interestqt-project.org" 
> > Subject: Re: [Interest] QML Rotation sensor readings [images]
> >
> > http://doc.qt.io/qt-5/compatmap.html <- this needs updating because tit 
> > sensor works with Android (it seems) But it does not fix the problem.
> > 
> > Here are images describing the problem, and what I'd like.
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Nice blog posts about cross-compiling Qt apps from windows to linux & mac

[David M. Cotter]

> On Jan 29, 2018, at 5:15 PM, Christian Gagneraud  wrote:
> 
> On 30/01/2018 6:56 AM, David M. Cotter wrote:
>>> You can just use this:
>>> 
>>>  http://mxe.cc
>> hmm
>> this appears to allow you to develop on MacOS X
>> are you saying that this lets you cross-compille to Windows?
>> ie: build on MacOS the actual windows binary?
>> but i don’t expect it can debug windows (remotely) from the mac. :(
>> sigh.  I remember CodeWarrior, which WAS in fact “The Holy Grail”.
> 
> CodeWarrior UI was (is still?) pretty bad, not to say crappy... And is 
> targeting embedded devices AFAIR. I much prefer QtCreator for Qt/C++ dev.

what i remember is that i could compile for windows *on my mac*, have it launch 
the windows binary on a remote windows box (or VM), and i could debug it 
remotely, on my mac, using the codewarrior debugger.  it was heaven.

it could gracefully debug things like window activations too, since the 
debugger was remote (ie: the debugger UI didn’t interfere with debugging the 
target app UI)

the debugger (and IDE) UI was great for my purposes, it “just worked”, without 
all the issues that xcode has.  didn’t seem bad to me at least. i wasn’t doing 
embedded devices, so i don’t know about that.

*sigh*
the goold old days.  like MacOS 10.6.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Nice blog posts about cross-compiling Qt apps from windows to linux & mac

[Christian Gagneraud]

On 30/01/2018 6:56 AM, David M. Cotter wrote:

You can just use this:

  http://mxe.cc


hmm

this appears to allow you to develop on MacOS X

are you saying that this lets you cross-compille to Windows?

ie: build on MacOS the actual windows binary?

but i don’t expect it can debug windows (remotely) from the mac. :(
sigh.  I remember CodeWarrior, which WAS in fact “The Holy Grail”.


CodeWarrior UI was (is still?) pretty bad, not to say crappy... And is 
targeting embedded devices AFAIR. I much prefer QtCreator for Qt/C++ dev.


Chris



i could cross compile AND cross debug all from my mac.  it was heaven.
i wish such a beast existed still.
___
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] Nice blog posts about cross-compiling Qt apps from windows to linux & mac

[David M. Cotter]

> On Jan 29, 2018, at 4:36 PM, Konstantin Tokarev  wrote:
> 
> Wine allows running Windows binaries without having actual Windows.
> But it can have bugs sometimes.

that’s not what i mean.
i’m writing windows software, to run on windows.  (but i want to use my mac to 
do it, currently i use Parallels)

-dave


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

Re: [Interest] QML Rotation sensor readings [images]

[Jason H]

I have continued to search on how to rectify this, does anyone have any 
experience with the rotation sensor 2-readings issue?


> Sent: Sunday, January 28, 2018 at 3:34 PM
> From: "Jason H" 
> To: "Jason H" 
> Cc: "interestqt-project.org" 
> Subject: Re: [Interest] QML Rotation sensor readings [images]
>
> http://doc.qt.io/qt-5/compatmap.html <- this needs updating because tit 
> sensor works with Android (it seems) But it does not fix the problem.
> 
> Here are images describing the problem, and what I'd like.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to make a looping element?

[Jason H]

> Sent: Monday, January 29, 2018 at 5:53 PM
> From: "Sze Howe Koh" 
> To: "Jason H" 
> Cc: "interestqt-project.org" 
> Subject: Re: [Interest] How to make a looping element?
>
> On 30 January 2018 at 03:07, Jason H  wrote:
> >
> > This is more like a rotation.. I'm looking for the other kind of rotation 
> > where bearing % 360 can go from 359 to 1, without sweeping backwards while 
> > animating the sweep.  Rather than sweep, I'd prefer to seek
> > 090180270360
> >  -->--> increase
> > <-- sweep back (how can I avoid this?)
> 
> Two things come to mind:
> 
> 1. Use relative moves instead of absolute moves. E.g. instead of "359°
> to 1°", do "359° + 2°"
> 2. Support values <= 0° and >= 360°. E.g. instead of "359° to 1°", do
> "359° to 361°". After the animation is done, you can normalize "361°"
> -> "1°" (optional)

I got a somewhat usable result by checking the delta and if over 350, it 
disables the animation entirely and when it falls back below 120, it 
re-enables. This produces a little jumpiness a few degrees around 0, but is 
otherwise very good.

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

Re: [Interest] Nice blog posts about cross-compiling Qt apps from windows to linux & mac

[Konstantin Tokarev]

29.01.2018, 20:57, "David M. Cotter" :
>>  You can just use this:
>>
>>   http://mxe.cc
>
> hmm
>
> this appears to allow you to develop on MacOS X
>
> are you saying that this lets you cross-compille to Windows?
>
> ie: build on MacOS the actual windows binary?
>
> but i don’t expect it can debug windows (remotely) from the mac. :(
> sigh. I remember CodeWarrior, which WAS in fact “The Holy Grail”.
>
> i could cross compile AND cross debug all from my mac. it was heaven.
> i wish such a beast existed still.

Wine allows running Windows binaries without having actual Windows.
But it can have bugs sometimes.

> ___
> 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 make a looping element?

[Sze Howe Koh]

On 30 January 2018 at 03:07, Jason H  wrote:
>
> This is more like a rotation.. I'm looking for the other kind of rotation 
> where bearing % 360 can go from 359 to 1, without sweeping backwards while 
> animating the sweep.  Rather than sweep, I'd prefer to seek
> 090180270360
>  -->--> increase
> <-- sweep back (how can I avoid this?)

Two things come to mind:

1. Use relative moves instead of absolute moves. E.g. instead of "359°
to 1°", do "359° + 2°"
2. Support values <= 0° and >= 360°. E.g. instead of "359° to 1°", do
"359° to 361°". After the animation is done, you can normalize "361°"
-> "1°" (optional)


Regards,
Sze-Howe

> Sent: Monday, January 29, 2018 at 1:23 PM
> From: "Ola Røer Thorsen" 
> To: No recipient address
> Cc: "interestqt-project.org" 
> Subject: Re: [Interest] How to make a looping element?
> Try the RotationAnimation item and set the direction property to shortest.
> http://doc.qt.io/qt-5/qml-qtquick-rotationanimation.html
>
> Cheers,
> Ola
>
>
> Den 29. jan. 2018 kl. 02.15 skrev Jason H :
>
>
> I am trying to make a compass control, something that shows 0-360, like a 
> boat compass. It's got hash marks and numbers 350...0...10, etc. I have 
> something that largely works, but when the position crosses over 360 to 0, 
> the whole thing swings back around. It's very jerky, so I animate it, and 
> it's got that nice smoothness. I've tried to use complete() to make the 
> animation finish when it's a switch over, no luck.
>
> Does anyone have tips on how I can do this?
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] can the QRegExpEngine cache acces objects belonging to an unloaded library during global destruction?

[Thiago Macieira]

On segunda-feira, 29 de janeiro de 2018 12:53:21 PST René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > The plugins aren't unloaded when you call unload(), but they are unloaded
> > when the application exits. There's no way to avoid that.
> 
> I guess not, no, though I'm not sure if Qt has do do the unloading and
> releasing itself (as opposed to just telling the plugins to prepare for
> being unloaded). I don't think there are still OSes out there that will
> leave dangling plugins in memory after unloading the app that loaded them.

QLibrary actually unloads them specifically as part of the QtCore global 
destruction, except if you're using glibc on Linux:

#ifdef __GLIBC__
// glibc has a bug in unloading from global destructors
// see https://bugzilla.novell.com/show_bug.cgi?id=622977
// and http://sourceware.org/bugzilla/show_bug.cgi?id=11941
lib->unload(QLibraryPrivate::NoUnloadSys);
#else
lib->unload();
#endif

The thinking was that the danger of using pointers to static date of libraries 
and plugins already unloaded. After all, if QtCore is destroying itself, it's 
only QtCore code itself that is being run.

> What's the difference between unload() and release(), btw?

QLibrary doesn't have release(). Did you mean QLibraryPrivate?

> > Your crash happens after the QLibrary private global static has finished
> > running.
> 
> Which appears to be beyond my control. Or should I say, the only control I
> have over that is a brute-force means to keep that QLibrary private global
> static alive a bit longer (and as luck has it, until after the
> QRegExpEngine cache has been destroyed)?

This sounds like something a little patch in QtCore may solve.

> Apparently I'm not the first to run into this problem. Assuming that the
> QRegExpEngine cache is indeed an important optimisation, wouldn't it be
> possible to empty it much earlier during the global destruction phase, and
> lock it? That way at least there is no more risk that the order changes
> again and my workaround no longer works.
> 
> Rewriting the QRegExpEngine cache implementation so it can connect to
> QCoreApplication::aboutToQuit and drain+lock itself shouldn't be very hard
> and should be completely invisible from the outside, no?

But what is it doing during destruction that it needs to access the patterns?

Oh, I know: it's trying to deref the QString

I'm ok with emptying the cache on aboutToQuit.
-- 
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 QRegExpEngine cache acces objects belonging to an unloaded library during global destruction?

[René J . V . Bertin]

Thiago Macieira wrote:

> The plugins aren't unloaded when you call unload(), but they are unloaded when
> the application exits. There's no way to avoid that.

I guess not, no, though I'm not sure if Qt has do do the unloading and 
releasing 
itself (as opposed to just telling the plugins to prepare for being unloaded). 
I 
don't think there are still OSes out there that will leave dangling plugins in 
memory after unloading the app that loaded them.

What's the difference between unload() and release(), btw?

> Your crash happens after the QLibrary private global static has finished
> running.

Which appears to be beyond my control. Or should I say, the only control I have 
over that is a brute-force means to keep that QLibrary private global static 
alive a bit longer (and as luck has it, until after the QRegExpEngine cache has 
been destroyed)?

Apparently I'm not the first to run into this problem. Assuming that the 
QRegExpEngine cache is indeed an important optimisation, wouldn't it be 
possible 
to empty it much earlier during the global destruction phase, and lock it? That 
way at least there is no more risk that the order changes again and my 
workaround no longer works.

Rewriting the QRegExpEngine cache implementation so it can connect to 
QCoreApplication::aboutToQuit and drain+lock itself shouldn't be very hard and 
should be completely invisible from the outside, no?

R.

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

Re: [Interest] can the QRegExpEngine cache acces objects belonging to an unloaded library during global destruction?

[Thiago Macieira]

On segunda-feira, 29 de janeiro de 2018 10:49:21 PST René J. V. Bertin wrote:
> This is a platform theme plugin, it uses KF5 libraries but is not a KDE
> plugin. It gets loaded automatically by Qt, and apparently also unloaded
> automatically. If you set a breakpoint in ~QPlatformThemePlugin you'll
> probably see (like I) that you get there from
> QFactoryLoaderPrivate::~QFactoryLoaderPrivate().
> 
> On Linux (Mac will do the same, with the equivalent platform theme plugin):
[cut]

The plugins aren't unloaded when you call unload(), but they are unloaded when 
the application exits. There's no way to avoid that.

Your crash happens after the QLibrary private global static has finished 
running.

-- 
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 QRegExpEngine cache acces objects belonging to an unloaded library during global destruction?

[René J . V . Bertin]

> No need drop it, just use QLatin1String wherever plugins and QRegExp is 

That would have to be in KIO and/or its dependencies then, I don't use QRegExp 
in my platform theme plugin.

> involved, or check if not unloading kde plugins could be an option.

That's what my fix/workaround does, which is really rather kludgy because I 
don't load the plugin myself (and so cannot set the PreventUnloadHint but need 
to get an additional lock on the plugin to the pluginfactory won't auto-unload 
it).

Again, this is not a KDE plugin. It's a Qt plugin, based on one written by KDE 
and using KDE libraries, but it doesn't use any of KDE's plugin mechanisms. 

Or should I read this as "the plugins written and provided by Qt are not 
unloaded, anything you install onto the plugins path  will be unloaded. In that 
case: did I overlook a plugin Json property to indicate a plugin shouldn't be 
unloaded?

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

Re: [Interest] How to make a looping element?

[Jason H]

This is more like a rotation.. I'm looking for the other kind of rotation where bearing % 360 can go from 359 to 1, without sweeping backwards while animating the sweep.  Rather than sweep, I'd prefer to seek 

090180270360

 -->--> increase

<-- sweep back (how can I avoid this?)

 

Sent: Monday, January 29, 2018 at 1:23 PM
From: "Ola Røer Thorsen" 
To: No recipient address
Cc: "interestqt-project.org" 
Subject: Re: [Interest] How to make a looping element?



Try the RotationAnimation item and set the direction property to shortest.

http://doc.qt.io/qt-5/qml-qtquick-rotationanimation.html

 

Cheers, 

Ola


 

Den 29. jan. 2018 kl. 02.15 skrev Jason H :
 


I am trying to make a compass control, something that shows 0-360, like a boat compass. It's got hash marks and numbers 350...0...10, etc. I have something that largely works, but when the position crosses over 360 to 0, the whole thing swings back around. It's very jerky, so I animate it, and it's got that nice smoothness. I've tried to use complete() to make the animation finish when it's a switch over, no luck.

Does anyone have tips on how I can do this?
___
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] can the QRegExpEngine cache acces objects belonging to an unloaded library during global destruction?

[René J . V . Bertin]

Thiago Macieira wrote:

> Qt plugins aren't. KF5 may be doing something different.

This is a platform theme plugin, it uses KF5 libraries but is not a KDE plugin. 
It gets loaded automatically by Qt, and apparently also unloaded automatically. 
If you set a breakpoint in ~QPlatformThemePlugin you'll probably see (like I) 
that you get there from QFactoryLoaderPrivate::~QFactoryLoaderPrivate().

On Linux (Mac will do the same, with the equivalent platform theme plugin):

Breakpoint 1, 0x7fffe8ee9350 in 
QPlatformThemePlugin::~QPlatformThemePlugin()@plt ()
   from /opt/local/share/qt5/plugins/platformthemes/KDEPlasmaPlatformTheme.so
(gdb) bt
#0  0x7fffe8ee9350 in QPlatformThemePlugin::~QPlatformThemePlugin()@plt ()
   from /opt/local/share/qt5/plugins/platformthemes/KDEPlasmaPlatformTheme.so
#1  0x7fffe8efbe83 in __base_dtor  ()
at /opt/local/var/lnxports/build/_opt_local_site-ports_Linux_kf5_kf5-plasma-
integration/kf5-plasma-integration-devel/work/kf5-plasma-
integration-5/src/platformtheme/main.cpp:25
#2  __deleting_dtor  (this=0x7ba880)
at /opt/local/var/lnxports/build/_opt_local_site-ports_Linux_kf5_kf5-plasma-
integration/kf5-plasma-integration-devel/work/kf5-plasma-
integration-5/src/platformtheme/main.cpp:25
#3  0x768805d6 in QLibraryPrivate::unload (this=this@entry=0x67be30, 
flag=flag@entry=QLibraryPrivate::UnloadSys)
at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-
devel/qt5-kde-devel/work/qt-everywhere-opensource-
src-5.9.3/qtbase/src/corelib/plugin/qlibrary.cpp:562
#4  0x768716d2 in QFactoryLoaderPrivate::~QFactoryLoaderPrivate 
(this=0x796de0, __in_chrg=)
at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-
devel/qt5-kde-devel/work/qt-everywhere-opensource-
src-5.9.3/qtbase/src/corelib/plugin/qfactoryloader.cpp:86
#5  0x76871819 in QFactoryLoaderPrivate::~QFactoryLoaderPrivate 
(this=0x796de0, __in_chrg=)
at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-
devel/qt5-kde-devel/work/qt-everywhere-opensource-
src-5.9.3/qtbase/src/corelib/plugin/qfactoryloader.cpp:89
#6  0x768bfb83 in cleanup (pointer=)
at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-
devel/qt5-kde-devel/work/qt-everywhere-opensource-
src-5.9.3/qtbase/include/QtCore/../../src/corelib/tools/qscopedpointer.h:60
#7  ~QScopedPointer (this=0x77529278 
<_ZZN12_GLOBAL__N_112Q_QGS_loader13innerFunctionEvE6holder+8>, 
__in_chrg=)
at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-
devel/qt5-kde-devel/work/qt-everywhere-opensource-
src-5.9.3/qtbase/include/QtCore/../../src/corelib/tools/qscopedpointer.h:107
#8  QObject::~QObject (this=, __in_chrg=)
at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-
devel/qt5-kde-devel/work/qt-everywhere-opensource-
src-5.9.3/qtbase/src/corelib/kernel/qobject.cpp:881
#9  0x76e0bc19 in (anonymous namespace)::Q_QGS_loader::Holder::~Holder 
(this=, 
__in_chrg=)
at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-
devel/qt5-kde-devel/work/qt-everywhere-opensource-
src-5.9.3/qtbase/src/gui/kernel/qplatformthemefactory.cpp:51
#10 0x76e0bc19 in operator() (this=) from 
/opt/local/libexec/qt5/lib/libQt5Gui.so.5
#11 (anonymous namespace)::Q_QGS_loader::innerFunction()::Holder::~Holder ()
at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-
devel/qt5-kde-devel/work/qt-everywhere-opensource-
src-5.9.3/qtbase/src/gui/kernel/qplatformthemefactory.cpp:102
#12 0x75d351a9 in __run_exit_handlers (status=0, listp=0x760bb6c8 
<__exit_funcs>, 
run_list_atexit=run_list_atexit@entry=true) at exit.c:82
#13 0x75d351f5 in __GI_exit (status=) at exit.c:104
#14 0x75d1af4c in __libc_start_main (main=0x408030 , 
argc=1, argv=0x7fffdca8, 
init=, fini=, rtld_fini=, 
stack_end=0x7fffdc98)
at libc-start.c:321
#15 0x004097b5 in _start ()


R.


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

Re: [Interest] can the QRegExpEngine cache acces objects belonging to an unloaded library during global destruction?

[Martins , Sérgio]

On 2018-01-29 18:24, René J.V. Bertin wrote:

Hi,


Don't use QStringLiteral with QRegExp, specially in plugins you'll
unload.
See https://blogs.kde.org/2015/11/05/qregexp-qstringliteral-crash-exit


The backtrace there certainly looks familiar. The mentioned fix (in
5.6) was to stop unloading plugins, a principle that's clearly not
being applied here.


The Qt bugs were fixed in 5.6, not the user bugs.
Note that one can reproduce the problems by using const char *, without 
even using Qt. It's out of our hands to fix.



What bothers me here is that the explanation suggests that it doesn't
matter if you do `QRegExp(QStringLiteral("foo"))` or if there are 27
intermediate variables and function arguments between the QRegExp and
the QStringLiteral. I hope that's me misunderstanding because
otherwise we almost have to drop the NO_CAST_FROM_ASCII build option;
KIO use a *lot* of QRegExp instances I noticed, and the code is
evidently littered with QStringLiterals.


No need drop it, just use QLatin1String wherever plugins and QRegExp is 
involved, or check if not unloading kde plugins could be an option.




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] can the QRegExpEngine cache acces objects belonging to an unloaded library during global destruction?

[René J . V . Bertin]

Hi,

>Don't use QStringLiteral with QRegExp, specially in plugins you'll 
>unload.
>See https://blogs.kde.org/2015/11/05/qregexp-qstringliteral-crash-exit

The backtrace there certainly looks familiar. The mentioned fix (in 5.6) was to 
stop unloading plugins, a principle that's clearly not being applied here. I'm 
running Qt 5.9.3 here, and am *almost* certain I never saw the issue in 5.8.0 
(but have yet to compare the relevant qfactory*.cpp files).

What bothers me here is that the explanation suggests that it doesn't matter if 
you do `QRegExp(QStringLiteral("foo"))` or if there are 27 intermediate 
variables and function arguments between the QRegExp and the QStringLiteral. I 
hope that's me misunderstanding because otherwise we almost have to drop the 
NO_CAST_FROM_ASCII build option; KIO use a *lot* of QRegExp instances I 
noticed, and the code is evidently littered with QStringLiterals.

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

Re: [Interest] How to make a looping element?

[Ola Røer Thorsen]

Try the RotationAnimation item and set the direction property to shortest.
http://doc.qt.io/qt-5/qml-qtquick-rotationanimation.html

Cheers, 
Ola


> Den 29. jan. 2018 kl. 02.15 skrev Jason H :
> 
> I am trying to make a compass control, something that shows 0-360, like a 
> boat compass. It's got hash marks and numbers 350...0...10, etc. I have 
> something that largely works, but when the position crosses over 360 to 0, 
> the whole thing swings back around. It's very jerky, so I animate it, and 
> it's got that nice smoothness. I've tried to use complete() to make the 
> animation finish when it's a switch over, no luck.
> 
> Does anyone have tips on how I can do this?
> ___
> 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] Nice blog posts about cross-compiling Qt apps from windows to linux & mac

[David M. Cotter]

> You can just use this:
> 
>  http://mxe.cc

hmm

this appears to allow you to develop on MacOS X

are you saying that this lets you cross-compille to Windows?

ie: build on MacOS the actual windows binary?

but i don’t expect it can debug windows (remotely) from the mac. :(
sigh.  I remember CodeWarrior, which WAS in fact “The Holy Grail”.

i could cross compile AND cross debug all from my mac.  it was heaven.
i wish such a beast existed still.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] can the QRegExpEngine cache acces objects belonging to an unloaded library during global destruction?

[Martins , Sérgio]

On 2018-01-29 14:49, René J.V. Bertin wrote:

Hi,

I've already touched on this in a previous message. I'm seeing an
issue (crash or hang on exit) during the destruction of the
QRegExpEngine globalEngineCache.


Don't use QStringLiteral with QRegExp, specially in plugins you'll 
unload.

See https://blogs.kde.org/2015/11/05/qregexp-qstringliteral-crash-exit



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] QWebView vs. QWebEngine

[Jean-Michaël Celerier]

> At this page there is written next to Qt Web Engine (under LGPL only).
Therefore I concluded that the rest is GPL.

If I am not mistaken it means instead that the rest is LGPL + commercial,
which is Qt's "normal" license.

Best,
Jean-Michaël

On Mon, Jan 29, 2018 at 3:27 PM, Walter Stefan 
wrote:

> Thanks, because the web-page of Qt is confusing.
>
> At this page there is written next to Qt Web Engine (under LGPL only).
> Therefore I concluded that the rest is GPL.
>
> -Original Message-
> From: Konstantin Tokarev [mailto:annu...@yandex.ru]
> Sent: Montag, 29. Jänner 2018 18:20
> To: Walter Stefan ; interest@qt-project.org
> Subject: Re: [Interest] QWebView vs. QWebEngine
>
>
>
> 29.01.2018, 17:08, "Walter Stefan" :
> > Thanks for the quick response.
> >
> > Is there a web-link that supports this, or where can I seen the licenses
> to the Qt modules?
>
> https://webkit.org/licensing-webkit/
> http://code.qt.io/cgit/qt/qtwebkit.git/tree/LICENSE.LGPLv21
>
> >
> > Best Regards,
> > Stefan
> >
> > -Original Message-
> > From: Konstantin Tokarev [mailto:annu...@yandex.ru]
> > Sent: Montag, 29. Jänner 2018 18:05
> > To: Walter Stefan ; interest@qt-project.org
> > Subject: Re: [Interest] QWebView vs. QWebEngine
> >
> > 29.01.2018, 16:58, "Walter Stefan" :
> >>  Hi,
> >>
> >>  I’ve done some research about QWebView and QWebEngine and came to the
> following conclusion:
> >>
> >>  QWebView is under GPL and uses internally WebKit.
> >
> > Incorrect. QtWebKit code is LGPL+BSD.
> >
> >>  QWebEngine is under LGPL and uses internally Chromium.
> >>
> >>  Please let me know if this is correct, because I don’t want to
> disclose my source and that would mean I have to use QWebEngine.
> >>
> >>  Is there beside the license other limitations to be aware of?
> >>
> >>  Thanks and Regards,
> >>
> >>  Stefan
> >>  ,
> >>
> >>  ___
> >>  Interest mailing list
> >>  Interest@qt-project.org
> >>  http://lists.qt-project.org/mailman/listinfo/interest
> >
> > --
> > Regards,
> > Konstantin
>
> --
> Regards,
> Konstantin
>
> ___
> 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] can the QRegExpEngine cache acces objects belonging to an unloaded library during global destruction?

[René J . V . Bertin]

On Monday January 29 2018 17:53:44 Konstantin Tokarev wrote:

> > I'm not having much luck pinpointing what in or used by KFileWidget could 
> > possibly be the culprit here. Suggestions would be appreciated!
> 
> Port applications to QRegularExpression

Hah... I hadn't thought about that one. Good idea, that'll give me a purpose in 
life! :)

I did find a workaround, thanks to writing up a succinct outline for my 
previous message. The idea is simple: if KF5KIOWidgets is unloaded because no 
longer needed because the plugin is unloaded, prevent that unloading from 
happening.

https://github.com/RJVB/osx-integration/commit/215f32d20194503a8a3ff0ea4c7578ad45a310b8

@Thiago: I thought plugins were not being unloaded anymore on exit, since QT 
5.6 or so. Why does that not apply to platform theme plugins, or has the 
principle been reversed?

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

Re: [Interest] Nice blog posts about cross-compiling Qt apps from windows to linux & mac

[Jean-Michaël Celerier]

Not enough coffee today... the title should read: "from linux to windows
and mac" instead.

On Mon, Jan 29, 2018 at 4:10 PM, Jean-Michaël Celerier <
jeanmichael.celer...@gmail.com> wrote:

> https://hackernoon.com/a-c-hello-world-and-a-glass-of-
> wine-oh-my-263434c0b8ad
> https://hackernoon.com/a-c-hello-world-and-the-cute-
> heartless-rainbow-3cc9695f4142
> https://medium.com/@corentin.jabot/a-c-hello-world-and-the-
> rose-gold-walled-garden-of-doom-4ac3c92385ed
>
> If these can be useful... maybe one day we will be able to just hit
> "compile" from qtcreator and get an appimage, a NSIS installer and a .dmg
> in one go !
>
> Best,
> ---
> Jean-Michaël Celerier
> http://www.jcelerier.name
>
> ___
> 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] Nice blog posts about cross-compiling Qt apps from windows to linux & mac

[Jean-Michaël Celerier]

https://hackernoon.com/a-c-hello-world-and-a-glass-of-wine-oh-my-263434c0b8ad
https://hackernoon.com/a-c-hello-world-and-the-cute-heartless-rainbow-3cc9695f4142
https://medium.com/@corentin.jabot/a-c-hello-world-and-the-rose-gold-walled-garden-of-doom-4ac3c92385ed

If these can be useful... maybe one day we will be able to just hit
"compile" from qtcreator and get an appimage, a NSIS installer and a .dmg
in one go !

Best,
---
Jean-Michaël Celerier
http://www.jcelerier.name
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] can the QRegExpEngine cache acces objects belonging to an unloaded library during global destruction?

[Konstantin Tokarev]

29.01.2018, 17:49, "René J.V. Bertin" :
> Hi,
>
> I've already touched on this in a previous message. I'm seeing an issue 
> (crash or hang on exit) during the destruction of the QRegExpEngine 
> globalEngineCache.
>
> This happens on Mac when I have used a class (KFileWidget) via a platform 
> theme plugin; KFileWidget is provided by a library (KF5's KIOWidgets) which 
> is linked only to the platform plugin. Just creating a KFileWidget instance 
> (and deleting it at the appropriate location) is enough.
>
> - linking the application to KIOWidgets fixes the issue but isn't a desirable 
> solution (defeats the purpose of using a platform theme plugin to provide a 
> more capable and cross-platform file dialog).
> - inserting the KIOWidgets library via DYLD_INSERT_LIBRARY also fixes the 
> issue
>
> Interesting tidbits: in all these cases the KIOWidgets library is unloaded 
> before globalEngineCache is taken down.
> This surprises me in itself: I was under the impression that plugins are no 
> longer unloaded explicitly (so logically the libraries they use shouldn't be 
> either?)
>
> On Linux, the same principle is used by the plasma integration plugin, and 
> there the KIOWidgets library is unloaded AFTER the cache has been destroyed.
>
> I'm not having much luck pinpointing what in or used by KFileWidget could 
> possibly be the culprit here. Suggestions would be appreciated!

Port applications to QRegularExpression

>
> Thanks,
> R.
> ___
> 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

[Interest] can the QRegExpEngine cache acces objects belonging to an unloaded library during global destruction?

[René J . V . Bertin]

Hi,

I've already touched on this in a previous message. I'm seeing an issue (crash 
or hang on exit) during the destruction of the QRegExpEngine globalEngineCache. 

This happens on Mac when I have used a class (KFileWidget) via a platform theme 
plugin; KFileWidget is provided by a library (KF5's KIOWidgets) which is linked 
only to the platform plugin. Just creating a KFileWidget instance (and deleting 
it at the appropriate location) is enough. 

- linking the application to KIOWidgets fixes the issue but isn't a desirable 
solution (defeats the purpose of using a platform theme plugin to provide a 
more capable and cross-platform file dialog).
- inserting the KIOWidgets library via DYLD_INSERT_LIBRARY also fixes the issue

Interesting tidbits: in all these cases the KIOWidgets library is unloaded 
before globalEngineCache is taken down.
This surprises me in itself: I was under the impression that plugins are no 
longer unloaded explicitly (so logically the libraries they use shouldn't be 
either?)

On Linux, the same principle is used by the plasma integration plugin, and 
there the KIOWidgets library is unloaded AFTER the cache has been destroyed.

I'm not having much luck pinpointing what in or used by KFileWidget could 
possibly be the culprit here. Suggestions would be appreciated!

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

Re: [Interest] QWebView vs. QWebEngine

[Walter Stefan]

Thanks, because the web-page of Qt is confusing.

At this page there is written next to Qt Web Engine (under LGPL only). 
Therefore I concluded that the rest is GPL.

-Original Message-
From: Konstantin Tokarev [mailto:annu...@yandex.ru] 
Sent: Montag, 29. Jänner 2018 18:20
To: Walter Stefan ; interest@qt-project.org
Subject: Re: [Interest] QWebView vs. QWebEngine



29.01.2018, 17:08, "Walter Stefan" :
> Thanks for the quick response.
>
> Is there a web-link that supports this, or where can I seen the licenses to 
> the Qt modules?

https://webkit.org/licensing-webkit/
http://code.qt.io/cgit/qt/qtwebkit.git/tree/LICENSE.LGPLv21

>
> Best Regards,
> Stefan
>
> -Original Message-
> From: Konstantin Tokarev [mailto:annu...@yandex.ru]
> Sent: Montag, 29. Jänner 2018 18:05
> To: Walter Stefan ; interest@qt-project.org
> Subject: Re: [Interest] QWebView vs. QWebEngine
>
> 29.01.2018, 16:58, "Walter Stefan" :
>>  Hi,
>>
>>  I’ve done some research about QWebView and QWebEngine and came to the 
>> following conclusion:
>>
>>  QWebView is under GPL and uses internally WebKit.
>
> Incorrect. QtWebKit code is LGPL+BSD.
>
>>  QWebEngine is under LGPL and uses internally Chromium.
>>
>>  Please let me know if this is correct, because I don’t want to disclose my 
>> source and that would mean I have to use QWebEngine.
>>
>>  Is there beside the license other limitations to be aware of?
>>
>>  Thanks and Regards,
>>
>>  Stefan
>>  ,
>>
>>  ___
>>  Interest mailing list
>>  Interest@qt-project.org
>>  http://lists.qt-project.org/mailman/listinfo/interest
>
> --
> Regards,
> Konstantin

-- 
Regards,
Konstantin

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

Re: [Interest] QWebView vs. QWebEngine

[Konstantin Tokarev]

29.01.2018, 17:08, "Walter Stefan" :
> Thanks for the quick response.
>
> Is there a web-link that supports this, or where can I seen the licenses to 
> the Qt modules?

https://webkit.org/licensing-webkit/
http://code.qt.io/cgit/qt/qtwebkit.git/tree/LICENSE.LGPLv21

>
> Best Regards,
> Stefan
>
> -Original Message-
> From: Konstantin Tokarev [mailto:annu...@yandex.ru]
> Sent: Montag, 29. Jänner 2018 18:05
> To: Walter Stefan ; interest@qt-project.org
> Subject: Re: [Interest] QWebView vs. QWebEngine
>
> 29.01.2018, 16:58, "Walter Stefan" :
>>  Hi,
>>
>>  I’ve done some research about QWebView and QWebEngine and came to the 
>> following conclusion:
>>
>>  QWebView is under GPL and uses internally WebKit.
>
> Incorrect. QtWebKit code is LGPL+BSD.
>
>>  QWebEngine is under LGPL and uses internally Chromium.
>>
>>  Please let me know if this is correct, because I don’t want to disclose my 
>> source and that would mean I have to use QWebEngine.
>>
>>  Is there beside the license other limitations to be aware of?
>>
>>  Thanks and Regards,
>>
>>  Stefan
>>  ,
>>
>>  ___
>>  Interest mailing list
>>  Interest@qt-project.org
>>  http://lists.qt-project.org/mailman/listinfo/interest
>
> --
> Regards,
> Konstantin

-- 
Regards,
Konstantin

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

Re: [Interest] QWebView vs. QWebEngine

[Walter Stefan]

Thanks for the quick response.

Is there a web-link that supports this, or where can I seen the licenses to the 
Qt modules?

Best Regards,
Stefan

-Original Message-
From: Konstantin Tokarev [mailto:annu...@yandex.ru] 
Sent: Montag, 29. Jänner 2018 18:05
To: Walter Stefan ; interest@qt-project.org
Subject: Re: [Interest] QWebView vs. QWebEngine



29.01.2018, 16:58, "Walter Stefan" :
> Hi,
>
> I’ve done some research about QWebView and QWebEngine and came to the 
> following conclusion:
>
> QWebView is under GPL and uses internally WebKit.

Incorrect. QtWebKit code is LGPL+BSD.


>
> QWebEngine is under LGPL and uses internally Chromium.
>
> Please let me know if this is correct, because I don’t want to disclose my 
> source and that would mean I have to use QWebEngine.
>
> Is there beside the license other limitations to be aware of?
>
> Thanks and Regards,
>
> Stefan
> ,
>
> ___
> 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] all of QtBase depends on qregexp.cpp (or almost)?

[René J . V . Bertin]

Giuseppe D'Angelo wrote:

It does trigger a qmake rebuild, that's for sure.

> Check the contents of the Makefiles...
> HTH,

Maybe if I had a lot of time and those files were made for human consumption ;)

BTW, reason I touched the file is that under certain conditions I'm seeing 
crashes or hangs on exit when the QRegExpEngine cache is taken down. I was 
hoping to be able to check if there's an atexit order problem (which I surely 
must be causing myself). No such luck, but my issue does go away when I disable 
that cache.

Is there any recent data on how important that cache is, performance-wise? (And 
I mean just the cache, not the other optimisations.)

Thanks,
R.


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

Re: [Interest] all of QtBase depends on qregexp.cpp (or almost)?

[Giuseppe D'Angelo]

On 29/01/18 12:23, René J.V. Bertin wrote:
> Hi,
> 
> Here's an interesting question: why is it that making a small change to 
> qregexp.cpp triggers what seems to be a full rebuild of the entire QtBase 
> component, when it isn't being used as an include file (AFAICT)?

Probably it triggers rebuilding of qmake, which may trigger further
rebuilds down the line somehow. Check the contents of the Makefiles...

HTH,
-- 
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt, C++ and OpenGL Experts



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

Re: [Interest] MQTT Client Message Routing

[Maurice Kalinowski]

Hi Andrew,

The answer is as usually: It depends.

Generally most people use it in a way to keep the subscription (and its 
messages) close to where the application logic happens.
In your described scenario, it'd be appropriate to handle separate subscription 
objects for each client. That way you spare one level of filtering.

You could consider using the '#' wildcard though instead of the '+' for this 
setup, "app/users/$user/$client/#". Usually you use the + only for subitems, as 
in "get all conversations" app/users/+/$client/conversations.
Furthermore it helps when you introduce additional levels to the subscription. 
Using + you would not get any notification, while for # it continues to work.

Maurice


> -Original Message-
> From: Interest [mailto:interest-bounces+maurice.kalinowski=qt.io@qt-
> project.org] On Behalf Of Tony Rietwyk
> Sent: Monday, January 29, 2018 12:58 PM
> To: interest@qt-project.org
> Subject: Re: [Interest] MQTT Client Message Routing
> 
> Hi Andrew,
> 
> I haven't used QMqtt.  Nonetheless, I would suggest a hybrid - using a
> separate subscription object for each folder in the hierarchy.  So the client
> subscription only needs to match on the terminal symbol and coordinates all
> of the actions relating to clients.
> 
> Regards, Tony
> 
> 
> On 29/01/2018 10:21 PM, Andrew Ialacci wrote:
> 
> > Hello Qt Friends!
> >
> > When using the QMqtt library, I've noticed there are two possible ways to
> inspect messages received by the client from the broker.
> >
> > 1. QMqttClient::messageReceived(const QByteArray , const
> > QMqttTopicName ) 2. QMqttSubscription::messageReceived(const
> > QMqttMessage & message)
> >
> > I understand that the first will be a firehose of all messages being 
> > received
> by the client. The second is to only see messages having to do with a specific
> subscription.
> >
> > Consider the following scenario:
> >
> > // Example Topic Hierarchy
> > - app/users/$user/$client/friends
> > - app/users/$user/$client/conversations
> > - app/users/$user/$client/events
> >
> > // Questions:
> >
> > - Is it better to maintain individual QMqttSubscription objects for all
> possible topics a client is interested in and connect to each
> QMqttSubscription::messageReceived signal?
> >
> > - Or does it make more sense to have a single subscription to a root topic
> (where applicable, in this case: "app/users/$user/$client/+" ), a bunch of 
> IFs,
> and QMqttTopicFilter::match(const QMqttTopicName ) to handle
> each case?
> >
> > - It feels like maintaining a huge list of subscription objects will get
> annoying. However, is doing so worth it in terms of performance? Does it
> somehow reduce the overhead of matching strings all over (either internally
> in the QMqttClient or by my calling QMqttTopicFilter::match)?
> >
> > // Example of "switching" on topic in a
> > QMqttSubscription::messageReceived handler // using
> QMqttTopicFilter::match.
> > // Note:
> > //   Please ignore syntax / coding / technical errors.
> > //   This was written freehand purely to illustrate my point.
> >
> > void AppMessageRouter::handleMQTTMessageReceived(const
> QMqttMessage
> > ) {
> >  if
> (QMqttTopicFilter("app/users/$user/$client/friends").match(mqttMessage.t
> opic()) == true)
> >  {
> >  this->routeFriendsMessage(mqttMessage);
> >  return;
> >  }
> >
> >  if
> (QMqttTopicFilter("app/users/$user/$client/conversations").match(mqttMe
> ssage.topic()) == true)
> >  {
> >  this-> routeConversationsMessage(mqttMessage);
> >  return;
> >  }
> >
> >  if (QMqttTopicFilter("app/users/$user/$client/ events
> ").match(mqttMessage.topic()) == true)
> >  {
> >  this->routeEventMessage(mqttMessage);
> >  return;
> >  }
> > }
> >
> > Thanks for your time!
> > 
> >
> >
> >
> >
> >
> > ___
> > 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] MQTT Client Message Routing

[Tony Rietwyk]

Hi Andrew,

I haven't used QMqtt.  Nonetheless, I would suggest a hybrid - using a 
separate subscription object for each folder in the hierarchy.  So the 
client subscription only needs to match on the terminal symbol and 
coordinates all of the actions relating to clients.


Regards, Tony


On 29/01/2018 10:21 PM, Andrew Ialacci wrote:


Hello Qt Friends!

When using the QMqtt library, I've noticed there are two possible ways to 
inspect messages received by the client from the broker.

1. QMqttClient::messageReceived(const QByteArray , const QMqttTopicName 
)
2. QMqttSubscription::messageReceived(const QMqttMessage & message)

I understand that the first will be a firehose of all messages being received 
by the client. The second is to only see messages having to do with a specific 
subscription.

Consider the following scenario:

// Example Topic Hierarchy
- app/users/$user/$client/friends
- app/users/$user/$client/conversations
- app/users/$user/$client/events

// Questions:

- Is it better to maintain individual QMqttSubscription objects for all 
possible topics a client is interested in and connect to each 
QMqttSubscription::messageReceived signal?

- Or does it make more sense to have a single subscription to a root topic (where applicable, 
in this case: "app/users/$user/$client/+" ), a bunch of IFs, and 
QMqttTopicFilter::match(const QMqttTopicName ) to handle each case?

- It feels like maintaining a huge list of subscription objects will get 
annoying. However, is doing so worth it in terms of performance? Does it 
somehow reduce the overhead of matching strings all over (either internally in 
the QMqttClient or by my calling QMqttTopicFilter::match)?

// Example of "switching" on topic in a QMqttSubscription::messageReceived 
handler
// using QMqttTopicFilter::match.
// Note:
//   Please ignore syntax / coding / technical errors.
//   This was written freehand purely to illustrate my point.

void AppMessageRouter::handleMQTTMessageReceived(const QMqttMessage 
)
{
 if 
(QMqttTopicFilter("app/users/$user/$client/friends").match(mqttMessage.topic()) 
== true)
 {
 this->routeFriendsMessage(mqttMessage);
 return;
 }

 if 
(QMqttTopicFilter("app/users/$user/$client/conversations").match(mqttMessage.topic())
 == true)
 {
 this-> routeConversationsMessage(mqttMessage);
 return;
 }

 if (QMqttTopicFilter("app/users/$user/$client/ events 
").match(mqttMessage.topic()) == true)
 {
 this->routeEventMessage(mqttMessage);
 return;
 }
}

Thanks for your time!






___
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] all of QtBase depends on qregexp.cpp (or almost)?

[René J . V . Bertin]

Hi,

Here's an interesting question: why is it that making a small change to 
qregexp.cpp triggers what seems to be a full rebuild of the entire QtBase 
component, when it isn't being used as an include file (AFAICT)?

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