On Sun, Jul 12, 2020 at 06:02:00PM -0700, Donald Carr wrote:
> [...]
> It is sad to see people miss the necessity for hardware accelerated UI
> that QML addresses Qt widgets backing onto QPainter was extremely
> problematic to accelerate and the Qt company addressed this with
> scenegraph/QML.
It
On Monday, 13 July 2020 07:44:24 PDT Roland Hughes wrote:
> When QML was first pitched back in the Nokia days, it was supposed to be
> a script that ran through a pre-compiler generating the C++ widget code.
No, it wasn't.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect
On Monday, 13 July 2020 05:30:50 PDT Roland Hughes wrote:
> Let us not forget that QML+JavaScript is completely insecure in the
> OpenSource world. All of that JavaScript gets stuffed into the binary
> you ship as free text. Anyone with a decent text editor can read/extract
> your super secret prop
On 7/13/20 10:10 AM, interest-requ...@qt-project.org wrote:
Il 13/07/20 14:30, Roland Hughes ha scritto:
Let us not forget that QML+JavaScript is completely insecure in the
OpenSource world. All of that JavaScript gets stuffed into the binary
you ship as free text. Anyone with a decent text edi
You should certainly use the QueueConnection. I assume you are familiar
with https://www.kdab.com/qt-android-episode-7/ ?
I always decouple them by sending a signal and connecting a slot (which
implies a queuedConnection). This is most likely equivalent to
QMetaObject::invokeMethod() with „Queued
Yes, JniHandler::stateChanged is called from Java.
I tried many ways:
* QMetaObject::invokeMethod() with „AutoConnection“
* QMetaObject::invokeMethod() with „QueuedConnection“
* QTimer::singleShot()
What will be different by using „emit pInstance ->signalName()“ ?
Regards
Fabrice
Von: Marc Van
The JniHandler::stateChanged is called from Android/Java (or Kotlin) I
guess?
Can you try to emit a signal in JniHandler::stateChanged and call the
updateList in the connected slot?
Marc
On Mon, 13 Jul 2020 at 16:15, Fabrice Mousset | GEOCEPT GmbH <
fabrice.mous...@geocept.com> wrote:
> Thanks
On 7/13/20 9:10 AM, Jérôme Godbout wrote:
Hi,
If you write your algo into Javascript or you can edit it, you are so doing Qml
wrong! leave your algo into C++ please, your model/controler too shall be be
C++. Qml is for the GUI layer only, it so simple it is temping to add more
logic into it,
Thanks for your reply!
The thread ID is the same, all messages are from the same process (Activity and
Service are on different processes).
I forgot to say that I have already tried QMutex to lock the access, but that
is not useful here because if I set it up as "NonRecursive", it will dead lock
Hi,
If you write your algo into Javascript or you can edit it, you are so doing Qml
wrong! leave your algo into C++ please, your model/controler too shall be be
C++. Qml is for the GUI layer only, it so simple it is temping to add more
logic into it, but that's an error that will bit you in the
Il 13/07/20 14:30, Roland Hughes ha scritto:
Let us not forget that QML+JavaScript is completely insecure in the
OpenSource world. All of that JavaScript gets stuffed into the binary
you ship as free text. Anyone with a decent text editor can read/extract
your super secret proprietary algorithms.
On 7/13/20 5:00 AM, interest-requ...@qt-project.org wrote:
I also didn't complain about stability, but coming from fundamental research I can
relate to the feeling that API breakage of the type Qt3 -> Qt4 -> Qt5 (and who
knows what Qt6 has in stock) happens too fast, too soon.
Kittens swatti
On 7/12/20 9:54 PM, Konstantin Tokarev wrote:
11.07.2020, 13:26, "Roland Hughes" :
On 7/10/20 11:24 AM, Konstantin Tokarev wrote:
10.07.2020, 15:00, "Roland Hughes" :
They have a "slightly" newer version of WebKit.
"CsWebKit is a web content rendering engine based on the open source
It is sad to see constant after the fact "justification" for the
existence of QML. Plain and simple, it is a completely insecure hand
polished turd and no amount of rah-rah after the fact can change that.
On 7/12/20 8:02 PM, Donald Carr wrote:
@rene: I would recommend reading:
https://woboq.c
Can you also print the thread-pointer/id next to the name?
Maybe (just guessing) one QtMainLoopThread is from the main app and the
other one is from the service?
You could add a QMutexLocker (https://doc.qt.io/qt-5/qmutexlocker.html) to
ensure that the calls are executed sequentially.
Kind Regards
On Sunday July 12 2020 18:02:00 Donald Carr wrote:
>@rene: I would recommend reading:
Remember, I didn't know about CopperSpice until a few days ago. Does it
interest me as an alternative, sure, but not as anything more than that.
Also please remember that my post was about QtWebKit.
>to contex
Hi all,
First, I tried to send this mail to Android mailing list, but got an error
message as reply, so I try here. Sorry if I am wrong
I have a random issue with one of my Android service I've build with Qt 5.12.9.
I have centralized JNI interface in one C++ class, which is a singleton.
My serv
17 matches
Mail list logo
