Re: [Interest] The Mobile Agenda?

[René Hansen]

Great points Jason. I'm definitely interested in this as well.


/René

On Sat, 4 Jan 2020 at 21:49, Jason H  wrote:

> So it looks like the QtWS 2019 videos are up on YouTube.
> https://www.youtube.com/watch?v=YmwAeS_ojPA "Qt 6 will bring massive
> improvements to QML and 3D development"
>
> At time 53:40 Lars is asked a question about mobile, and answers "We will
> continue to support them. Was that the answer you were looking for?
> (giggles)" - Actually, no it is not.
> At 57:00 Lars takes another question about mobile, and responds with a
> hesitant "Um, yes..." and continues" We have a lot of ideas... want to make
> sure Qt is working nicely on mobile.. things have been moving quickly...
> have to catch up there".
> Actually the QA segment ended up being bookended by Mobile questions.
>
> Well I'm glad to hear Lars admit that there is catching up to do, but I
> take issue with the claim that things have been moving quickly. The
> majority of mobile features that I and others are requesting are not
> bleeding edge, it is basic things, like
> * NFC on iOS (Available iOS 11, September 19, 2017, 2+y)
> * Media keys (volume, play/pause, etc., Since before Qt 5.2)
> * Push Notifications (Since before Qt 5.2)
> * Display control (Since before Qt 5.2)
> * Battery Info (Since before Qt 5.2)
> * Vibration/haptics control (Since before Qt 5.2)
> * DeviceInfo (model, OS version, hardware enumeration, etc)
> * Biometric authentication
> * Datatype conversion (Java and ObjC to Qt types and back)
>
> Many of these are not that hard, the code is known and settled, I've
> posted code where I think it helps, but the issue is for every app I make,
> I have the friction of adding 8 of my own classes to every project... which
> is composed of bout 8 files, and the tome doctoring manifests and plists).
> The expense of these classes is over, but these classes that took me days
> to create and test in environments where I am not expert. I hack at native
> Objective C and Android, and those experiences are troubling. I don't mind
> for some really weird feature, but what is being asked for by me and the
> community is pretty basic stuff. Objective-C code examples are becoming
> rarer as Swift takes over.  The experience of using Eclipse or XCode is
> another problem itself, as the Qt integration is less than ideal. (Even
> ignoring having to use 2 IDEs to code.)
>
> Mobile (in general) really hasn't advanced in any way that Qt needs to
> react to, there's a lot of new biometrics stuff, but really we only need a
> way to integrate for authentication. (Fingerprint, FaceID, etc) Also the
> only thing I know Android has changed lately is the permission requests,
> but Qt already has a helper for that.
>
> A lot of these needs are tracked at:
> https://bugreports.qt.io/browse/QTBUG-74049 which was opened 11 months
> ago, but there has not been *any* activity, at least visibly.
>
> However I have had several mobile support issues serviced and closed, but
> I also have a commercial support agreement.
>
> If you are interested in my current code (that I recently refactored to be
> more granular than a monolithic catch-all shim that I had before) I can see
> about getting it shared to Qt, at least as inspiration (I don't use D-ptrs
> and am not subject to binary compatibility constraints). I think the most
> complicated bit on anyone's list is the Push Notifications, as the two
> platforms have different message structures.
>
> So my question to Lars is:
> Lars, can we get a better (in terms of: better stated, more attention,
> schedule clarity) commitment to mobile in 2020? I think with not a lot of
> effort we could get everything of what we are asking for, and then we can
> get out of your hair.
>
>
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QML and sensitive data

[René Hansen]

So here's a crazy idea.

You could decide to circumvent the whole thing, by drawing your own input
widget on top of an opengl texture, and inject that into the QML
scenegraph. I'm not entirely sure how you would sidestep input handling,
but at least that way you could potentially sidestep everything in JS-land,
and keep everything in protected memory.

I think you'd be in for a world of hurt, since you have to manage all the
native interfacing yourself, but at least it's doable in theory.


/René




On Thu, 5 Sep 2019 at 09:38, Alexander Ivash  wrote:

> Crashes are already happening which means obviously I'm doing
> something wrong. But what options do I have? Do I have it at all?
>
> чт, 5 сент. 2019 г. в 09:37, Elvis Stansvik :
> >
> > Den tors 5 sep. 2019 01:22Alexander Ivash  skrev:
> >>
> >> Thank you for fast response, but my question is purely about QML. On
> >> C++ side I have a lot of ways for nullifying / erasing sensitive
> >> information *after* it is not needed (let say after particular QML
> >> screen gets' closed). But on QML / JS side I have no any control at
> >> all. Would be great if one of QML guys could step in and comment too.
> >>
> >> Here is the small example illustrating my issue (all I need is to make
> >> 'Piter Pen' to disappear from memory dumps):
> >>
> >> 
> >>
> >> import QtQuick 2.12
> >> import QtQuick.Window 2.12
> >>
> >> Window {
> >> visible: true
> >> width: 640
> >> height: 480
> >> title: qsTr("Hello World")
> >>
> >> Component.onCompleted: {
> >> var test = "Piter Pen";
> >>
> >> // uncommenting results in a crash
> >> // backend.cleanup(test);
> >>
> >> // doesnt' nullify "Piter Pen"
> >> // gc();
> >>
> >> // doesn't work either
> >> /*
> >> Qt.callLater(() => {
> >>   gc();
> >>  })
> >>  */
> >> }
> >> }
> >>
> >> 
> >>
> >> #include 
> >> #include 
> >> #include 
> >> #include 
> >> #include 
> >> #include 
> >> #include 
> >> #include 
> >>
> >> class Backend : public QObject
> >> {
> >> Q_OBJECT
> >> public:
> >> explicit Backend(QObject *parent = nullptr) {
> >> QString str1 = "Piter Pen";
> >> QString str2 = str1;
> >> QString str3 = str2;
> >>
> >> qDebug() << "str1:" << str1;
> >> qDebug() << "str2:" << str2;
> >> qDebug() << "str3:" << str3;
> >>
> >> cleanup(str1);
> >>
> >> qDebug() << "str1:" << str1;
> >> qDebug() << "str2:" << str2;
> >> qDebug() << "str3:" << str3;
> >> }
> >>
> >> Q_INVOKABLE void cleanup(const QString& str) {
> >> std::mt19937
> >> eng(std::chrono::system_clock::now().time_since_epoch().count());
> >> std::uniform_int_distribution distribution;
> >>
> >> QChar* data = const_cast (str.constData());
> >>
> >> for(int i = 0; i < str.length(); ++i) {
> >> data[i] = distribution(eng);
> >> }
> >
> >
> > Just a word of caution: Even if you had not gotten a crash, like Thiago
> said you need to be very careful here: A smart compiler could possibly
> decide that since the memory pointed to by data is not used after this, it
> can optimize this entire loop of yours away.
> >
> > Not saying that's going to happen, but you need to be very careful. I
> think there are platform specific memory-zeroing functions that could be
> used that are written with that in mind. At least I know OpenBSD has
> something like that.
> >
> >> }
> >> };
> >>
> >> int main(int argc, char *argv[])
> >> {
> >> QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
> >>
> >> QGuiApplication app(argc, argv);
> >>
> >> Backend backend;
> >> QQmlApplicationEngine engine;
> >> const QUrl url(QStringLiteral("qrc:/main.qml"));
> >> QObject::connect(, ::objectCreated,
> >>  , [url](QObject *obj, const QUrl ) {
> >> if (!obj && url == objUrl)
> >> QCoreApplication::exit(-1);
> >> }, Qt::QueuedConnection);
> >> engine.rootContext()->setContextProperty("backend", );
> >> engine.load(url);
> >>
> >> return app.exec();
> >> }
> >>
> >> #include "main.moc"
> >>
> >> чт, 5 сент. 2019 г. в 01:32, Thiago Macieira  >:
> >> >
> >> > On Wednesday, 4 September 2019 14:46:09 PDT Alexander Ivash wrote:
> >> > > Is there any mechanism for cleanup sensitive data like passwords etc
> >> > > from QML? This issue is that gc() doesn't seem to even nullify
> memory
> >> > > (at least in release on Windows) so all the sensitive information
> >> > > stays in memory.
> >> >
> >> > Write in C++ and manage your memory VERY carefully. Remember that
> memset()
> >> > before free / delete or going out of scope is removed by the compiler.
> >> >
> >> > Don't use new or malloc. Instead, mmap() your chunk of memory
> yourself and
> >> > mlock() it properly.
> >> >
> >> > Of course, to display such information you need 

Re: [Interest] Android: include and use the translation files of Qt (qt_*.qm)

[René Hansen]

"You can use CONFIG += lrelease to automatically compile the files during
the build, and CONFIG += lrelease embed_translations to make them available
in The Qt Resource System."

Alternatively, you can just add the .qm files to a resource file yourself,
e.g. in the case where you want a different qrc path. I do the same, having
them at /translations/*.qm.

In-app you load them like so:

  QLocale defaultLocale;
  QTranslator app_translator;
  if (app_translator.load(defaultLocale, "your-app-name", "_",
":/translations"))
app.installTranslator(_translator);
  else
qDebug() << "Failed to load app translations, default 'en' will be
used.";

/René

On Mon, 19 Aug 2019 at 09:49, Alexander Dyagilev 
wrote:

> Filed the bug...
> https://bugreports.qt.io/browse/QTBUG-77661
>
> On 8/19/2019 10:35 AM, Alexander Dyagilev wrote:
> > Hmm This QT_INSTALL_TRANSLATIONS is empty under Android config.
> >
> > However, it's defined for Windows/Mac/Desktop Linux Any help?
> >
> > On 8/19/2019 5:41 AM, Alexander Dyagilev wrote:
> >> Something like this?
> >>
> >> qt_qm_files.path = /assets/translations
> >> qt_qm_files.files += $$QT_INSTALL_TRANSLATIONS/qt_*.qm
> >> INSTALLS += qt_qm_files
> >>
> >> On 8/19/2019 5:39 AM, Alexander Dyagilev wrote:
> >>> Looks like I should use qmake's INSTALLS variable and install all
> >>> the required qt_*.qm files into assets folder?
> >>>
> >>> On 8/19/2019 5:36 AM, Alexander Dyagilev wrote:
>  Hello,
> 
>  Is there a "good" way to achieve this?
> 
>  The only solution for know I'm thinking of is to manually copy all
>  them into my project folder and include into resource files.
> 
>  This is not good because I'll have to store them in my repository
>  and I'll have to update them every time I update Qt.
> 
>  What I want instead is to be able to tell qmake/androiddeployqt
>  tools to add all these files automatically from Qt installation
>  folder into my APK.
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>


-- 
Never fear, Linux is here.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] qt 5.13.0 SSL requirements

[René Hansen]

Ah, my mistake, I misunderstood.

According to this comment, on Windows, PATH is traversed when looking for
shared libs: https://stackoverflow.com/a/7148123/57290

Might be worth checking out.


/René



On Mon, 29 Jul 2019 at 19:59, maitai  wrote:

> Thanks René,
>
> I may be wrong but these variables look like build variables in case you
> want to build Qt.
>
> I am looking for a runtime variable to indicate where the libs are, and I
> hope to be able to set it from inside main with qputenv, otherwise it's
> back to 5.12.3
>
> Philippe.
>
>
>
> Le 29-07-2019 19:42, René Hansen a écrit :
>
> This archived 5.11 page might be what you're looking for:
>
> https://doc.qt.io/archives/qt-5.11/ssl.html
>
> I don't know if pkg-config is available to Windows users, but in case it
> is, this would do as well:
>
>   QT_CONFIG -= no-pkg-config
>   CONFIG += link_pkgconfig
>   PKGCONFIG += /path/to/openssl/lib/pkgconfig/openssl.pc \
> /path/to/openssl/lib/pkgconfig/libssl.pc
>
>
> /René
>
>
>
> On Mon, 29 Jul 2019 at 19:15, David M. Cotter  wrote:
>
>> seconded
>>
>> On Jul 29, 2019, at 9:33 AM, maitai  wrote:
>>
>> Hi all,
>>
>> I have some Windows 10/64 bits users reporting "TLS initialization
>> failed" when running our app, built with Qt 5.13.0 MSVC 2017/64 bits
>>
>> I have found this page:
>>
>> https://doc.qt.io/qt-5/windows-requirements.html
>>
>> But the interesting part is missing, i.e. what variable should I set to
>> indicate where opensll libs are ?
>>
>> Thanks
>> Philippe.
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> https://lists.qt-project.org/listinfo/interest
>>
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> https://lists.qt-project.org/listinfo/interest
>
>
>
> --
> Never fear, Linux is here.
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>


-- 
Never fear, Linux is here.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] qt 5.13.0 SSL requirements

[René Hansen]

This archived 5.11 page might be what you're looking for:

https://doc.qt.io/archives/qt-5.11/ssl.html

I don't know if pkg-config is available to Windows users, but in case it
is, this would do as well:

  QT_CONFIG -= no-pkg-config
  CONFIG += link_pkgconfig
  PKGCONFIG += /path/to/openssl/lib/pkgconfig/openssl.pc \
/path/to/openssl/lib/pkgconfig/libssl.pc


/René



On Mon, 29 Jul 2019 at 19:15, David M. Cotter  wrote:

> seconded
>
> On Jul 29, 2019, at 9:33 AM, maitai  wrote:
>
> Hi all,
>
> I have some Windows 10/64 bits users reporting "TLS initialization failed"
> when running our app, built with Qt 5.13.0 MSVC 2017/64 bits
>
> I have found this page:
>
> https://doc.qt.io/qt-5/windows-requirements.html
>
> But the interesting part is missing, i.e. what variable should I set to
> indicate where opensll libs are ?
>
> Thanks
> Philippe.
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>


-- 
Never fear, Linux is here.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Checking for refunds - QtPurchasing

[René Hansen]

A bit of further testing on this has offered a few more conclusions.

I was wrong in assuming network connectivity was needed. Turning on Flight
Mode and calling restorePurchases() still yields a callback of
onPurchaseRestored(), so the billing api must cache this information
locally on the phone somewhere.

One caveat though. The callback to onPurchaseRestored() only triggers once
per Store {} element during the lifetime of the application. I guess that
means, if you'd like to have a check on startup, invalidating a purchase in
the case where onPurchaseRestored() is not called, as well as having a
restore button somewhere on a buy page, that triggers the same, you'd need
two different instances of Store {}, with the same product, in order to
accomplish that.

I know refund abuse is commonplace, so would have hoped for a
better solution. It seems backwards and very brittle this way.


/René



On Wed, 24 Jul 2019 at 15:18, René Hansen  wrote:

> Ok, so I'm supposed to call restorePurchases() and then check whether
> "onPurchaseRestored" was *not* called for a specific Product? And in that
> case assume it was not purchased and/or refunded?
>
> That's going to be very error prone I think, because then I guess I'll
> have to do all the usual timeout checking, network connectivity assertion
> etc. etc.
>
> If only Store had something like:
>
>
> https://developers.google.com/android-publisher/api-ref/purchases/voidedpurchases/list
>
>
> /René
>
> On Wed, 24 Jul 2019 at 14:12, Maurice Kalinowski 
> wrote:
>
>> Hi,
>>
>>
>>
>> It’s been a while I had a look at Qt Purchasing, but generally
>> https://doc.qt.io/qt-5/qinappstore.html#restorePurchases was talking to
>> the store (at least Microsoft Store) to re-verify active purchases.
>>
>> If something has been refunded and/or revoked, then those should not be
>> listed anymore. But generally, restorePurchases does not only check
>> locally, but refers to what the store currently states.
>>
>>
>>
>> BR,
>>
>> Maurice
>>
>>
>>
>>
>>
>> *From:* Interest  *On Behalf Of *René
>> Hansen
>> *Sent:* Wednesday, July 24, 2019 2:04 PM
>> *To:* interest 
>> *Subject:* [Interest] Checking for refunds - QtPurchasing
>>
>>
>>
>> Hi all,
>>
>>
>>
>>
>>
>> I'm not sure this is solvable via QtPurchasing currently, but if anyone
>> has solved it, I'd love to hear about your approach.
>>
>>
>>
>> Normally a purchase flow goes something like this:
>>
>>
>>
>> 1. Purchase happens.
>>
>> 2. Transaction information is returned.
>>
>> 3. If transaction was approved, some value is stored locally in the
>> settings or otherwise persistent storage, indicating this item was bought.
>>
>> 4. Subsequent launches checks for the above set value, in order to
>> determine if user previously bought said item.
>>
>>
>>
>> Here's what I haven't figured out how to solve. What if this additional
>> step occurs:
>>
>>
>>
>> 5. User is issued a refund.
>>
>>
>>
>> Is there any way using QtPurchasing to "re-check" the status of a
>> transaction, in order to deactivate any features or similar, which was
>> unlocked by a purchase?
>>
>>
>>
>>
>>
>> /René
>>
>
>
> --
> Never fear, Linux is here.
>


-- 
Never fear, Linux is here.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Checking for refunds - QtPurchasing

[René Hansen]

Ok, so I'm supposed to call restorePurchases() and then check whether
"onPurchaseRestored" was *not* called for a specific Product? And in that
case assume it was not purchased and/or refunded?

That's going to be very error prone I think, because then I guess I'll have
to do all the usual timeout checking, network connectivity assertion etc.
etc.

If only Store had something like:

https://developers.google.com/android-publisher/api-ref/purchases/voidedpurchases/list


/René

On Wed, 24 Jul 2019 at 14:12, Maurice Kalinowski 
wrote:

> Hi,
>
>
>
> It’s been a while I had a look at Qt Purchasing, but generally
> https://doc.qt.io/qt-5/qinappstore.html#restorePurchases was talking to
> the store (at least Microsoft Store) to re-verify active purchases.
>
> If something has been refunded and/or revoked, then those should not be
> listed anymore. But generally, restorePurchases does not only check
> locally, but refers to what the store currently states.
>
>
>
> BR,
>
> Maurice
>
>
>
>
>
> *From:* Interest  *On Behalf Of *René
> Hansen
> *Sent:* Wednesday, July 24, 2019 2:04 PM
> *To:* interest 
> *Subject:* [Interest] Checking for refunds - QtPurchasing
>
>
>
> Hi all,
>
>
>
>
>
> I'm not sure this is solvable via QtPurchasing currently, but if anyone
> has solved it, I'd love to hear about your approach.
>
>
>
> Normally a purchase flow goes something like this:
>
>
>
> 1. Purchase happens.
>
> 2. Transaction information is returned.
>
> 3. If transaction was approved, some value is stored locally in the
> settings or otherwise persistent storage, indicating this item was bought.
>
> 4. Subsequent launches checks for the above set value, in order to
> determine if user previously bought said item.
>
>
>
> Here's what I haven't figured out how to solve. What if this additional
> step occurs:
>
>
>
> 5. User is issued a refund.
>
>
>
> Is there any way using QtPurchasing to "re-check" the status of a
> transaction, in order to deactivate any features or similar, which was
> unlocked by a purchase?
>
>
>
>
>
> /René
>


-- 
Never fear, Linux is here.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Checking for refunds - QtPurchasing

[René Hansen]

Hi all,


I'm not sure this is solvable via QtPurchasing currently, but if anyone has
solved it, I'd love to hear about your approach.

Normally a purchase flow goes something like this:

1. Purchase happens.
2. Transaction information is returned.
3. If transaction was approved, some value is stored locally in the
settings or otherwise persistent storage, indicating this item was bought.
4. Subsequent launches checks for the above set value, in order to
determine if user previously bought said item.

Here's what I haven't figured out how to solve. What if this additional
step occurs:

5. User is issued a refund.

Is there any way using QtPurchasing to "re-check" the status of a
transaction, in order to deactivate any features or similar, which was
unlocked by a purchase?


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

Re: [Interest] Android app bundles

[René Hansen]

Relevant issue, currently marked for 5.14:

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

On Thu, 11 Jul 2019 at 22:40, Jérôme Godbout  wrote:

> It seem like flutter is using the following project into there procedure
> if it might help:
>
> https://github.com/google/bundletool
>
>
>
>
>
> *From:* Interest  *On Behalf Of *René
> Hansen
> *Sent:* July 11, 2019 4:17 PM
> *To:* interest 
> *Subject:* [Interest] Android app bundles
>
>
>
> I know this was touched upon in the previous arm64 thread, but that
> settled on the solution juggling multiple APKs, with superseding version
> codes.
>
>
>
> Does anyone here know what roadmap looks like for app bundles, or if it's
> even in works for Qt at all?
>
>
>
> /René
>
>
>
> P.S. Was curious if Flutter had gotten there yet, so went to check and it
> seems they're already support it:
> https://flutter.dev/docs/deployment/android#building-the-app-for-release
>


-- 
Never fear, Linux is here.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Android app bundles

[René Hansen]

I know this was touched upon in the previous arm64 thread, but that settled
on the solution juggling multiple APKs, with superseding version codes.

Does anyone here know what roadmap looks like for app bundles, or if it's
even in works for Qt at all?

/René

P.S. Was curious if Flutter had gotten there yet, so went to check and it
seems they're already support it:
https://flutter.dev/docs/deployment/android#building-the-app-for-release
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] qt creator 4.9.1 + qt 5.11.3 = android debugger not working

[René Hansen]

Might be related:

https://bugreports.qt.io/browse/QTCREATORBUG-20403

On Tue, 2 Jul 2019 at 21:51, Alexander Dyagilev  wrote:

> Yes. I never build release versions on my machine.
>
>
> On 7/2/2019 10:40 PM, Konstantin Tokarev wrote:
> >
> > 02.07.2019, 22:31, "Alexander Dyagilev" :
> >> Hello,
> >>
> >> I've just noticed that debugger is not stopping on the breakpoints. It
> >> seems like it's not working at all.
> >>
> >> Is this a known problem? Do I have to upgrade to Qt 5.12 and clang for
> >> Android?
> > Are you sure that you are using debug build?
> >
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>


-- 
Never fear, Linux is here.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Android-development] [Qt-creator] Android will require 64bit soon

[René Hansen]

I'm about to migrate to 64bit myself and coincidentally I just pushed a
build config for OpenSSL 1.1.1c to my own build system -
https://github.com/rhardih/bad. (N.B. Docker
 is a pre-requisite.)

There's a rudimentary Qt based autotest included if you'd like to test it
on a device -
https://github.com/rhardih/bad/tree/master/tests/openssl/openssl-1-1-1c

In short this is steps to get a working *.so* file:

$ git clone https://github.com/rhardih/bad.git
$ cd bad
$ make openssl-arm64-v8a/1.1.1c
$ eval "$(.bad/bin/bad init -)"
$ bad extract openssl/1.1.1c-arm64-v8a

You should have the following files on your host afterwards:

$ tree extracted/openssl-1.1.1c-arm64-v8a-build/lib
extracted/openssl-1.1.1c-arm64-v8a-build/lib
├── engines-1.1
│   ├── capi.so
│   └── padlock.so
├── libcrypto.a
├── libcrypto.so -> libcrypto.so.1.1
├── libcrypto.so.1.1
├── libssl.a
├── libssl.so -> libssl.so.1.1
├── libssl.so.1.1
└── pkgconfig
├── libcrypto.pc
├── libssl.pc
└── openssl.pc


Cheers,

René


On Tue, 28 May 2019 at 09:50, ekke  wrote:

> Am 28.05.19 um 09:37 schrieb Guenter Schwann:
> > On Samstag, 2. Februar 2019 16:30:55 CEST ekke wrote:
> >> Am 02.02.19 um 04:29 schrieb Aleksey Kontsevich:
> >>> 01.02.2019, 12:11, "ekke" :
>  Also I think I must then also compile OpenSSL for 32 bit and 64 bit
> and
>  then need to know HowTo include into .pro>
> >>> That could help You to do this:
> >>> https://github.com/akontsevich/openssl-android-build
> >> Thx Aleksey,
> >>
> >> your github project looks great. Later this month I'll add 64 bit
> >> support to my Qt Android projects and will try to use your project to
> >> build OpenSSL for Android 32 + 64 Bit.
> > Have you been able to use SSL with 64 Bit Android?
>
> ... had so much work on Qt mobile customer projects and august was so
> far away ;-)
>
> now in June I'll test 64 bit builds - if there are problems, perhaps
> switching to Qt 5.13 and OpenSSL 1.1 (haven't looked for 1.1 scripts to
> build yet BTW)
>
> ciao
>
> ekke
>
> > As it is broken for me https://bugreports.qt.io/browse/QTBUG-73474
> >
> > And there seem to be more Android 64 Bit issues :(
> > https://lists.qt-project.org/pipermail/android-development/2019-May/
> > 001092.html
> >
> > Günter
> >
> >
> >
> >
>
> ___
> Android-development mailing list
> android-developm...@qt-project.org
> https://lists.qt-project.org/listinfo/android-development
>


-- 
Never fear, Linux is here.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Problem with cv::Mat grayscale to QImage

[René Hansen]

You might need to set the bytesPerLine of the QImage to match the step of
cv::Mat. I seem to recall having a similar issue once, converting between a
four and three bytes per pixel formats, e.g. if the cv::Mat is in CV_8UC4.


/René

On Thu, 20 Jun 2019 at 23:05, Jason H  wrote:

> Simple code:
>
> cv::Mat left_image = cv::imread(filename, cv::IMREAD_COLOR );
> cv::cvtColor(mat, mat, cv::COLOR_BGR2GRAY);
> cv::imwrite("dummy_gray_cv.png", left_image); // ok
> QImage test((unsigned char*) left_image.data, left_image.cols,
> left_image.rows, QImage::Format_Grayscale8);
> test.save("dummy_gray_qt.png"); // skewed
>
>
> However the dummy_gray_qt.png image is not aligned correctly, it's skewed
> as if bytes are missing/being skipped.
>
> I have to convert it back to color to work:
> cv::Mat dst;
> cv::cvtColor(left_image, dst, cv::COLOR_GRAY2BGRA);
> QImage result = QImage((unsigned char*) dst.data, dst.cols, dst.rows,
> QImage::Format_RGB32);
> result.save("dummy_color_qt.png")
>
> Is there a way I can avoid needing cv::cvtColor(left_image, dst,
> cv::COLOR_GRAY2BGRA)?
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>


-- 
Never fear, Linux is here.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Track global mouse position in QML

[René Hansen]

Imagine this example:

import QtQuick 2.12
import QtQuick.Window 2.12
import QtQuick.Controls 2.5

Window {
  visible: true
  width: 640
  height: 480
  title: qsTr("Hello World")

  TextField {
anchors.centerIn: parent
width: 0.7 * parent.width
  }

  Rectangle {
width: 30
height: 30
anchors.left: parent.left
anchors.leftMargin: 20
anchors.top: parent.top
anchors.topMargin: 20
color: "blue"

visible: ma.mouseX < 100 && ma.mouseY < 100
  }

  MouseArea {
id: ma
anchors.fill: parent
hoverEnabled: true
  }
}

So here's the idea. I want the blue rectangle in the upper left corner, to
only appear given some condition based on the X, Y position of the mouse
within the window. Now overlaying the *MouseArea* enables me to *track* the
cursor position at all times. The catch is then, that the *TextField* is
now broken. You cannot click it to give it focus and the cursor doesn't
change when you hover over it, to indicate text input is available.

If I change the ordering and *underlay* the *MouseArea* instead, then the
*TextField* works, but now I loose X, Y tracking, as soon as I'm hovering
over the TextField. I've tried all of:

hoverEnabled: true
preventStealing: true
propagateComposedEvents: true
acceptedButtons: Qt.NoButton

As well as:

mouse.accepted = false;

But it doesn't seem to work as expected.

@Jerome, I think the singleton approach would work, but it feels like
reversing responsibilities, which would lead to some weird patterns down
the road.
@Jason, A dispatch is probably fine for clicks, since they're only run
sporadically. Hover I think is a different thing, and I'd rather keep the
logic triggered to a bare minimum, since it'll be running pretty much
constantly.


/René

On Thu, 21 Mar 2019 at 15:35 Jérôme Godbout  wrote:

> Not sure I get what you are trying to achieve, but having a mouse area
> where the coordinate are local you can map them to global or to an item. If
> the mouse area should not grab the mouse event, make sure to add those to
> your mouse area
>
>
>
> hoverEnabled: true
>
> preventStealing: true
>
> propagateComposedEvents: true
>
> acceptedButtons: Qt.NoButton
>
>
>
> Also do not accept the events if not processing it or the event will be
> stopped (do this for all event that can be accepted):
>
>
>
> onClicked:
>
> {
>
>mouse.accepted = false;
>
> }
>
>
>
> This should make your overlay mouse area nearly transparent. This way the
> mouseArea overlay known the “global position” and can act upon it and the
> actual behavior under it can process the click like normal.
>
>
>
> You can use a single mouse area that overlay the whole items tree
> (MouseArea into Root Item fill) and change the global coordinate into a Qml
> Singleton. Any part of the application could connect to the coordinate and
> check if the global to whatever item you need match and act according to it.
>
>
>
>
> [image: 36E56279]
>
> une compagnie
>
> RAPPROCHEZ LA DISTANCE
>
> *Jérôme Godbout*
> Développeur Logiciel Sénior /
> Senior Software Developer
>
> *p:* +1 (418) 800-1073 ext.:109
>
> amotus.ca <http://www.amotus-solutions.com/>
> statum-iot.com
>
> <https://www.facebook.com/LesSolutionsAmotus/>
> <https://www.linkedin.com/company/amotus-solutions/>
> <https://twitter.com/AmotusSolutions>
> <https://www.youtube.com/channel/UCoYpQgsmj1iJZyDjTQ3x8Ig>
>
>
>
>
>
> *From:* Interest  *On Behalf Of *Jason H
> *Sent:* March 21, 2019 10:11 AM
> *To:* "René Hansen" 
> *Cc:* interest 
> *Subject:* Re: [Interest] Track global mouse position in QML
>
>
>
> Please forgive me if I don't completely understand...
>
>
>
> Maybe you want an underlying mouse area, not an overlaynig one? I'd
> suggest you just move the MouseArea in the file.
>
> You can always use an overlaying one and translate the mouse events to the
> child, if there is one. This is what I do for a sample drawing app I have:
>
> In TouchTestRect.qml:
>
>
>
> function dispatchTouchEvent(x,y) {
>
> var c = childAt(x,y);
>
> var typename =  "" + c;
>
> var box;
>
> if (c && (typename.startsWith("QQuickRow") || 
> typename.startsWith("QQuickColumn"))) {
>
> var point = mapToItem(c, x, y);
>
> box = c.childAt(point.x, point.y);
>
> typename =  "" + box;
>
> } else if(typename.startsWith("TouchHitBox_QMLTYPE")) {
>
> 
>
> }
>
> ...
>
> }
>
>
>
> then:
>
> MouseArea {
>
> anchors.fill: parent
>
> onMouseXChanged: {
>
> touchTestRect.dispatchTouchEvent(mouseX, mou

Re: [Interest] Track global mouse position in QML

[René Hansen]

For now I'm doing this:

class MouseTrackableWindow : public QQuickWindow
{
  Q_OBJECT
public:
  void mouseMoveEvent(QMouseEvent *event) override {
QQuickWindow::mouseMoveEvent(event);
emit mouseMove(event->windowPos());
  }

signals:
  void mouseMove(QPointF mouse);
};

...

qmlRegisterType("foo.components", 1, 0,
"MouseTrackableWindow");

...

import QtQuick 2.12

import foo.components 1.0

MouseTrackableWindow {
  title: qsTr("Hello World")

  onMouseMove: {
console.log(mouse.x, mouse.y);
  }
}

And it's not all too bad, but if anyone can tell me of a more dogmatic
QtQuick based approach, please let me know.

I'm not sure missing whatever is left in QQuickWindowQmlImpl
<https://github.com/qt/qtdeclarative/blob/5.12/src/quick/items/qquickwindowmodule_p.h>
is
going to wind up giving me problems later. Subclassing that means including
private headers etc. so I'm not to keen on going that route.


/René

On Thu, 21 Mar 2019 at 12:50 René Hansen  wrote:

> Hi all,
>
>
> I want to track mouse movement within my entire application window,
> because I need to show/hide/move items around where my cursor is at certain
> times. (Think e.g. custom cursor)
>
> I can do it easily by filling the entire window with a *MouseArea* and
> handle *onPositionChanged*. The problem is that any mouse sensitive
> inputs underneath, then get's blocked by the overlaying *MouseArea*. E.g.
> a *TextField* that is usually highlighted on hover and clickable, no
> longer receives any mouse events.
>
> Is there any straightforward solution to this?
>
> I know *QQuickWindow* has a *mouseMoveEvent*, but that doesn't seem to be
> exposed in QML and if I can avoid subclassing and exposing a custom class,
> I'd rather do that.
>
>
> Cheers,
>
> René Hansen
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Track global mouse position in QML

[René Hansen]

Hi all,


I want to track mouse movement within my entire application window, because
I need to show/hide/move items around where my cursor is at certain times.
(Think e.g. custom cursor)

I can do it easily by filling the entire window with a *MouseArea* and
handle *onPositionChanged*. The problem is that any mouse sensitive inputs
underneath, then get's blocked by the overlaying *MouseArea*. E.g. a
*TextField* that is usually highlighted on hover and clickable, no longer
receives any mouse events.

Is there any straightforward solution to this?

I know *QQuickWindow* has a *mouseMoveEvent*, but that doesn't seem to be
exposed in QML and if I can avoid subclassing and exposing a custom class,
I'd rather do that.


Cheers,

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

Re: [Interest] Fwd: vs. Flutter

[René Hansen]

On Fri, 22 Feb 2019, 13:47 Jean-Michaël Celerier, <
jeanmichael.celer...@gmail.com> wrote:

> Cisco did it with an app that uses gstreamer (which is under LGPL) :
> https://itunes.apple.com/ua/app/cisco-jabber/id467192391?mt=8.
> They send it on request, with the proprietary part in a static lib (see at
> the end here :
>
> https://github.com/GStreamer/gst-plugins-good/blob/master/README.static-linking
> )
>

That is really cool. They even included, scripts to build the app. I'm not
sure you have to go quite that far to be compliant, but awesome
nevertheless. Maybe someone can clarify this further. I.e. Are you
responsible for providing a, or instructions for creating a, working build
environment, in order to be LGPL compliant.


> Best,
> Jean-Michaël
>
> On Thu, Feb 21, 2019 at 6:07 PM Sylvain Pointeau <
> sylvain.point...@gmail.com> wrote:
>
>> Do you have one example of someone who put a LGPL app in the app store
>> and provided the binary object files?
>>
>> On Thu, Feb 21, 2019 at 3:58 PM Julius Bullinger <
>> julius.bullin...@gmail.com> wrote:
>>
>>> On 21.02.2019 15:44, Christian Gagneraud wrote:
>>> > Qt is free (on mobile), free as in liberty, as long as your
>>> > application is free, as in liberty.
>>> > That's basic (L)GPL rules.
>>> >
>>> > Now there's the business rules:
>>> > If you want your (mobile) app to be non-free (as in proprietary), then
>>> > you'll have to pay the Qt company for that. Disregarding the fact that
>>> > you want to make money or not.
>>>
>>> Please do not spread this misinformation! As long as you adhere to the
>>> terms of LGPL, you can create non-free, proprietary and closed apps with
>>> Qt (or any other LGPL library for that matter). You only need to make
>>> sure that the user can replace all LGPL parts with their own builds.
>>>
>>> The fact that the mobile OS's and app stores make it exceptionally hard
>>> to do that is not an issue with the license terms. If you find a way
>>> that enables the user to replace LGPL parts (for example by dynamic
>>> linking or by making all object files and linking instructions available
>>> on request), that's perfectly valid and legal.
>>>
>>> _That_ is a basic LGPL rule.
>>>
>>>
>>> https://tldrlegal.com/license/gnu-lesser-general-public-license-v2.1-(lgpl-2.1)
>>>
>>>
>>> https://tldrlegal.com/license/gnu-lesser-general-public-license-v3-(lgpl-3)
>>> ___
>>> Interest mailing list
>>> Interest@qt-project.org
>>> https://lists.qt-project.org/listinfo/interest
>>>
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> https://lists.qt-project.org/listinfo/interest
>>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Fwd: vs. Flutter

[René Hansen]

You're reversing the burden of proof here. Where have Qt stated that it is
non-free for mobile?

The licensing terms are the same no matter the platform; Qt is LGPL or
Commercial. It's up to you to adhere to whichever license you choose to
utilise.


/René


On Thu, 21 Feb 2019 at 14:50 Sylvain Pointeau 
wrote:

> On Tue, Feb 19, 2019 at 8:30 PM Sylvain Pointeau <
> sylvain.point...@gmail.com> wrote:
>
>> Qt is free on desktop, but it is not free on mobile, which is a real
>> showstopper for me and many others.
>>
>> Le mar. 19 févr. 2019 à 20:12, ich  a écrit :
>>
>>> Qt is free, too.
>>>
>>
> I received few personal emails to ask me why am I writing that Qt is not
> free on mobile.
>
> I am sorry but this is the message from the Qt company, please show me one
> official statement that Qt is free to use on mobile.
> I would be really glad and finally use Qt instead of looking for
> alternatives.
>
> Best regards,
> Sylvain
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] vs. Flutter

[René Hansen]

On Tue, 19 Feb 2019 at 06:58 Shawn Rutledge  wrote:

> On Feb 18, 2019, at 17:18, René Hansen  wrote:
>
> On Mon, 18 Feb 2019 at 16:27 Shawn Rutledge  wrote:
>
>>
>> > On 18 Feb 2019, at 15:40, René Hansen  wrote:
>>
>
>> > Achitecturally it's similar to Qt, in that they've build a custom
>> renderer on top of Skia, so the whole scene is basically just OpenGL, which
>> makes it really fast.
>> >
>> > Component wise, their UI library offers bother Cupertino and Material
>> design out of the box, and from initial impressions, looks to be closer to
>> the original design guidelines than Qt Quick Controls for. e.g. Material.
>>
>> In what way?
>>
>
> This might just be my own personal experience, but I've run into weird and
> "finicky" behaviours with Qt Quick Controls, quite a number of times and so
> far, from the admittedly smaller sample size, I've not seen the same issues
> with widgets in Flutter.
>
>
> That still sounds vague.  I hope you will write up bugs with concrete
> examples of what’s weird.
>


I've kind of given up reporting bugs, unless they're really big. Again,
this is just my personal experience, but I've long felt that minor bug
reports are just left to rot in the tracker, so why even bother. Here's one
I did report though; about TextInput:
https://bugreports.qt.io/browse/QTBUG-69625. That's an example of what I
mean by weird.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] vs. Flutter

[René Hansen]

On Mon, 18 Feb 2019 at 16:27 Shawn Rutledge  wrote:

>
> > On 18 Feb 2019, at 15:40, René Hansen  wrote:
> >
> > I've not come across any myself, and have only built a few small things
> with it a bit for now.
> >
> > Initial reactions was that it is *leagues* ahead of Qt with regards to
> developer experience. You're not locked to an IDE, like with QtCreator,
>
> Strictly speaking you’re not locked into using QtCreator either: I've done
> command-line builds of Android apps once in a while.  You can watch what
> Creator does and do the same yourself.  But it’s not as straightforward as
> it could be, and the script I made to automate it needs to change since
> earlier Qt versions.  Something like
>
> qmake
> make install INSTALL_ROOT=.
> androiddeployqt --input something.so-deployment-settings.json --output
> /path/to/android-build --android-platform android-27 --jdk
> /usr/lib/jvm/default --gradle
>
> I wish we would make it a universal one-liner without having to find paths
> to things first.  Perhaps someone could figure out how to do that with
> cmake eventually.
>


Would definitely be nice, to have a single tool outside of QtCreator to
help out for people who just like their own setup. Equate this with
flutters simplicity of just `flutter run` optionally with a -d param, in
case you've connected more than one device/emulator etc. Flutter has also
copied homebrews `doctor` subcommand, to help you out, in case something
isn't quite right. This combination of ease of setup, paired with live
preview just killer.



>
> > and the ui live updates across device, simulators, emulators etc. when
> you write changes. No need to build and .apk and wait for a build+deploy.
>
> I wonder how well-understood that mechanism is, so that someone could even
> try to get that working with Qt?  If it should not be part of the IDE, it
> would have to be some daemon that watches the filesystem, recompiles and
> re-deploys classes, right?  But at this point it’s up to someone to
> volunteer to figure that out I suppose.
>


I'm not entirely sure how they do it, but from what I can tell they've got
two separate modes of hot reload, one which reloads the entire
application/world, and one where only the part you changed is updated.

It might be something which is possible because of how Dart and the Dart VM
itself is structured, but I'm just guessing here. As I undestand it, an
entire flutter app is one big tree-like structure of widget nodes,
russian-dolled into one another, so I would imagine something there allows
for a recompile of a subtree, and basic node replacement.



>
> > There's no JS involved. It's Dart all the way. It doesn't even ship with
> a web runtime afaik.
>
> In other words it’s another new language all the way, but the advantage is
> it gets compiled to native code.  But QML can be compiled, and anyway
> doesn’t depend on a web runtime.  I doubt you can say that Dart has no
> runtime at all?  If there is garbage collection, there’s a runtime; the
> question is which one, how big is it and what does it provide.
>


Yes, the Dart VM is of-course a runtime, but as far as I know it doesn't
get included in release builds, only in development, which allows for the
hot reload etc. I believe garbage collection and some other stuff from the
vm is the only thing included in release builds otherwise.



>
> An advantage when a phone or OS vendor decides to support a particular
> development framework is that they can ship parts of it pre-installed.  So
> the best phone for Qt applications is one that’s built with Qt in the first
> place; but the Big Two didn’t make that choice, so we can only hope that
> some not-so-small player will eventually do that (again).  I recently tried
> Ubuntu Touch (yeah, better late than never): it seems quite nice, it’s just
> missing a lot of apps.  There is Jolla.  And there is Plasma Mobile… and
> maybe the Librem 5 will end up with Qt in some way?  We’ll see.
>


It might be a good idea, but I'd hate having to wait on phone release
cycles/os updates, in order to get latest features/bugfixes for a Qt built
application. I don't know if any Android version even ships with native
Dart support either. Maybe Fuchsia will.



>
> > Achitecturally it's similar to Qt, in that they've build a custom
> renderer on top of Skia, so the whole scene is basically just OpenGL, which
> makes it really fast.
> >
> > Component wise, their UI library offers bother Cupertino and Material
> design out of the box, and from initial impressions, looks to be closer to
> the original design guidelines than Qt Quick Controls for. e.g. Material.
>
> In what way?
>


This might just be my own personal experience, but I've run into weird and
"finicky" behaviours with Qt Qui

Re: [Interest] vs. Flutter

[René Hansen]

I've not come across any myself, and have only built a few small things
with it a bit for now.

Initial reactions was that it is *leagues* ahead of Qt with regards to
developer experience. You're not locked to an IDE, like with QtCreator, and
the ui live updates across device, simulators, emulators etc. when you
write changes. No need to build and .apk and wait for a build+deploy.

There's no JS involved. It's Dart all the way. It doesn't even ship with a
web runtime afaik.

Achitecturally it's similar to Qt, in that they've build a custom renderer
on top of Skia, so the whole scene is basically just OpenGL, which makes it
really fast.

Component wise, their UI library offers bother Cupertino and Material
design out of the box, and from initial impressions, looks to be closer to
the original design guidelines than Qt Quick Controls for. e.g. Material.

I haven't tried it out myself yet, but you should be able to reach into
native world by using platform channels:

https://flutter.io/docs/development/platform-integration/platform-channels

It's seems like it's quite a ways worse than with Qt though, so there's at
least that.


/René

On Mon, 18 Feb 2019 at 14:58 Jason H  wrote:

> Are there any good Qt vs Google Flutter comparisons?
> I took a brief look, it looked like a declarative JS framework. Usually
> the difference with between Qt and the competition is Qt abstracts there
> platform libraries (i.e. Gstreamer vs avfoundation vs directshow)
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] What are you using for continuous integration?

[René Hansen]

Does anyone have any experience using Travis for for Qt projects?

I found this project, which seems to at least have a good general approach
to setting up a usable environment for Travis:

https://github.com/benlau/qtci

If anyone has tried using it, I'd love to hear about it.


/René

On Thu, 14 Feb 2019 at 10:22 Elvis Stansvik  wrote:

> Den tors 14 feb. 2019 kl 10:08 skrev Nuno Santos  >:
> >
> > Hey,
> >
> > Thank you all for sharing your solutions and approaches. Among here
> there are two obvious winners:
> >
> > - Jenkins
> > - Buildbot
> >
> > I want to keep the build config within the project so I guess Jenkins
> will be my way to go.
>
> For brevity, this is the side-project I mentioned to make Buildbot
> more like Travis in that respect:
> https://github.com/buildbot/buildbot_travis
>
> It's maintained (and I believe used) by the Buildbot maintainers
> themselves. I've looked at it, but we haven't tried to use it. One
> reason is that it works by dynamically adjusting the Buildbot config,
> and I was unsure how this would work if we still wanted to have parts
> of the Buildbot config that were custom/static (like I mentioned, we
> have some other automation tasks that we run on top of the same
> Buildbot master instance).
>
> Anyway, just thought I'd drop the link. Probably good idea to go with
> Jenkins if you want in-repo build recipies out of the box.
>
> Elvis
>
> >
> > Now I just need to go though all the configuration details. If anyone
> knows any really pragmatic documentation on how to setup Jenkins server
> with GitHub and how to setup a worker on Mac and Windows, please share.
> >
> > Thanks,
> >
> > Best regards,
> >
> > Nuno
> >
> > On 13 Feb 2019, at 19:02, Elvis Stansvik  wrote:
> >
> > Den ons 13 feb. 2019 kl 00:06 skrev Nuno Santos <
> nunosan...@imaginando.pt>:
> >
> >
> > Hi,
> >
> > I’m curious about what you Qt heads are using for continuous integration.
> >
> > I have googled a few times this for this topic and I have found a couple
> of options but every time I tried to spend the minimum amount of time to
> setup one, it seems an incredible effort. I’m looking for a solution that
> allows me to:
> >
> > - push to a specific branch on GitHub
> > - get a local CI agent to fetch that branch and build it
> >
> > Ideally I would like it to be :
> >
> > - fast to setup
> > - Windows & Mac compatible
> > - ideally with docker integration
> >
> > Drone works damn well for web projects. I wanted something that cool for
> automatic desktop software building and packaging
> >
> > What are you people using?
> >
> >
> > We use Buildbot. It has worked very well, and we use it for some other
> > automation tasks besides software builds. It builds and tests software
> > from our local GitLab instance. Builds are mostly done in Docker
> > containers, though for macOS and Windows we run the Buildbot workers
> > on bare metal.
> >
> > Downside is it's configured using Python and the configuration takes
> > some getting used to when setting it up for the first time (but it's
> > very well designed and worth learning). The upside is it's Python :)
> > so it's *very* flexible. Downside is also that the config is central
> > and not kept with the repos (though there is a project to support
> > Travis-style in-repo config).
> >
> > Elvis
> >
> >
> > Thanks!
> >
> > Best,
> >
> > Nuno
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > https://lists.qt-project.org/listinfo/interest
> >
> >
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > https://lists.qt-project.org/listinfo/interest
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Netiquette [was: Feature Request - QtCreator - Multiple right margins]

[René Hansen]

I'm with Jason here.

I use Qt for mobile development as well, and I don't think a ban is the
right course of action. Choice of words is a pre-eminent selector in
deciding which posts to take seriously. Using terms in the the manner
Roland does about phone development, in all likelihood, self-disqualifies
any serious consideration his posts might have received otherwise. Although
a shame, that is repercussion enough in my opinion.


/René

On Mon, 11 Feb 2019 at 15:07 Jason H  wrote:

> The truth is I often enjoy the hyperbole. In my book it's better to have a
> thick skin rather than to go around being offended by everyone and asking
> for them to comply with a fragile nature. However this most recent post put
> down the Qt mobile community of which I am a significant member having been
> using Qt in mobile for about the past 5 years. I have argued repeatedly for
> more attention in the Mobile platforms (except WinRT) and the message was
> directly contrary to that aim. I pointed out (off list) ironically what
> should happen is port the application to mobile and just let Samsung make
> and revise the hardware faster than he ever could. Didn't draw any ire but
> it didn't go anywhere either. I'm starting to wonder if the hyperbole isn't
> for comedic effect.
>
> My plan of action is that I'm just going to ignore this person's snarky
> posts which comes with the price that I might have the answer to their
> issue and I won't contribute it.
>
> I on occasion post something snarky because I am frustrated with the
> problem I'm having. I wouldn't want to be banned over it. There is a social
> capital here, add I try to have a positive balance. And I think it's
> reasonable that when you fall below zero, you stop getting replies. I would
> not bring in the CoC just yet.
>
> > Sent: Friday, February 08, 2019 at 8:18 PM
> > From: "Konstantin Shegunov" 
> > To: m...@herrdiel.de
> > Cc: "Interests Qt" 
> > Subject: Re: [Interest] Netiquette [was: Feature Request - QtCreator -
> Multiple right margins]
> >
> > >
> > > [...]
> > > I do appreciate the open discussion style on this list. I even do
> > > appreciate a somewhat harsh style, if it has a factual base and is
> > > getting straight to the point instead of b*s*ing around. But those
> > > lengthy wallpapers our President of Logikal solutions commonly utters,
> > > have long since crossed the border from amusing to annoying.
> > >
> >
> > I, myself, still perceive them more as amusingly misguided, than really
> > angering (annoying at times, yes). This is just me, though, I have
> > experience with that kind of thing. However, I can very well imagine how
> > you, and most certainly others, are finding them taxing; not surprising
> at
> > all.
> > Plus, as I rule, I tend to discard anything that references fortran or
> > cobol as examples of anything ... ;)
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > https://lists.qt-project.org/listinfo/interest
> >
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] (JNI ERROR) jbytearray -> java.lang.String[] - What am I doing wrong here?

[René Hansen]

I think I've found the problem. It seems wrapping the call to
*callStaticMethod* like this:

QtAndroid::runOnAndroidThread([jdata] {
  ...
});

Had the effect of changing something about the type of jdata. If I remove
it out, that makes call pass just fine. I'm not sure how to run on the
android ui thread then, but I guess that's a different problem then.


/René

On Sat, 26 Jan 2019 at 12:35 René Hansen  wrote:

> I don't know if there's a difference between *QAndroidJniEnvironment* and
> *QtAndroidExtras/QAndroidJniEnvironment*.
>
> I tried a few different things, also e.g. declaring:
>
> const jbyte foo[] = { 0x4c, 0x6f, 0x72 ,0x65, 0x6d };
>
> Directly to avoid the cast, but the same thing is happening. I still see:
>
> JNI ERROR (app bug): attempt to pass an instance of java.lang.String[] as
> argument 1 to int Foo.bar(byte[])
>
> So either *jbyteArray* is simply not the right type to pass to
> *callStaticMethod*, for a *byte[]* parameter type, or some magic
> conversion is happening in the Qt wrapper classes.
>
>
> /René
>
> On Sat, 26 Jan 2019 at 01:01 Jason H  wrote:
>
>> So I think i got that completely wrong.  I'm more used to using
>> androidextras. They have a nice API that cleans up for you. I gotta that's
>> not an option?  Maybe they JNI stuff should get it's own module separate
>> from Android?
>>
>> > Sent: Friday, January 25, 2019 at 9:00 PM
>> > From: "Jason H" 
>> > To: "René Hansen" 
>> > Cc: interest 
>> > Subject: Re: [Interest] (JNI ERROR) jbytearray -> java.lang.String[] -
>> What am I doing wrong here?
>> >
>> >
>> >
>> > I'm not familiar with that, jbteArray, but in attemping your challenge,
>> I saw:
>> >
>> > qjniEnv->SetByteArrayRegion(jdata, 0, _size, reinterpret_cast> *>(foo));
>> >
>> > but saw this in the docs:
>> > void SetArrayRegion(JNIEnv *env, ArrayType array, jsize
>> start, jsize len, NativeType *buf);
>> >
>> >
>> > is jdata your jni env?
>> >
>> > Sent: Friday, January 25, 2019 at 1:13 PM
>> > From: "René Hansen" 
>> > To: interest 
>> > Subject: [Interest] (JNI ERROR) jbytearray -> java.lang.String[] - What
>> am I doing wrong here?
>> >
>> > All I want to do is send some bytes from Qt to Java, but I'm running
>> into an annoying problem, where my jbyteArray gets turned
>> into java.lang.String[] in mid-flight:
>> >
>> >
>> > E art : JNI ERROR (app bug): attempt to pass an instance of
>> java.lang.String[] as argument 1 to int Foo.bar(byte[])
>> > F art : art/runtime/java_vm_ext.cc:410] JNI DETECTED ERROR IN
>> APPLICATION: bad arguments passed to int Foo.bar(byte[]) (see above for
>> details)
>> > F art : art/runtime/java_vm_ext.cc:410] from void
>> org.qtproject.qt5.android.QtNative.runPendingCppRunnables()
>> > F art : art/runtime/java_vm_ext.cc:410] "main" prio=5 tid=1 Runnable
>> > ...
>> >
>> > Here's a minimal example; just a simple auto test project:
>> >
>> > TestJNI.pro:
>> >
>> >
>> > QT += testlib androidextras
>> > QT -= gui
>> >
>> > CONFIG += qt console warn_on depend_includepath testcase
>> > CONFIG -= app_bundle
>> >
>> > TEMPLATE = app
>> >
>> > SOURCES +=  tst_test_jni.cpp
>> >
>> > ANDROID_PACKAGE_SOURCE_DIR = $$PWD
>> >
>> > DISTFILES += \
>> > src/Foo.java
>> >
>> > tst_test_jni.cpp:
>> >
>> > #include 
>> > #include 
>> > #include 
>> >
>> > class test_jni : public QObject
>> > {
>> > Q_OBJECT
>> >
>> > private slots:
>> > void test_case1();
>> > };
>> >
>> > void test_jni::test_case1()
>> > {
>> >   QAndroidJniEnvironment qjniEnv;
>> >   jsize _size = static_cast(5);
>> >   jbyteArray jdata = qjniEnv->NewByteArray(_size);
>> >   jint result;
>> >
>> >   if (jdata == nullptr)
>> > QFAIL("Failed creating new jbyteArray");
>> >
>> >   if (qjniEnv->GetArrayLength(jdata) != _size)
>> >   {
>> > qjniEnv->DeleteLocalRef(jdata);
>> > QFAIL("Failed to allocate entire array through JNI");
>> >   }
>> >
>> >   // Lorem
>> >   char foo[] = { 0x4c, 0x6f, 0x72 ,0x65, 0x6d };
>> >
>> >   qjniEnv->SetByteArray

Re: [Interest] (JNI ERROR) jbytearray -> java.lang.String[] - What am I doing wrong here?

[René Hansen]

I don't know if there's a difference between *QAndroidJniEnvironment* and
*QtAndroidExtras/QAndroidJniEnvironment*.

I tried a few different things, also e.g. declaring:

const jbyte foo[] = { 0x4c, 0x6f, 0x72 ,0x65, 0x6d };

Directly to avoid the cast, but the same thing is happening. I still see:

JNI ERROR (app bug): attempt to pass an instance of java.lang.String[] as
argument 1 to int Foo.bar(byte[])

So either *jbyteArray* is simply not the right type to pass to
*callStaticMethod*, for a *byte[]* parameter type, or some magic conversion
is happening in the Qt wrapper classes.


/René

On Sat, 26 Jan 2019 at 01:01 Jason H  wrote:

> So I think i got that completely wrong.  I'm more used to using
> androidextras. They have a nice API that cleans up for you. I gotta that's
> not an option?  Maybe they JNI stuff should get it's own module separate
> from Android?
>
> > Sent: Friday, January 25, 2019 at 9:00 PM
> > From: "Jason H" 
> > To: "René Hansen" 
> > Cc: interest 
> > Subject: Re: [Interest] (JNI ERROR) jbytearray -> java.lang.String[] -
> What am I doing wrong here?
> >
> >
> >
> > I'm not familiar with that, jbteArray, but in attemping your challenge,
> I saw:
> >
> > qjniEnv->SetByteArrayRegion(jdata, 0, _size, reinterpret_cast *>(foo));
> >
> > but saw this in the docs:
> > void SetArrayRegion(JNIEnv *env, ArrayType array, jsize
> start, jsize len, NativeType *buf);
> >
> >
> > is jdata your jni env?
> >
> > Sent: Friday, January 25, 2019 at 1:13 PM
> > From: "René Hansen" 
> > To: interest 
> > Subject: [Interest] (JNI ERROR) jbytearray -> java.lang.String[] - What
> am I doing wrong here?
> >
> > All I want to do is send some bytes from Qt to Java, but I'm running
> into an annoying problem, where my jbyteArray gets turned
> into java.lang.String[] in mid-flight:
> >
> >
> > E art : JNI ERROR (app bug): attempt to pass an instance of
> java.lang.String[] as argument 1 to int Foo.bar(byte[])
> > F art : art/runtime/java_vm_ext.cc:410] JNI DETECTED ERROR IN
> APPLICATION: bad arguments passed to int Foo.bar(byte[]) (see above for
> details)
> > F art : art/runtime/java_vm_ext.cc:410] from void
> org.qtproject.qt5.android.QtNative.runPendingCppRunnables()
> > F art : art/runtime/java_vm_ext.cc:410] "main" prio=5 tid=1 Runnable
> > ...
> >
> > Here's a minimal example; just a simple auto test project:
> >
> > TestJNI.pro:
> >
> >
> > QT += testlib androidextras
> > QT -= gui
> >
> > CONFIG += qt console warn_on depend_includepath testcase
> > CONFIG -= app_bundle
> >
> > TEMPLATE = app
> >
> > SOURCES +=  tst_test_jni.cpp
> >
> > ANDROID_PACKAGE_SOURCE_DIR = $$PWD
> >
> > DISTFILES += \
> > src/Foo.java
> >
> > tst_test_jni.cpp:
> >
> > #include 
> > #include 
> > #include 
> >
> > class test_jni : public QObject
> > {
> > Q_OBJECT
> >
> > private slots:
> > void test_case1();
> > };
> >
> > void test_jni::test_case1()
> > {
> >   QAndroidJniEnvironment qjniEnv;
> >   jsize _size = static_cast(5);
> >   jbyteArray jdata = qjniEnv->NewByteArray(_size);
> >   jint result;
> >
> >   if (jdata == nullptr)
> > QFAIL("Failed creating new jbyteArray");
> >
> >   if (qjniEnv->GetArrayLength(jdata) != _size)
> >   {
> > qjniEnv->DeleteLocalRef(jdata);
> > QFAIL("Failed to allocate entire array through JNI");
> >   }
> >
> >   // Lorem
> >   char foo[] = { 0x4c, 0x6f, 0x72 ,0x65, 0x6d };
> >
> >   qjniEnv->SetByteArrayRegion(jdata, 0, _size, reinterpret_cast *>(foo));
> >
> >   QtAndroid::runOnAndroidThread([jdata] {
> > QAndroidJniObject::callStaticMethod(
> >   "Foo",
> >   "bar",
> >   "([B)I",
> >   jdata);
> >   });
> >
> >   QCOMPARE(result, 42);
> > }
> >
> > QTEST_APPLESS_MAIN(test_jni)
> >
> > #include "tst_test_jni.moc"
> >
> > Foo.java:
> >
> > public class Foo {
> >   static int bar(byte baz[]) {
> >   return 42;
> >   }
> > }
> >
> > Have I missed something very basic here?
> >
> >
> > Best regards,
> >
> > René Hansen___ Interest
> mailing list Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest___
> Interest mailing list Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] (JNI ERROR) jbytearray -> java.lang.String[] - What am I doing wrong here?

[René Hansen]

All I want to do is send some bytes from Qt to Java, but I'm running
into an annoying problem, where my *jbyteArray* gets turned into
*java.lang.String[]* in mid-flight:

E art : JNI ERROR (app bug): attempt to pass an instance of
java.lang.String[] as argument 1 to int Foo.bar(byte[])
F art : art/runtime/java_vm_ext.cc:410] JNI DETECTED ERROR IN
APPLICATION: bad arguments passed to int Foo.bar(byte[]) (see above for
details)
F art : art/runtime/java_vm_ext.cc:410] from void
org.qtproject.qt5.android.QtNative.runPendingCppRunnables()
F art : art/runtime/java_vm_ext.cc:410] "main" prio=5 tid=1 Runnable
...

Here's a minimal example; just a simple auto test project:

*TestJNI.pro:*

QT += testlib androidextras
QT -= gui

CONFIG += qt console warn_on depend_includepath testcase
CONFIG -= app_bundle

TEMPLATE = app

SOURCES +=  tst_test_jni.cpp

ANDROID_PACKAGE_SOURCE_DIR = $$PWD

DISTFILES += \
src/Foo.java

*tst_test_jni.cpp:*

#include 
#include 
#include 

class test_jni : public QObject
{
Q_OBJECT

private slots:
void test_case1();
};

void test_jni::test_case1()
{
  QAndroidJniEnvironment qjniEnv;
  jsize _size = static_cast(5);
  jbyteArray jdata = qjniEnv->NewByteArray(_size);
  jint result;

  if (jdata == nullptr)
QFAIL("Failed creating new jbyteArray");

  if (qjniEnv->GetArrayLength(jdata) != _size)
  {
qjniEnv->DeleteLocalRef(jdata);
QFAIL("Failed to allocate entire array through JNI");
  }

  // Lorem
  char foo[] = { 0x4c, 0x6f, 0x72 ,0x65, 0x6d };

  qjniEnv->SetByteArrayRegion(jdata, 0, _size, reinterpret_cast(foo));

  QtAndroid::runOnAndroidThread([jdata] {
QAndroidJniObject::callStaticMethod(
  "Foo",
  "bar",
  "([B)I",
  jdata);
  });

  QCOMPARE(result, 42);
}

QTEST_APPLESS_MAIN(test_jni)

#include "tst_test_jni.moc"

*Foo.java:*

public class Foo {
  static int bar(byte baz[]) {
  return 42;
  }
}

Have I missed something very basic here?


Best regards,

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

Re: [Interest] Official builds configuration options

[René Hansen]

That's probably because g++ is a wolf in sheeps clothing in the later NDKs:

# /android-23-toolchain/bin/arm-linux-androideabi-g++  --version
Android (4751641 based on r328903) clang version 7.0.2 (
https://android.googlesource.com/toolchain/clang
003100370607242ddd5815e4a043907ea9004281) (
https://android.googlesource.com/toolchain/llvm
1d739ffb0366421d383e04ff80ec2ee591315116) (based on LLVM 7.0.2svn)
Target: armv7a-none-linux-android23
Thread model: posix

This is from r18b.

/René

On Thu, 24 Jan 2019 at 13:19 Filip Piechocki  wrote:

> That does not seem right as Qt 5.12.0 for Android is built with clang
> and those configure lines have:
> -xplatform android-g++
>
> BR,
> Filip Piechocki
>
> On Thu, Jan 24, 2019 at 11:11 AM Konstantin Podsvirov
>  wrote:
> >
> >
> >
> > 12:55, 24 January 2019 г., Filip Piechocki :
> >
> > Thanks, but cannot find that there :(
> >
> > Look there:
> >
> > http://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config
> >
> > configure_android_armv7_opensource:
> >
> > -opensource -confirm-license -release -xplatform android-g++ -opengl es2
> -android-arch armeabi-v7a -nomake tests -nomake examples -skip qtserialport
> -skip qtwebkit -skip qtwebkit-examples -skip qtx11extras -sysconfdir
> /etc/xdg -no-icu -openssl
> >
> >
> > configure_android_armv7_enterpris:
> >
> > -commercial -confirm-license -release -xplatform android-g++ -opengl es2
> -android-arch armeabi-v7a -nomake tests -nomake examples -skip qtserialport
> -skip qtwebkit -skip qtwebkit-examples -skip qtx11extras -sysconfdir
> /etc/xdg -no-icu -openssl
> >
> > BR,
> > Filip Piechocki
> >
> > On Thu, Jan 24, 2019 at 10:31 AM Konstantin Podsvirov
> >  wrote:
> >
> >  Hello Filip!
> >
> >  Try look there:
> >
> >  http://code.qt.io/cgit/qtsdk/qtsdk.git
> >
> >  12:20, 24 January 2019 г., Filip Piechocki :
> >
> >  Hi,
> >  Where can I find official builds (available from Qt Maintenance Tool)
> >  configure options? I am especially interested in Qt 5.12.0 for Android
> >  armv7 build.
> >
> >  Best regards,
> >  Filip Piechocki
> >  ___
> >  Interest mailing list
> >  Interest@qt-project.org
> >  https://lists.qt-project.org/listinfo/interest
> >
> >
> >  Regards,
> >  Konstantin Podsvirov
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Can't run simple Auto Test Project on arm64-v8a

[René Hansen]

Has anyone else run into this bug with arm64-v8a?

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

Regular application templates seems to run fine, but not unit tests.


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

Re: [Interest] Changes to Javascript runtime in 5.12

[René Hansen]

That's what I've resorted to for now, but yeah, as you say, it's definitely
not as nice. Luckily, this time, there wasn't too many libs that needed
rewriting.

I haven't specifically seen any documentation regarding "this" and the
global scope of JS libs, so I guess it might be my own fault for relying on
that behaviour. The closest is the points about *import* semantics from
http://doc.qt.io/qt-5/qtqml-javascript-imports.html, but afaict nothing
there seems to touch on the issue I'm seeing.


/René



On Thu, 3 Jan 2019 at 10:22 Ulf Hermann  wrote:

> Hi René,
>
> > In JS libs before 5.12, I've always used a closure approach to not
> > leak a bunch of private variables onto the global module object. This
> > results in a layout much like so:
>  >
> > (function(lib) {
> >   ... closed vars can be declared here ...
> >
> >   lib.bar = function() {
> > return "baz";
> >   };
> > })(this);
>
> You can still pass an empty object to your anonymous function and
> extract the interesting bits of that into the JS file's global scope
> afterwards. Or you can declare a number of vars outside the anonymous
> function and assign functions to them from inside. Both options are
> indeed a bit uglier, though.
>
> This looks like a regression in Qt 5.12, but I will need to take a
> closer look at it. Did we ever document anything about the semantics of
> the "this" object in JavaScript libraries?
>
> best regards,
> Ulf
>
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Changes to Javascript runtime in 5.12

[René Hansen]

Hi all,


In the progress of upgrading an app to 5.12, I'm seeing some unexpected
issues with external JS dependencies.

In JS libs before 5.12, I've always used a closure approach to not leak a
bunch of private variables onto the global module object. This results in a
layout much like so:

(function(lib) {
  ... closed vars can be declared here ...

  lib.bar = function() {
return "baz";
  };
})(this);

And then traditionally used it in QML e.g. like so:

import "foo.js" as Foo

Item {
  objectName: Foo.bar()
}

However, in 5.12 something has changed, so I can no longer assign stuff to "
*this*" in a JS library. Anything attached to the main scope comes up as
*undefined* now.

Can anyone point me in the direction of docs explaining this change, and
possibly what the preferred way of closing over variables in a JS library
is from now on?


Best regards,

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

Re: [Interest] Modern

[René Hansen]

Vlad, do you have a source saying QML was an inspiration for Flutter?

I've recently talked with someone on the Flutter team, that literally
didn't even know QtQuick existed. At first I was sort of surprised, but
then again not really. I've talked with a lot of app developers, where Qt
isn't even on their radar.


/René


On Thu, 20 Dec 2018, 16:03 Vlad Stelmahovsky, 
wrote:

> I suppose he is just trolling community for whatever reason
>
> and QML is sooo "outdated" that Google created Flutter, where QML was an
> inspiration, for my poi
>
> br,
>
> Vlad
>
> On 12/20/18 3:23 PM, Nuno Santos wrote:
> > Hey Roland,
> >
> > Sorry mate.. I couldn’t avoid...
> >
> > How are you writing UIs this days? What is modern to you?
> >
> > I consider myself young. I’m only 36. But I have been writing software
> for the last 20 years.
> >
> > In the last 6 years I have written 4 different apps ALONE! One of them
> was written 3 times. One in native iOS, then in native Android and then in
> Qt Qml.
> >
> > Qml is by far the BEST way I have ever used to write a UI!
> >
> > UI code is glue, glue, glue. Every single other framework requires so
> much code to do exactly the same things as with Qml.
> >
> > Qt/Qml allowed me to advance at least 5x faster than any other UI
> framework.
> >
> > Is perfect? Nothing is perfect! There is are always pros/cons.
> >
> > Any way... for me, Qml in terms of UI writing is so modern that stands
> that easily stands from any other technology around.
> >
> > I want to express my gratitude to the WHOLE Qt team to make it possible!
> You guys rock! Qt Quick is definitely one of the best things around there.
> >
> > Best regards,
> >
> > --
> > Nuno Santos
> > Founder / CEO / CTO
> > www.imaginando.pt
> >
> > No dia 20/12/2018, às 13:26, Roland Hughes 
> escreveu:
> >
> >> It's still not modern.
> >>
> >> Modern implies "something which learned from past mistakes to overcome
> many of them." When something recent fails we simply call it "a new
> approach" implying that it failed, generally beyond human comprehension.
> Modern implies something succeed in overcoming many/most/all of the
> pitfalls/travesties/tragedies which came before.
> >>
> >> The latter does not apply to QML.
> >>
> >> Newer isn't better, just newer.
> >>
> >> Some "light" reading.
> >>
> >> https://www.cbinsights.com/research/corporate-innovation-product-fails/
> >>
> >> How many of you writing idiot phone apps know their used to be a
> Facebook Phone? A Ubuntu Phone? There even used to be an Apple Newton.
> >>
> >> Now that pretty much every industry analyst agrees the fad of idiot
> phones are over and that 2019 will be the first year of negative growth for
> the industry, scripted UIs will die off with them. Five years from now
> people will think about QML as often as you currently think about the Apple
> Newton.
> >>
> >> More light reading:
> >>
> >>
> http://www.interestingauthors.com/blog/thankyousirmayihaveanother/the-counter-culture-has-won/
> >>
> >> Hopefully you all read far enough in the first link to read about
> Amazon's colossal failure, The Fire Phone. Even I didn't know Microsoft
> tried to market a "smart watch" in 2004. That thing must have only been on
> the market a few minutes!
> >>
> >> Be sure to scroll down to #35. Microsoft Kin One and Kin Two.
> Discontinued after 6 weeks. No wonder I'd never heard about this wanna-be
> Blackberry.
> >>
> >> Oh, from your own link
> >>
> >> /Although it was built in the 1600s, the building still has a very
> *modern* look./
> >>
> >> /
> >> /
> >>
> >>> On 12/19/2018 12:33 PM, Ian Trick wrote:
> >>> On Tue, Dec 18, 2018 at 6:15 AM Roland Hughes
> >>>  wrote:
>  QML is __NOT__ modern.
> >>> modern: Pertaining to a current or recent time and style; not ancient.
> >>>
> >>> https://en.wiktionary.org/wiki/modern
> >>>
> >>> 樂
> >>>
> >> On 17 Dec 2018, at 16:44, Fabrice Salvaire<
> fabrice.salva...@orange.fr>  wrote:
> >>
> >> Dear Qt users,
> >>
> >> Is there people around who needed to hack QQuickTextNode private
> API ? IMHO it restricts strongly the possibility to develop modern custom
> QML items.
> >> --
> >> Roland Hughes, President
> >> Logikal Solutions
> >> (630) 205-1593
> >>
> >> http://www.theminimumyouneedtoknow.com
> >> http://www.infiniteexposure.net
> >> http://www.johnsmith-book.com
> >> http://www.logikalblog.com
> >> http://www.interestingauthors.com/blog
> >> http://lesedi.us
> >>
> >> ___
> >> Interest mailing list
> >> Interest@qt-project.org
> >> https://lists.qt-project.org/listinfo/interest
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > https://lists.qt-project.org/listinfo/interest
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list

Re: [Interest] Android NDK with clang for 5.12.0?

[René Hansen]

I think I'd run into one of those spurious QtCreator flakes, so I just
nuked everything; all settings etc. and started over. It seems to correctly
detect the NDK now.

Thanks again,

/René

On Tue, 18 Dec 2018 at 12:34 ekke  wrote:

> Hi René,
>
> Android NDK r18b should work with Qt 5.12.0 and detect clang.
> (on macOS 10.13.6)
> Build / Target SDK 28
>
> ekke
>
> Am 18.12.18 um 12:08 schrieb René Hansen:
>
> Hi all,
>
>
> So I'm finally trying to make the jump from 5.11 to 5.12 and also upgrade
> from ndk r10e, but I've yet to get the setup correct.
>
> This says to just use the "latest" with android-clang toolchain, but not
> much else.
>
> http://doc.qt.io/qt-5/android-getting-started.html
>
> However, just updating Android NDK Location, to point to e.g. r16b doesn't
> seem to work. I keep getting:
>
> "*No compiler can produce code for this Qt version. Please define one or
> more compilers for:*"
>
> I've tried r18b as well.
>
> Has anyone else successfully gotten this to work?
>
>
> /René
>
> ___
> Interest mailing 
> listInterest@qt-project.orghttps://lists.qt-project.org/listinfo/interest
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Android NDK with clang for 5.12.0?

[René Hansen]

Hi all,


So I'm finally trying to make the jump from 5.11 to 5.12 and also upgrade
from ndk r10e, but I've yet to get the setup correct.

This says to just use the "latest" with android-clang toolchain, but not
much else.

http://doc.qt.io/qt-5/android-getting-started.html

However, just updating Android NDK Location, to point to e.g. r16b doesn't
seem to work. I keep getting:

"*No compiler can produce code for this Qt version. Please define one or
more compilers for:*"

I've tried r18b as well.

Has anyone else successfully gotten this to work?


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

Re: [Interest] [ANN] UniqLogger a Qt-based logging library

[René Hansen]

Thank you for sharing Francesco!

This seems confusing though, as LGPL is indeed free for commercial use:

"License is LGPL-2, if you need a commercial license, feel free to contact
us."


/René

On Sat, 17 Nov 2018 at 00:23 Francesco Lamonica 
wrote:

> Hi all,
> I'd just want to announce the availability of the UniqLogger library,
> it's an open-source Qt-based logging library with multiple backends (
> file, colored console, network, db) that runs on many platforms (linux,
> win, macOS, iOS, android)
>
> You can grab a copy at http://github.com/netresultsit/uniqlogger
> ___
> 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] tr() a string while ignoring context?

[René Hansen]

QT_TR_NOOP() and QT_TRANSLATE_NOOP() is what you're looking for.

/René

On Fri, 9 Nov 2018 at 18:47 Vadim Peretokin  wrote:

> I tried QObject::tr but I'm still having difficulty. I'd like to translate
> dynamic input that's not known as compile-time.
>
> Basically, I'd like to expose the wealth of translations already available
> for my application to my scripting layer, and as you can see that means the
> context needs to be stripped out - so given any input string, return the
> first known translation, irregardless of the context. Is this feasible and
> am I just misunderstanding you?
>
> - Vadim
>
> On Fri, Nov 9, 2018 at 5:52 PM Andy  wrote:
>
>> Aside from QObject::tr() which works without a context string, I think
>> QT_TR_NOOP() is the only other one without a context.
>>
>>
>> https://doc.qt.io/qt-5/i18n-source-translation.html#using-qt-tr-noop-and-qt-translate-noop-in-c
>>
>> Note that QObject::tr can be used outside the class. See
>> some_global_function example here:
>>
>>
>> https://doc.qt.io/qt-5/i18n-source-translation.html#using-qcoreapplication-translate
>>
>> Also of interest might be "Translating Non-Qt Classes":
>>
>>
>> https://doc.qt.io/qt-5/i18n-source-translation.html#translating-non-qt-classes
>>
>> ---
>> Andy Maloney  //  https://asmaloney.com
>> twitter ~ @asmaloney 
>>
>>
>>
>> On Fri, Nov 9, 2018 at 11:12 AM Vadim Peretokin 
>> wrote:
>>
>>> I'd like to translate a string while ignoring the context of it, but
>>> QCoreApplication::translate("", sourceText.toUtf8().constData()) isn't
>>> cutting it. Any ideas on what would work?
>>>
>>> ___
>>> 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] Qt Android with OpenSSL problems "OpenSSL vulnerabilities in your apps"

[René Hansen]

Somehow it seems you're still bundling 1.0.1e, so that's what you need to
look for. I'm not sure where to start, since I don't know your specific
project but afaik OpenSSL was a manual include as far back as 5.6
<http://doc.qt.io/qt-5.6/opensslsupport.html>, so the version you're using,
5.9.4, shouldn't be doing any magic stuff either. /René

On Wed, 31 Oct 2018 at 02:34 Nguyen Ngoc Thach Chau 
wrote:

> The problem is not about send HTTPS request,
> It is about Google Play Store rejection.
> Google Play Store still alert me about OpenSSL library & do not let me
> upload to play store
> Refer alert here: https://support.google.com/faqs/answer/6376725
> :( I update library and re-upload but still do not success.
> I ask Google but they may not give any answer
>
>
> On Tue, Oct 30, 2018 at 12:23 AM René Hansen  wrote:
>
>> Nguyen, I've just updated from 1.0.2n in my own app to 1.0.2p, using my
>> own homegrown build system for OpenSSL.
>>
>> It seems to work and I can complete https request just fine. This is what
>> I get in the app when I query the version:
>>
>> main.cpp:117 (int main(int, char**)): sslLibraryVersionString() "OpenSSL
>> 1.0.2p  14 Aug 2018"
>>
>> I don't know it will solve your problem, but maybe it's worth trying a
>> different build. Here's the link: https://github.com/rhardih/bad.
>>
>> The readme has instructions, but basically it's just:
>>
>>
>>1. Clone repo
>>2. Run make openssl
>>3. Extract libs
>>
>> This is the Android part of the .pri file I use for OpenSSL:
>>
>> linux:android {
>>   OSSL_BUILD_PATH =
>> /Users/rene/Code/bad/extracted/openssl-1.0.2p-armv7-a-build
>>
>>   ANDROID_EXTRA_LIBS += \
>> $$OSSL_BUILD_PATH/lib/libcrypto.so \
>> $$OSSL_BUILD_PATH/lib/libssl.so
>> }
>>
>> /René
>>
>> On Mon, 29 Oct 2018 at 17:17 Thiago Macieira 
>> wrote:
>>
>>> On Monday, 29 October 2018 00:58:20 PDT Nguyen Ngoc Thach Chau wrote:
>>> > I checked APK, it is return openSSL 1.0.2k but it is confusing then I
>>> want
>>>
>>> 1.0.2k is not up-to-date. Upgrade to 1.0.2p.
>>>
>>> --
>>> 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
>>
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt Android with OpenSSL problems "OpenSSL vulnerabilities in your apps"

[René Hansen]

Nguyen, I've just updated from 1.0.2n in my own app to 1.0.2p, using my own
homegrown build system for OpenSSL.

It seems to work and I can complete https request just fine. This is what I
get in the app when I query the version:

main.cpp:117 (int main(int, char**)): sslLibraryVersionString() "OpenSSL
1.0.2p  14 Aug 2018"

I don't know it will solve your problem, but maybe it's worth trying a
different build. Here's the link: https://github.com/rhardih/bad.

The readme has instructions, but basically it's just:


   1. Clone repo
   2. Run make openssl
   3. Extract libs

This is the Android part of the .pri file I use for OpenSSL:

linux:android {
  OSSL_BUILD_PATH =
/Users/rene/Code/bad/extracted/openssl-1.0.2p-armv7-a-build

  ANDROID_EXTRA_LIBS += \
$$OSSL_BUILD_PATH/lib/libcrypto.so \
$$OSSL_BUILD_PATH/lib/libssl.so
}

/René

On Mon, 29 Oct 2018 at 17:17 Thiago Macieira 
wrote:

> On Monday, 29 October 2018 00:58:20 PDT Nguyen Ngoc Thach Chau wrote:
> > I checked APK, it is return openSSL 1.0.2k but it is confusing then I
> want
>
> 1.0.2k is not up-to-date. Upgrade to 1.0.2p.
>
> --
> 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] Qt Android with OpenSSL problems "OpenSSL vulnerabilities in your apps"

[René Hansen]

It looks like you're bundling the stale version of OpenSSL. Try deleting
your *build-* folder to get a fresh one and maybe set *ANDROID_EXTRA_LIBS *to
point directly to the libs outside of your project folder.

/René

On Mon, 29 Oct 2018 at 10:38 Nguyen Ngoc Thach Chau 
wrote:

> Thank you Rene
>
> I check by source code functions below:
> 
> long sslLibraryVersionNumber
> <http://doc.qt.io/qt-5/qsslsocket.html#sslLibraryVersionNumber>()
> QString sslLibraryVersionString
> <http://doc.qt.io/qt-5/qsslsocket.html#sslLibraryVersionString>()
> long sslLibraryBuildVersionNumber
> <http://doc.qt.io/qt-5/qsslsocket.html#sslLibraryBuildVersionNumber>()
> QString sslLibraryBuildVersionString
> <http://doc.qt.io/qt-5/qsslsocket.html#sslLibraryBuildVersionString>()
>
> ===
>
>
> Here is output
>
> 
>
> 268439647
>
> "OpenSSL 1.0.1e 11 Feb 2013"
>
> 268443903
>
> "OpenSSL 1.0.2o 27 Mar 2018"
>
> 
>
>
> I still can not figure out why it is 1.0.1e.
>
> Does it related to graddle build version ?
>
> I checked output folder and see it is using as below
>
> *classpath 'com.android.tools.build:gradle:2.2.3'*
>
>
>
> On Mon, Oct 29, 2018 at 3:33 PM René Hansen  wrote:
>
>> Try to make sure you're actually on the right version, from inside the
>> app. Ie, what does *OpenSSL_version(OPENSSL_VERSION)* return? Your
>> setting of *ANDROID_EXTRA_LIBS* looks correct enough.
>>
>> /René
>>
>>
>>
>> On Mon, 29 Oct 2018 at 08:59 Nguyen Ngoc Thach Chau 
>> wrote:
>>
>>> Dear supporters
>>>
>>> I'm using Qt Android for mobile project.
>>> When I upload APK file to Google Play Store, they always send me an
>>> alert as below
>>> =
>>> https://support.google.com/faqs/answer/6376725
>>> =
>>> I checked APK, it is return openSSL 1.0.2k but it is confusing then I
>>> want to ask to make sure
>>> I searched Google a lot and applied some solutions:
>>> - Add library file to "android\libs\armeabi-v7a" folder
>>> - Add library path to .pro file
>>> ===
>>> android {
>>>
>>> ANDROID_PACKAGE_SOURCE_DIR = $$PWD/android
>>> contains(ANDROID_TARGET_ARCH,armeabi-v7a) {
>>>  ANDROID_EXTRA_LIBS = \
>>> $$PWD/android/libs/armeabi-v7a/libcrypto.so \
>>> $$PWD/android/libs/armeabi-v7a/libssl.so
>>> }
>>> OTHER_FILES += \
>>> #android/build.gradle \
>>> libs/armeabi-v7a/libcrypto.so \
>>> libs/armeabi-v7a/libssl.so \
>>> android/AndroidManifest.xml
>>>
>>> }
>>> ==
>>>
>>> The question is:
>>> When I'm checking output of build process
>>> ("...android-build\libs\armeabi-v7a" folder)
>>> I always see old openSSL library file (libcrypto.so / libssl.so).
>>> I also see that my library files are copied but they are replaced by old
>>> library files (may be it is process of Qt)
>>> => How can I prevent Qt replace my library file in this cases ?
>>> => Is there any success case that use Qt to build Android game / app for
>>> Qt recently ? ( before, I already uploaded successfully some apps, but from
>>> 2 months ago. I can not upload any more because of this problem)
>>>
>>> Note:
>>> - NDK: android-ndk-r17c
>>> - Java: Java\jdk1.8.0_111
>>> - Qt: 5.9.4 => I can upgrade this if needed
>>> - SDK: Android SDK (build tool v25.0.3, android build sdk 28)
>>> - target: min API 16, max API 26
>>> - error details: https://support.google.com/faqs/answer/6376725
>>> ___
>>> 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] Qt Android with OpenSSL problems "OpenSSL vulnerabilities in your apps"

[René Hansen]

Try to make sure you're actually on the right version, from inside the app.
Ie, what does *OpenSSL_version(OPENSSL_VERSION)* return? Your setting of
*ANDROID_EXTRA_LIBS* looks correct enough.

/René



On Mon, 29 Oct 2018 at 08:59 Nguyen Ngoc Thach Chau 
wrote:

> Dear supporters
>
> I'm using Qt Android for mobile project.
> When I upload APK file to Google Play Store, they always send me an alert
> as below
> =
> https://support.google.com/faqs/answer/6376725
> =
> I checked APK, it is return openSSL 1.0.2k but it is confusing then I want
> to ask to make sure
> I searched Google a lot and applied some solutions:
> - Add library file to "android\libs\armeabi-v7a" folder
> - Add library path to .pro file
> ===
> android {
>
> ANDROID_PACKAGE_SOURCE_DIR = $$PWD/android
> contains(ANDROID_TARGET_ARCH,armeabi-v7a) {
>  ANDROID_EXTRA_LIBS = \
> $$PWD/android/libs/armeabi-v7a/libcrypto.so \
> $$PWD/android/libs/armeabi-v7a/libssl.so
> }
> OTHER_FILES += \
> #android/build.gradle \
> libs/armeabi-v7a/libcrypto.so \
> libs/armeabi-v7a/libssl.so \
> android/AndroidManifest.xml
>
> }
> ==
>
> The question is:
> When I'm checking output of build process
> ("...android-build\libs\armeabi-v7a" folder)
> I always see old openSSL library file (libcrypto.so / libssl.so).
> I also see that my library files are copied but they are replaced by old
> library files (may be it is process of Qt)
> => How can I prevent Qt replace my library file in this cases ?
> => Is there any success case that use Qt to build Android game / app for
> Qt recently ? ( before, I already uploaded successfully some apps, but from
> 2 months ago. I can not upload any more because of this problem)
>
> Note:
> - NDK: android-ndk-r17c
> - Java: Java\jdk1.8.0_111
> - Qt: 5.9.4 => I can upgrade this if needed
> - SDK: Android SDK (build tool v25.0.3, android build sdk 28)
> - target: min API 16, max API 26
> - error details: https://support.google.com/faqs/answer/6376725
> ___
> 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] qmllive with android target

[René Hansen]

Did you ever figure out how to do this Alexander?

Would be interested to know how.


/René

On Tue, 2 Oct 2018 at 00:00 Alexander Ivash  wrote:

> Have anybody succeed in configuring such an environment? I'm a bit
> stuck with figuring out what to specify as 'workspacePath'.
>
> Regards, Alexander
> ___
> 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 inspect a Qt Application memory usage?

[René Hansen]

I've tried more than once with Valgrind, but never got it working with
QtCreator on macOS. Just tried it now and:

Failed to start program. Path or permissions wrong?

Might not be Qt related at all. I've run into this bug before:

https://bugs.kde.org/show_bug.cgi?id=383723

Which got fixed, but leads up to other blocking bugs.

On Mon, 22 Oct 2018 at 17:01 Francisco Ares  wrote:

> Em seg, 22 de out de 2018 às 11:50, Nuno Santos 
> escreveu:
>
>> Hi,
>>
>> What tool(s) do you people suggest in order to investigate where is the
>> memory being spent on a Qt application?
>>
>> Thanks!
>>
>> Nuno
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>
>
>
> QtCreator IDE supports Valgrind, for instance. I've already used it, and
> it rocks!
>
> Good luck,
> Francisco
>
>
>
> ___
> 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] qmake, pkg-config and "Requires"

[René Hansen]

After upgrading to the latest XCode, I had to recompile some native libs
and ran into an old familiar bug.

Basically it seems qmake doesn't now what to do whenever it runs into a
`Requires` directive in a pkg-config file. Here's for example openssl:

prefix=/usr/local/Cellar/openssl/1.0.2p
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: OpenSSL
Description: Secure Sockets Layer and cryptography libraries and tools
Version: 1.0.2p
Requires: libssl libcrypto

If I don't uncomment the last line, qmake will spit out the following
generic error:

Project ERROR: /usr/local/opt/openssl/lib/pkgconfig/openssl.pc development
package not found

Now, the solution I've resorted to is to just uncomment any "Requires" in
all dependant libraries .pc files, (all the way down), and add each one
manually. Tedious.

Have I missed something in the docs, or is this simply not something qmake
knows how to handle?
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Including Qt Quick 2 extension plugin in Android App

[René Hansen]

I don't have the problem if I just want a plain shared library, in that
case just bundling the .so with ANDROID_EXTRA_LIBS works fine.

Isolating code into an extension plugin with both QML components and Qt
classes and using that in separate apps is my goal.

If anyone has a working example + build and package process somewhere, I'd
love to see it.

I simply don't get how it's supposed to work. Most SO answers etc. seem to
point to people giving up and just copying stuff directly into their apps.
I just can't get myself to believe there isn't a better way to do this.


/René

On Thu, 4 Oct 2018 at 23:37 Jérôme Godbout  wrote:

> Not sure if it might help, but I had some problems with bundling some lib
> with my application and I end up with this in my project:
> android/lib   // for my .so library, note the lib without s here
> android/libs // for my .jar library
>
> Then I add those lib into the extra libs into my .pro:
>
> ANDROID_EXTRA_LIBS += \
>
> $$PWD/android/lib/libcrypto.so \
>
> $$PWD/android/lib/libssl.so
>
>
> Seem like the android/libs folder is somehow special for qmake.
>
>
> I also attached the copy android sources, if you every need to have .pri that 
> want to include android lib on his own,
>
> this is a work derivated from Luke Vear which I talk to on slack when I was 
> trying to achieve this.
>
>
> Including Android lib and .jars from multiple .pri is a huge pain, avoid it 
> unless you want to use something like the attached files.
>
> How to use the atatched file:
>
>
> include(CopyAndroidSources.pri)
>
> defineReplace(androidPathMaker) {
>
> for(a, $$3) {
>
> result += $$1/$$2/$${a}
>
> }
>
> return($$result)
>
> }
>
> defineReplace(androidSourceMaker) {
>
>  return($$copyAndroidSources($$1, $$2, $$androidPathMaker($$3, $$4, 
> $$5)))
>
> }
>
>
> SOURCES_ANDROID_WORKPAD_TECHKNOWSERV = \
>
> UhfReader.java
>
> QMAKE_EXTRA_TARGETS += 
> $$androidSourceMaker("WorkpadTechKnowServ_Android_Sources", 
> "src/com/amotus/workpad/techknowserv", $$clean_path($$PWD), 
> "android-src/src/com/amotus/workpad/techknowserv", 
> SOURCES_ANDROID_WORKPAD_TECHKNOWSERV)
>
>
> LIB_ANDROID_WORKPAD_TECHKNOWSERV = \
>
> libpda.so \
>
> QMAKE_EXTRA_TARGETS += 
> $$androidSourceMaker("WorkpadTechKnowServ_Android_Lib", "lib", 
> $$clean_path($$PWD), "android-src/lib", LIB_ANDROID_WORKPAD_TECHKNOWSERV)
>
>
> ANDROID_EXTRA_LIBS += \
>
> $$clean_path($$PWD)/android/lib/libpda.so \
>
>
> SO you place everything into android-src and copy all the stuff into android 
> when building the project, so multiple source can declare their own lib usage
>
>
> On Thu, 4 Oct 2018 at 16:39, René Hansen  wrote:
>
>> Hi everyone,
>>
>>
>> I can't seem to get the voodoo right on something that should be trivial.
>>
>> My use case is this; I have two Android apps, which uses similar logic
>> that I'd like to extract and share between them, in the form of an
>> extension plugin. Easy peasy right? Well, I just can't seem to figure it
>> out.
>>
>> In order to distill my understanding of how this is supposed to work I've
>> created a simple example in this repo:
>>
>> https://github.com/rhardih/app-with-extension-example
>>
>> All I've done is the following:
>>
>> 1. Generated the default Qt Quick Controls 2 Swipe app.
>> 2. Generated the default Qt Quick 2 extension plugin.
>> 3. Added a custom QML invokable method, "foo()" on the default "MyItem".
>> 4. Updated the App.pro file, and specified the extension's install path,
>> (Maybe incorrectly), to the QML_IMPORT_PATH
>>
>> I get the autocompletion inside QtCreator for "MyItem" and no import
>> errors in the editor, so something must be right.
>>
>> However... as soon as I run the App, i get:
>>
>> W libApp.so: (null):0 ((null)): QQmlApplicationEngine failed to load
>> component
>> W libApp.so: (null):0 ((null)): qrc:/main.qml:4 module
>> "com.mycompany.qmlcomponents" is not installed
>>
>> The extension build folder looks like this after a build:
>>
>> ├── Makefile
>> ├── android-build
>> │   ├── Users
>> │   │   └── rene
>> │   │   └── Code
>> │   │   └── Qt
>> │   │   └── 5.11.1
>> │   │   └── android_armv7
>> │   │   └── qml
>> │   │   └── com
>> │   │  

[Interest] Including Qt Quick 2 extension plugin in Android App

[René Hansen]

Hi everyone,


I can't seem to get the voodoo right on something that should be trivial.

My use case is this; I have two Android apps, which uses similar logic that
I'd like to extract and share between them, in the form of an extension
plugin. Easy peasy right? Well, I just can't seem to figure it out.

In order to distill my understanding of how this is supposed to work I've
created a simple example in this repo:

https://github.com/rhardih/app-with-extension-example

All I've done is the following:

1. Generated the default Qt Quick Controls 2 Swipe app.
2. Generated the default Qt Quick 2 extension plugin.
3. Added a custom QML invokable method, "foo()" on the default "MyItem".
4. Updated the App.pro file, and specified the extension's install path,
(Maybe incorrectly), to the QML_IMPORT_PATH

I get the autocompletion inside QtCreator for "MyItem" and no import errors
in the editor, so something must be right.

However... as soon as I run the App, i get:

W libApp.so: (null):0 ((null)): QQmlApplicationEngine failed to load
component
W libApp.so: (null):0 ((null)): qrc:/main.qml:4 module
"com.mycompany.qmlcomponents" is not installed

The extension build folder looks like this after a build:

├── Makefile
├── android-build
│   ├── Users
│   │   └── rene
│   │   └── Code
│   │   └── Qt
│   │   └── 5.11.1
│   │   └── android_armv7
│   │   └── qml
│   │   └── com
│   │   └── mycompany
│   │   └── qmlcomponents
│   │   └── qmldir
│   └── libs
│   └── armeabi-v7a
│   └── libExtension.so
├── extension_plugin.o
├── libExtension.so
├── moc_extension_plugin.cpp
├── moc_extension_plugin.o
├── moc_myitem.cpp
├── moc_myitem.o
├── moc_predefs.h
├── myitem.o
└── qmldir

Even so, libExtension.so isn't included in the .apk after building the app.
I can get it included by adding ANDROID_EXTRA_LIBS += /libs/armeabi-v7a/libExtension.so, to App.pro, but that doesn't change
the above error.

I've tried pointing ANDROID_EXTRA_PLUGINS to various locations of the
extension's install folder as well, but that just seems to dump everything
underneath the specified path, directly into assets...

Can anyone tell me, how on earth is this supposed to work? Am I just using
the wrong paths, or am I missing something fundamental here?


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

Re: [Interest] QML Settings fails persistance on Android

[René Hansen]

For now I've reported QTBUG-70419
<https://bugreports.qt.io/browse/QTBUG-70419>, with my own suggestion for
the fix. It's been given P1.

/René

On Fri, 31 Aug 2018 at 18:09 Paolo Angelelli  wrote:

> I also have had several issues (mostly persistence issues) with
> Qt.labs.settings.
> In the end using QSettings directly seemed to work alright, and so i kept
> using
> that.
>
> A pity since Qt.labs.settings looks much easier to use, but nevertheless..
>
> On Fri, 31 Aug 2018 13:26:05 +0200
> René Hansen  wrote:
>
> > Hi,
> >
> >
> > I've run into a number of weird cases where properties on a *Settings*
> > element doesn't properly persist between launches of an app.
> >
> > Initially I used aliasing quite heavily for it's syntactic ease, as per
> the
> > main example from the docs. However, I found that sometimes only part of
> > the the properties would properly persist for next launch. I could never
> > quite reproduce the issues consistently and it had a sort of
> > race-condition'y feel about it. So I gave up an aliases.
> >
> > Instead I've opted for a direct one-way load binding on launch and then a
> > write-back to the Settings when the app closes down. This seems to work
> > correctly regarding value persistence. That is, when it actually works...
> >
> > Here's the pickle; Android has two means of closing an application. One
> is,
> > that you can directly exit it via the back button, which triggers a Close
> > event on the main window, the other is by suspending the app and then
> > "clearing" it out from the list of background processes.
> >
> > The former produces a valid result, where properties are properly
> persisted
> > to the *Settings*, the other does not.
> >
> > I'm guessing this is because the actual write-back happens on the
> > destruction of the Settings element, which is, afaict, never triggered if
> > the app is cleared during suspension.
> >
> > I've made a futile attempt at manually triggering the write-back, at an
> > earlier stage of the shutdown, by connecting the the *application.state*,
> > e.g.:
> >
> > *  Connections {*
> > *target: Qt.application*
> > *onStateChanged: {*
> > *  switch(Qt.application.state) {*
> > *  case Qt.ApplicationActive:*
> > *console.log("Qt.ApplicationActive")*
> > *break;*
> > *  case Qt.ApplicationInactive:*
> > *console.log("Qt.ApplicationInactive")*
> > *break;*
> > *  case Qt.ApplicationSuspended:*
> > *console.log("Qt.ApplicationSuspended")*
> >
> > *// WRITE STUFF TO SETTINGS HERE*
> >
> > *break;*
> > *  case Qt.ApplicationHidden:*
> > *console.log("Qt.ApplicationHidden")*
> > *break;*
> > *  }*
> > *}*
> > *  }*
> >
> > However, even by doing it this way, "seemingly" before the app is
> > suspended, the values are still not written back at all. Presumably it's
> > because of missing destruction trigger mentioned above.
> >
> > So, what are my options here if I'd like to use *Settings* here?
> >
> > I notice QSettings have a sync
> > <http://doc.qt.io/qt-5/qsettings.html#sync> method,
> > but I don't see anything similar for the QML variant.
> >
> > What is the canonical way to solve this problem for Android? Has anyone
> > else done this in a practical manner?
> >
> >
> > Best regards,
> >
> > René Hansen
>
> ___
> 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] QML Settings fails persistance on Android

[René Hansen]

I guess you have a QSettings instance instead of using the QML Settings
component then?

/René

On Fri, 31 Aug 2018 at 14:35 maitai  wrote:

> Hi,
>
> Here I have a slot in my backend (c++) that is called each time the app
> goes to background (from override onPause() in java). I do sync() there.
>
>
> Philippe.
>
> Le 31-08-2018 13:26, René Hansen a écrit :
>
> Hi,
>
>
> I've run into a number of weird cases where properties on a *Settings*
> element doesn't properly persist between launches of an app.
>
> Initially I used aliasing quite heavily for it's syntactic ease, as per
> the main example from the docs. However, I found that sometimes only part
> of the the properties would properly persist for next launch. I could never
> quite reproduce the issues consistently and it had a sort of
> race-condition'y feel about it. So I gave up an aliases.
>
> Instead I've opted for a direct one-way load binding on launch and then a
> write-back to the Settings when the app closes down. This seems to work
> correctly regarding value persistence. That is, when it actually works...
>
> Here's the pickle; Android has two means of closing an application. One
> is, that you can directly exit it via the back button, which triggers a
> Close event on the main window, the other is by suspending the app and then
> "clearing" it out from the list of background processes.
>
> The former produces a valid result, where properties are properly
> persisted to the *Settings*, the other does not.
>
> I'm guessing this is because the actual write-back happens on the
> destruction of the Settings element, which is, afaict, never triggered if
> the app is cleared during suspension.
>
> I've made a futile attempt at manually triggering the write-back, at an
> earlier stage of the shutdown, by connecting the the *application.state*,
> e.g.:
>
> *  Connections {*
> *target: Qt.application*
> *onStateChanged: {*
> *  switch(Qt.application.state) {*
> *  case Qt.ApplicationActive:*
> *console.log("Qt.ApplicationActive")*
> *break;*
> *  case Qt.ApplicationInactive:*
> *console.log("Qt.ApplicationInactive")*
> *break;*
> *  case Qt.ApplicationSuspended:*
> *console.log("Qt.ApplicationSuspended")*
>
> *// WRITE STUFF TO SETTINGS HERE*
>
> *break;*
> *  case Qt.ApplicationHidden:*
> *console.log("Qt.ApplicationHidden")*
> *break;*
> *  }*
> *}*
> *  }*
>
> However, even by doing it this way, "seemingly" before the app is
> suspended, the values are still not written back at all. Presumably it's
> because of missing destruction trigger mentioned above.
>
> So, what are my options here if I'd like to use *Settings* here?
>
> I notice QSettings have a sync <http://doc.qt.io/qt-5/qsettings.html#sync> 
> method,
> but I don't see anything similar for the QML variant.
>
> What is the canonical way to solve this problem for Android? Has anyone
> else done this in a practical manner?
>
>
> Best regards,
>
> René Hansen
>
> ___
> 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] QML Settings fails persistance on Android

[René Hansen]

Hi,


I've run into a number of weird cases where properties on a *Settings*
element doesn't properly persist between launches of an app.

Initially I used aliasing quite heavily for it's syntactic ease, as per the
main example from the docs. However, I found that sometimes only part of
the the properties would properly persist for next launch. I could never
quite reproduce the issues consistently and it had a sort of
race-condition'y feel about it. So I gave up an aliases.

Instead I've opted for a direct one-way load binding on launch and then a
write-back to the Settings when the app closes down. This seems to work
correctly regarding value persistence. That is, when it actually works...

Here's the pickle; Android has two means of closing an application. One is,
that you can directly exit it via the back button, which triggers a Close
event on the main window, the other is by suspending the app and then
"clearing" it out from the list of background processes.

The former produces a valid result, where properties are properly persisted
to the *Settings*, the other does not.

I'm guessing this is because the actual write-back happens on the
destruction of the Settings element, which is, afaict, never triggered if
the app is cleared during suspension.

I've made a futile attempt at manually triggering the write-back, at an
earlier stage of the shutdown, by connecting the the *application.state*,
e.g.:

*  Connections {*
*target: Qt.application*
*onStateChanged: {*
*  switch(Qt.application.state) {*
*  case Qt.ApplicationActive:*
*console.log("Qt.ApplicationActive")*
*break;*
*  case Qt.ApplicationInactive:*
*console.log("Qt.ApplicationInactive")*
*break;*
*  case Qt.ApplicationSuspended:*
*console.log("Qt.ApplicationSuspended")*

*// WRITE STUFF TO SETTINGS HERE*

*break;*
*  case Qt.ApplicationHidden:*
*console.log("Qt.ApplicationHidden")*
*break;*
*  }*
*}*
*  }*

However, even by doing it this way, "seemingly" before the app is
suspended, the values are still not written back at all. Presumably it's
because of missing destruction trigger mentioned above.

So, what are my options here if I'd like to use *Settings* here?

I notice QSettings have a sync
<http://doc.qt.io/qt-5/qsettings.html#sync> method,
but I don't see anything similar for the QML variant.

What is the canonical way to solve this problem for Android? Has anyone
else done this in a practical manner?


Best regards,

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

Re: [Interest] QSettings keys

[René Hansen]

Check out the whitespace section of https://en.wikipedia.org/wiki/INI_file.
Inconsistent whitespace handling is the reason you really want to encode it.

/René

On Wed, 22 Aug 2018 at 20:06 Bertwim  wrote:

> This is what I observe:
>
> For instance, if I enter the following, manually, in the ini file:
>
> [  foo:bar  ]
> line 1 = some text
> line:tail = indented + key has character ':'
>
> and then look at the ini-file after it has been rewritten to disk, this
> has become:
>
> [foo%3Abar]
> line%201=some text
> line%3Atail=indented + key has character ':'
>
> Now, looking at the keys, removing the leading and trailing white spaces
> makes sense to me, as does removing the white spaces around the '='.
> However, writing the space between 'line' and '1' with the %20 encoding,
> and likewise the %3A for the colon looks weird
> and unnecessary, as they are normal ascii characters.
>
> Regards
> Bertwim
>
>
> On 08/22/2018 06:57 PM, Thiago Macieira wrote:
> > On Wednesday, 22 August 2018 01:42:20 PDT Bertwim wrote:
> >> Hi,
> >>
> >> I have a problem with understanding QSettings.  I see that when the
> >> settings are written back to file (ini-file, Linux) certain characters
> >> such as , ':' (colon), etc, written in their hexadecimal encoding
> >> (%20 for space, %3A for ':').
> >> When keys are read (from an ini file) these characters are read as
> >> expected, but writing them back gives this encoding.
> >> Why is this, and -more importantly- Is there any way to prevent this, at
> >> least have the normal printable ascii characters written back to file
> > Are you reporting that you don't get the same string back when you read
> from
> > the file? That would be a bug and we'd need to fix it
> >
> > The escaping is used because those characters are special in the file
> format.
> > For example, the following two lines declare the same key and value:
> >
> > foo=bar
> >   foo = bar
> >
> > So, no, you cannot turn escaping off. You really want it.
> >
> >
>
> ___
> 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] Make Android App Restart When It Can't Resume Quickly

[René Hansen]

As far as I know, Kodi is open source. So is their Android client:

https://kodi.wiki/view/Android_development

Maybe check it out for inspiration.


/René

On Tue, 7 Aug 2018 at 21:35 David Engel  wrote:

> Hi,
>
> I'm one of the developers of the MythTV, open source DVR.  Over the
> last several months, we've ported our frontend (aka client) from Linux
> with Qt to run on Android with Qt.  It's to the point now that some of
> us are using Nvidia Shield TVs as our primary frontends.
>
> One annoying problem that remains is that resuming the app can
> sometimes take several minutes.  By resume I mean switching back to
> the app after the device has been sleeping for several hours or other
> apps have been in use.  I know Android doesn't have traditional swap
> like Linux, so I can only assume that the Android system and/or the Qt
> framework is saving and restoring significant process state somewhere.
> What I'd like to do is have our app resume where it was but only if
> that can be done in a few seconds.  If it can't resume quickly, then
> want it to disregard any previous state and restart.  How can I do
> that?  Other apps like Kodi seem to work that way, but I can't figure
> out how they do it.
>
> Thanks,
> David
> --
> David Engel
> da...@istwok.net
> ___
> 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] Android: Better way of asserting permanent permission refusal

[René Hansen]

It didn't initially occur to me to look up the Android docs, but I think
I've understood how it's meant to be used now. (With the help of this SO
thread
<https://stackoverflow.com/questions/32347532/android-m-permissions-confused-on-the-usage-of-shouldshowrequestpermissionrati>
)

The case I'm interested in is then when
*shouldShowRequestPermissionRationale* returns false, indicating "Don't
show this again" has been checked and I can no longer trigger a permissions
prompt.

Thanks!


/René



On Thu, 28 Jun 2018 at 00:36 Pierre-Yves Siret  wrote:

>
> 2018-06-27 22:33 GMT+02:00 René Hansen :
>
>> Well, yes, I know what rationale means, but the method only takes one
>> parameter, *permission*, which I assume aligns with requestPermissions,
>> e.g. "android.permission.ACCESS_FINE_LOCATION", so how is the text for a
>> *rationale* actually provided? I don't get it.
>>
>>
>> /René
>>
>> On Wed, 27 Jun 2018 at 18:01 Jason H  wrote:
>>
>>> The rationale is the justification to the user on why they should grant
>>> the permission
>>> "Location needed for GPS tagging"
>>> "Camera needed for selfies"
>>>
>>> The "UI" is operating system grant dialog.
>>>
>>>
>>> *Sent:* Tuesday, June 26, 2018 at 5:02 PM
>>> *From:* "René Hansen" 
>>> *To:* "Pierre-Yves Siret" 
>>> *Cc:* interest 
>>> *Subject:* Re: [Interest] Android: Better way of asserting permanent
>>> permission refusal
>>> All things happen for a reason. :)
>>>
>>> My rationale, is that I have a feature which is location based. I want
>>> to be able to let the user toggle the feature on/off via a switch on a
>>> settings page. In the case where a user has permanently deactivated
>>> location permissions for the app, I want this switch to equally be
>>> disabled, with a message instructing the user to edit global permissions,
>>> if they wish to use the feature.
>>>
>>> I haven't tried out *shouldShowRequestPermissionRationale*, since I
>>> don't really understand what it does from the docs.
>>>
>>> "Returns true if you should show UI with a rationale for requesting a
>>> permission."
>>>
>>> I mean... What rationale? What UI?
>>>
>>>
>>> /René
>>>
>>> On Tue, 26 Jun 2018 at 15:05 Pierre-Yves Siret 
>>> wrote:
>>>
>>>> 2018-06-26 13:27 GMT+02:00 René Hansen :
>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>> When requesting specific permissions through
>>>>> QtAndroid::requestPermissions{,Sync}, the host native permissions popup 
>>>>> has
>>>>> the option to "Don't show this again", on subsequent requests, which will
>>>>> permanently disable the popups on future invocations.
>>>>>
>>>>> From then on a permission can only be given through host sytem global
>>>>> settings.
>>>>>
>>>>> The question then becomes, is there a canonical way to figure out, if
>>>>> the user has ticked the "Don't show again" for a specific permission?
>>>>>
>>>>> Right now I've resorted to heuristic, where I time the response of the
>>>>> permissions request. Typically it comes back in < 150 msec, when it has
>>>>> been perma-denied, and the fastest I've been able to allow or deny it via
>>>>> the popup was about 900 msec. I've placed my guesstimate predicate at 400
>>>>> msec, to allow a bit of margin for error on slower devices.
>>>>>
>>>>> But... this seems like such a bad hack.
>>>>>
>>>>> Can anyone tell me of a better way to do this?
>>>>>
>>>>>
>>>>> Best regards,
>>>>>
>>>>> René Hansen
>>>>>
>>>> ___
>>>>> Interest mailing list
>>>>> Interest@qt-project.org
>>>>> http://lists.qt-project.org/mailman/listinfo/interest
>>>>>
>>>>
>>>> Hello,
>>>>
>>>> The better way is not do it.
>>>> This Qt API just mirrors the Android API, and there is no native way to
>>>> know if the user selected "Don't show this again" previously. At least not
>>>> without calling requestPermissions.
>>>>
>>>> Why do you want to check this?
>>>> If you want to show a rationale to thw user about why the app need a
>>>> permission, you can use QtAndroid::shouldShowRequestPermissionRationale.
>>>> It will return true if the user previously denied the permission
>>>> without selecting the "Don't show this again" option.
>>>>
>>>> Regards,
>>>> Pierre-Yves Siret
>>>>
>>>>
>>> ___ Interest mailing list
>>> Interest@qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/interest
>>>
>> The Qt methods are mirrored from the Android API, you can read
> documentation and what others say about the Android methods to get more
> information.
>
> shouldShowRequestPermissionRationale returns true when the user already
> denied the permission at least once but without selecting "Don't show this
> again".
> In this case you should display a custom UI explaining why you need the
> permission. It's different than the system UI asking what permission is
> asked without explanation.
>
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Android: Better way of asserting permanent permission refusal

[René Hansen]

Well, yes, I know what rationale means, but the method only takes one
parameter, *permission*, which I assume aligns with requestPermissions,
e.g. "android.permission.ACCESS_FINE_LOCATION", so how is the text for a
*rationale* actually provided? I don't get it.


/René

On Wed, 27 Jun 2018 at 18:01 Jason H  wrote:

> The rationale is the justification to the user on why they should grant
> the permission
> "Location needed for GPS tagging"
> "Camera needed for selfies"
>
> The "UI" is operating system grant dialog.
>
>
> *Sent:* Tuesday, June 26, 2018 at 5:02 PM
> *From:* "René Hansen" 
> *To:* "Pierre-Yves Siret" 
> *Cc:* interest 
> *Subject:* Re: [Interest] Android: Better way of asserting permanent
> permission refusal
> All things happen for a reason. :)
>
> My rationale, is that I have a feature which is location based. I want to
> be able to let the user toggle the feature on/off via a switch on a
> settings page. In the case where a user has permanently deactivated
> location permissions for the app, I want this switch to equally be
> disabled, with a message instructing the user to edit global permissions,
> if they wish to use the feature.
>
> I haven't tried out *shouldShowRequestPermissionRationale*, since I don't
> really understand what it does from the docs.
>
> "Returns true if you should show UI with a rationale for requesting a
> permission."
>
> I mean... What rationale? What UI?
>
>
> /René
>
> On Tue, 26 Jun 2018 at 15:05 Pierre-Yves Siret  wrote:
>
>> 2018-06-26 13:27 GMT+02:00 René Hansen :
>>
>>> Hi,
>>>
>>>
>>> When requesting specific permissions through
>>> QtAndroid::requestPermissions{,Sync}, the host native permissions popup has
>>> the option to "Don't show this again", on subsequent requests, which will
>>> permanently disable the popups on future invocations.
>>>
>>> From then on a permission can only be given through host sytem global
>>> settings.
>>>
>>> The question then becomes, is there a canonical way to figure out, if
>>> the user has ticked the "Don't show again" for a specific permission?
>>>
>>> Right now I've resorted to heuristic, where I time the response of the
>>> permissions request. Typically it comes back in < 150 msec, when it has
>>> been perma-denied, and the fastest I've been able to allow or deny it via
>>> the popup was about 900 msec. I've placed my guesstimate predicate at 400
>>> msec, to allow a bit of margin for error on slower devices.
>>>
>>> But... this seems like such a bad hack.
>>>
>>> Can anyone tell me of a better way to do this?
>>>
>>>
>>> Best regards,
>>>
>>> René Hansen
>>>
>> ___
>>> Interest mailing list
>>> Interest@qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/interest
>>>
>>
>> Hello,
>>
>> The better way is not do it.
>> This Qt API just mirrors the Android API, and there is no native way to
>> know if the user selected "Don't show this again" previously. At least not
>> without calling requestPermissions.
>>
>> Why do you want to check this?
>> If you want to show a rationale to thw user about why the app need a
>> permission, you can use QtAndroid::shouldShowRequestPermissionRationale.
>> It will return true if the user previously denied the permission without
>> selecting the "Don't show this again" option.
>>
>> Regards,
>> Pierre-Yves Siret
>>
>>
> ___ 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] Android: Better way of asserting permanent permission refusal

[René Hansen]

All things happen for a reason. :)

My rationale, is that I have a feature which is location based. I want to
be able to let the user toggle the feature on/off via a switch on a
settings page. In the case where a user has permanently deactivated
location permissions for the app, I want this switch to equally be
disabled, with a message instructing the user to edit global permissions,
if they wish to use the feature.

I haven't tried out *shouldShowRequestPermissionRationale*, since I don't
really understand what it does from the docs.

"Returns true if you should show UI with a rationale for requesting a
permission."

I mean... What rationale? What UI?


/René

On Tue, 26 Jun 2018 at 15:05 Pierre-Yves Siret  wrote:

> 2018-06-26 13:27 GMT+02:00 René Hansen :
>
>> Hi,
>>
>>
>> When requesting specific permissions through
>> QtAndroid::requestPermissions{,Sync}, the host native permissions popup has
>> the option to "Don't show this again", on subsequent requests, which will
>> permanently disable the popups on future invocations.
>>
>> From then on a permission can only be given through host sytem global
>> settings.
>>
>> The question then becomes, is there a canonical way to figure out, if the
>> user has ticked the "Don't show again" for a specific permission?
>>
>> Right now I've resorted to heuristic, where I time the response of the
>> permissions request. Typically it comes back in < 150 msec, when it has
>> been perma-denied, and the fastest I've been able to allow or deny it via
>> the popup was about 900 msec. I've placed my guesstimate predicate at 400
>> msec, to allow a bit of margin for error on slower devices.
>>
>> But... this seems like such a bad hack.
>>
>> Can anyone tell me of a better way to do this?
>>
>>
>> Best regards,
>>
>> René Hansen
>>
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>> Hello,
>
> The better way is not do it.
> This Qt API just mirrors the Android API, and there is no native way to
> know if the user selected "Don't show this again" previously. At least not
> without calling requestPermissions.
>
> Why do you want to check this?
> If you want to show a rationale to thw user about why the app need a
> permission, you can use QtAndroid::shouldShowRequestPermissionRationale.
> It will return true if the user previously denied the permission without
> selecting the "Don't show this again" option.
>
> Regards,
> Pierre-Yves Siret
>
>
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Android: Better way of asserting permanent permission refusal

[René Hansen]

Hi,


When requesting specific permissions through
QtAndroid::requestPermissions{,Sync}, the host native permissions popup has
the option to "Don't show this again", on subsequent requests, which will
permanently disable the popups on future invocations.

>From then on a permission can only be given through host sytem global
settings.

The question then becomes, is there a canonical way to figure out, if the
user has ticked the "Don't show again" for a specific permission?

Right now I've resorted to heuristic, where I time the response of the
permissions request. Typically it comes back in < 150 msec, when it has
been perma-denied, and the fastest I've been able to allow or deny it via
the popup was about 900 msec. I've placed my guesstimate predicate at 400
msec, to allow a bit of margin for error on slower devices.

But... this seems like such a bad hack.

Can anyone tell me of a better way to do this?


Best regards,

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

[Interest] Can't debug on Android device anymore

[René Hansen]

Hi,


Has anyone else starting seeing this error, when trying to run in debug
mode on device?

"Can't find C++ debugger."

It seems to have started just recently and I haven't made any changes to my
ndk afaict.

QtCreator 4.6.2 on macOS.


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

Re: [Interest] QtQuick for mobile - any experience to share?

[René Hansen]

I can't speak for IOS, but at least on Android, all Qt libraries are packed
inside the application apk as .so files, so no static linking there.

It seems the "go-to" reply on the list and from Qt in general is, "just buy
the license". Somewhat shortsighted, but understandable as it is, Qt is a
business, out to make a profit. However, and as I'm surely not alone in
thinking, I really don't get this approach towards small-timers. The
license cost just isn't feasible for a lone couch coder with a pet project,
who just want to put a $1 proprietary app on the store. Most those kinds of
apps never make much sales anyway and Qt is quickly excluded from the list
of candidate frameworks, due to this perceived upfront cost.

The side effect of supporting indie devs and tinkerers are a lot more
profound though. That is where the ecosystem grows. Bigger ecosystem = more
growth opportunity for the "business" down the line.

It's a shame that many devs are left with the same impression as yourself,
and easily jump ship to React Native or similar. Qt could easily be the
defacto standard for mobile app development. It's just not the narrative
being supported by the Qt corp. Hence, you won't find any official guide or
writeup on how to publish a closed source LGPL paid app on the app store.

As far as I can tell though, there's really no reason why you can't publish
a paid app, which is still compliant.

You need to let people relink against other versions of Qt, but that simply
entails making object files available on request. If ever one is made...


/René





On Mon, 28 May 2018 at 20:08 Sylvain Pointeau 
wrote:

> My mistake, I understood the question was about to make my app GPL
> compliant.
> I would agree with you for the desktop version but I don't think that it
> is feasible for a mobile app (is it not statically linked BTW?)
> and I also understood the app store was not GPL friendly, but maybe my
> knowledge is outdated.
>
> Best regards,
> Sylvain
>
> Le lun. 28 mai 2018 à 19:37, Jean-Michaël Celerier <
> jeanmichael.celer...@gmail.com> a écrit :
>
>> > I thought about it but that does not work for all projects, and I don’t
>> see the business model in that case for my app.
>>
>> in which case would using Qt under the LGPL affect your business model ?
>> You don't have to publish your sources, only under the GPL.
>>
>>
>>
>>
>> ---
>> Jean-Michaël Celerier
>> http://www.jcelerier.name
>>
>> On Mon, May 28, 2018 at 4:32 PM, Sylvain Pointeau <
>> sylvain.point...@gmail.com> wrote:
>>
>>>
>>> On Mon, 28 May 2018 at 16:21, René Hansen  wrote:
>>>
>>>> Or...
>>>>
>>>> Just make your app LGPL compliant and use Qt anyway.
>>>>
>>>
>>> I thought about it but that does not work for all projects, and I don’t
>>> see the business model in that case for my app.
>>>
>>> ___
>>> 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 for mobile - any experience to share?

[René Hansen]

Or...

Just make your app LGPL compliant and use Qt anyway.


/René

On Mon, 28 May 2018 at 15:57 ekke  wrote:

> Am 28.05.18 um 11:25 schrieb Christoph Keller:
>
> You are correct, in my opinion the price for Qt is way too high if you
> only need the mobile platforms.
>
> that's right
> there should be a 30$ or so per Dev per month license for mobile platforms
> really don't understand why Qt isn't pushing mobile Apps with a cheap
> Indie Developer License
>
> That's the reason we're thinking about phasing out Qt in the next project.
>
> sorry to hear
> Qt is so GREAT on mobile platforms w QQC2
>
> You'll likely reach the $100k revenue with a 2-man project soon.
>
> yep - with 2 or more devs you'll reach the limits soon
>
> I'm a single developer working from my home office and it works for me
> with StartUp License
> @Sylvain: if you fit into the 100.000$ maximum I recommend to fill out the
> formular and wait for answer from sales. I'm pretty sure you'll get the
> license. I'm using this license with 99 $ / month and know that there are
> some otherd evs out there using this license
>
> Don't forget there's also Google's Flutter in the game which is written in
> dart and renders all by itself like Qt does.
>
> Flutter does a great work and is pushed by Google.
> but: try to develop a x-platform project with Camera, BluetoothLE, ... and
> compare with Qt ;-)
>
> React Native will give you all the joy of dependency management
> (cocoapods, gradle) and 3rdparty libraries available for mobile which will
> be hell to integrate with Qt (think of lottie animations and google maps
> for example). Also they support the nice "hot reload" (flutter also has
> this feature).
>
> Regards,
> Christoph
>
> On 27.05.18 10:13, Sylvain Pointeau wrote:
>
> Hello Ekke, Jason, Jérôme, and all
>
> Thank you so much for sharing your experience and tips.
>
> Did you use the v-play components? how did you succeed to match the native
> look and feel?
>
> My choice is between Qt and React Native.
>
> I would have gone with Qt but the price is the real barrier for me. As I
> don't know the success of the app, it is hard to start (and convince my
> partners) knowing the price to pay per year.
>
> Ekke you mention in your blog about the startup plan but as far as I know,
> this is discontinued, the startup plan now let you use the "trial" version
> until you go to the store.
>
> React Native is fully in javascript, but seems typescript can be used
> (which is much better) (BTW would be great to use typescript in QML).
>
> The benefit of RN is IMO to do json natively, but the negative aspect is
> that it is not as cross plateform as Qt, so the desktop version is likely
> to be (much) more challenging.
>
> I am really puzzled, I think that Qt is better than RN, but the price ...
>
> Am I missing something? is there someone else in the same situation?
>
> ps: I continue to investigate (and to read the blog of Ekke), my choice is
> not done yet.
>
> Best regards,
> Sylvain
>
>
> ___
> Interest mailing 
> listInterest@qt-project.orghttp://lists.qt-project.org/mailman/listinfo/interest
>
>
>
>
> ___
> Interest mailing 
> listInterest@qt-project.orghttp://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] Video Filters on Android

[René Hansen]

I don't have a Pixel myself, but have you checked that OpenCL isn't rolled
up into */vendor/lib/egl/libEGL_adreno.so*. I know that is the case for
some phones with Mali chipsets at least. Here's a list of *cl* symbols from
one I pulled from a Samsung Galaxy S7:

$
~/Code/Android/android-ndk-r10e/toolchains/x86_64-4.9/prebuilt/darwin-x86_64/bin/x86_64-linux-android-nm
-D ~/Code/Android/samsunggalaxys7/lib/egl/libGLES_mali.so | ag '\bcl[A-Z]'
006823a0 T clBuildProgram
00682584 T clCompileProgram
006808d0 T clCreateBuffer
00688078 T clCreateBufferFromEGLImageARM
00680568 T clCreateCommandQueue
0067fe18 T clCreateContext
006801b4 T clCreateContextFromType
00687db4 T clCreateEventFromEGLSyncKHR
00687e94 T clCreateFromEGLImageKHR
00686f68 T clCreateFromGLBuffer
00687784 T clCreateFromGLRenderbuffer
00687140 T clCreateFromGLTexture
00687398 T clCreateFromGLTexture2D
0068758c T clCreateFromGLTexture3D
00680dc0 T clCreateImage
006816ac T clCreateImage2D
0068176c T clCreateImage3D
00682c24 T clCreateKernel
00682ce0 T clCreateKernelsInProgram
00682008 T clCreateProgramWithBinary
006821dc T clCreateProgramWithBuiltInKernels
00681ef8 T clCreateProgramWithSource
00681c8c T clCreateSampler
00680adc T clCreateSubBuffer
00680148 T clCreateSubDevices
00683334 T clCreateUserEvent
00688244 T clEnqueueAcquireEGLObjectsKHR
00687a04 T clEnqueueAcquireGLObjects
00686cbc T clEnqueueBarrier
00686ae8 T clEnqueueBarrierWithWaitList
006841d8 T clEnqueueCopyBuffer
00684414 T clEnqueueCopyBufferRect
00685828 T clEnqueueCopyBufferToImage
00685098 T clEnqueueCopyImage
006854e4 T clEnqueueCopyImageToBuffer
00683fec T clEnqueueFillBuffer
00684e7c T clEnqueueFillImage
00685b6c T clEnqueueMapBuffer
00685dfc T clEnqueueMapImage
00686b98 T clEnqueueMarker
00686a38 T clEnqueueMarkerWithWaitList
006862d0 T clEnqueueMigrateMemObjects
00686460 T clEnqueueNDRangeKernel
00686794 T clEnqueueNativeKernel
0068365c T clEnqueueReadBuffer
00683820 T clEnqueueReadBufferRect
0068476c T clEnqueueReadImage
00688414 T clEnqueueReleaseEGLObjectsKHR
00687bdc T clEnqueueReleaseGLObjects
00686688 T clEnqueueTask
006861c0 T clEnqueueUnmapMemObject
00686c00 T clEnqueueWaitForEvents
00683b20 T clEnqueueWriteBuffer
00683ce4 T clEnqueueWriteBufferRect
00684af4 T clEnqueueWriteImage
00683614 T clFinish
006835cc T clFlush
0068078c T clGetCommandQueueInfo
006804e4 T clGetContextInfo
0067fd04 T clGetDeviceIDs
0067fda8 T clGetDeviceInfo
006832ac T clGetEventInfo
00683548 T clGetEventProfilingInfo
00686d3c T clGetExtensionFunctionAddress
00686d14 T clGetExtensionFunctionAddressForPlatform
00686d4c T clGetGLContextInfoKHR
00687940 T clGetGLObjectInfo
00687988 T clGetGLTextureInfo
00681b20 T clGetImageInfo
006830bc T clGetKernelArgInfo
00683034 T clGetKernelInfo
00683140 T clGetKernelWorkGroupInfo
00681a9c T clGetMemObjectInfo
0067fc58 T clGetPlatformIDs
0067fca4 T clGetPlatformInfo
00682b64 T clGetProgramBuildInfo
00682adc T clGetProgramInfo
00681e70 T clGetSamplerInfo
006818bc T clGetSupportedImageFormats
0067fca0 T clIcdGetPlatformIDsKHR
006885e0 T clImportMemoryARM
00682834 T clLinkProgram
00680744 T clReleaseCommandQueue
0068049c T clReleaseContext
00680190 T clReleaseDevice
00683420 T clReleaseEvent
00682db0 T clReleaseKernel
00681874 T clReleaseMemObject
00682358 T clReleaseProgram
00681e28 T clReleaseSampler
006806fc T clRetainCommandQueue
00680454 T clRetainContext
0068016c T clRetainDevice
006833d8 T clRetainEvent
00682d68 T clRetainKernel
0068182c T clRetainMemObject
00682310 T clRetainProgram
00681de0 T clRetainSampler
00680814 T clSetCommandQueueProperty
006834cc T clSetEventCallback
00682df8 T clSetKernelArg
00681c28 T clSetMemObjectDestructorCallback
00683468 T clSetUserEventStatus
00682ad4 T clUnloadCompiler
00682ab8 T clUnloadPlatformCompiler
00683240 T clWaitForEvents

I haven't actually found out how to properly link against the _
named libs yet however, because it seems when running a Qt based app,
Dalvik only provides /system/lib and /vendor/lib as library load paths and
not /vendor/lib/egl. I sent another mail to the list regarding this
specific issue a couple of days ago, but no-one has answered it yet.


/René Hansen

On Wed, 4 Apr 2018 at 19:21 Jason H <jh...@gmx.com> wrote:

>  I should find it there yes. But the irony is that I can't find it
> anywhere. Meanwhile the Samsung has it where you would expect. I'm looking
> for an OpenGL for it, but the Adreno SDK doesn't have it. Any idea where I
> mght find it?
>
> Many thanks.
>
> taimen:/ $ find . -name *CL*  2> /dev/null
> ./system/usr/srec/en-US/CLG.prewalk.fst
>
> 1|taimen:/ $ find . -name *GL*  2> /dev/null
> ./sys/bus/platform/drivers/GLINK_CTRL
> ./system/lib/libGLESv1_CM.so
> ./system/lib/libGLESv3.so
> ./system/lib/libGLESv2.so
> ./system/lib/libEGL.so
> ./system/lib64/libGLESv1_CM.so
> ./system/lib64/libGLESv3.so
> ./system/lib64/libGLESv2.so
> ./system/lib64/libEGL.so
> ./vendor/lib/egl/libGLESv2_adreno.so
&g

Re: [Interest] Video Filters on Android

[René Hansen]

fright_foundation.so
> libstagefright_http_support.so
> libstagefright_httplive.so
> libstagefright_omx.so
> libstagefright_omx_utils.so
> libstagefright_soft_aacdec.so
> libstagefright_soft_aacenc.so
> libstagefright_soft_amrdec.so
> libstagefright_soft_amrnbenc.so
> libstagefright_soft_amrwbenc.so
> libstagefright_soft_avcdec.so
> libstagefright_soft_avcenc.so
> libstagefright_soft_flacdec.so
> libstagefright_soft_flacenc.so
> libstagefright_soft_g711dec.so
> libstagefright_soft_gsmdec.so
> libstagefright_soft_hevcdec.so
> libstagefright_soft_mp3dec.so
> libstagefright_soft_mpeg2dec.so
> libstagefright_soft_mpeg4dec.so
> libstagefright_soft_mpeg4enc.so
> libstagefright_soft_opusdec.so
> libstagefright_soft_rawdec.so
> libstagefright_soft_vorbisdec.so
> libstagefright_soft_vpxdec.so
> libstagefright_soft_vpxenc.so
> libstagefright_wfd.so
> libstagefright_xmlparser.so
> libstdc++.so
> libsurfaceflinger.so
> libsurfaceflinger_ddmconnection.so
> libsuspend.so
> libsync.so
> libsysutils.so
> libtextclassifier.so
> libtextclassifier_hash.so
> libtinyxml2.so
> libtombstoned_client.so
> libui.so
> libunwind.so
> libusbhost.so
> libutils.so
> libvintf.so
> libvixl-arm.so
> libvixl-arm64.so
> libvndksupport.so
> libvorbisidec.so
> libvulkan.so
> libwebviewchromium_loader.so
> libwebviewchromium_plat_support.so
> libwifi-service.so
> libwilhelm.so
> libxml2.so
> libz.so
> libziparchive.so
>
>
> *Sent:* Wednesday, April 04, 2018 at 4:54 AM
> *From:* "René Hansen" <ren...@gmail.com>
> *To:* "Jason H" <jh...@gmx.com>
> *Cc:* "interestqt-project.org" <interest@qt-project.org>
> *Subject:* Re: [Interest] Video Filters on Android
> I never got that specific example to work, but assuming you're building
> with the Android NDK, you can include:
>
> #include 
> #include 
>
> Which will give you access to *eglGetCurrentContext()*.
>
> I'm using the r10e ndk, since that's what works with Qt at the moment.
> GLES v3 is available in toolchain v21:
>
> $ ls
> ~/Code/Android/android-ndk-r10e//platforms/android-21/arch-arm/usr/lib/
> crtbegin_dynamic.o  libGLESv2.solibdl.so
> libstdc++.a
> crtbegin_so.o   libGLESv3.solibjnigraphics.so
>  libstdc++.so
> crtbegin_static.o   libOpenMAXAL.so liblog.so
>  libthread_db.so
> crtend_android.olibOpenSLES.so  libm.a
> libz.a
> crtend_so.o libandroid.so   libm.so
>  libz.so
> libEGL.so   libc.a  libm_hard.a rs
> libGLESv1_CM.so libc.so libmediandk.so
>
> If you want to link against OpenCL, you still need to pull a
> *libOpenCL.so* from an actual device though.
>
>
> /René
>
> On Wed, 4 Apr 2018 at 01:52 Jason H <jh...@gmx.com> wrote:
>
>>
>> http://blog.qt.io/blog/2015/03/20/introducing-video-filters-in-qt-multimedia/
>> announced video filter support, and hardware accelerated too!
>>
>> Code:
>> http://code.qt.io/cgit/qt/qtmultimedia.git/tree/examples/multimedia/video/qmlvideofilter_opencl
>>
>> I'm trying to get it running on Android, but I'm going down a rabbit hole
>> with OpenCL 2.0 and EGL 3.2. I have been hacking on it but I don't know
>> where EGLContext is declared.
>>
>> Had anyone gotten this running in Android?
>>
>> Thanks!
>> ___
>> 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 programatically make a tab's text bold?

[René Hansen]

Alternatively suffix an asterisk; Tab -> Tab*. Then remove it on highlight.

/René

On Wed, 4 Apr 2018 at 09:47 Vadim Peretokin  wrote:

> On Wed, Apr 4, 2018 at 7:35 AM Hamish Moffatt 
> wrote:
>
>> On 04/04/18 15:10, Vadim Peretokin wrote:
>> > How can I programatically make a tab's text bold? I'm looking to
>> > notify the user that they need to look at it.
>> >
>> > Note that this is different from using a stylesheet to set the
>> > selected tab bold - I'd like to set any random tab's text bold.
>> >
>> > Been looking at this for several days, appreciate any advice!
>>
>> Using widgets? You didn't say what context.
>>
>> Maybe you can set a dynamic property on the tab when you want it to be
>> bold, and attach a special style using properties in the stylesheet.
>>
>>
>> Hamish
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>
> Yes, using widgets.
>
> I've tried a dynamic property however as far as I can see, I can only set
> the dynamic property on the entire tab bar - not a specific tab. How can I
> set it on a specific tab?
> ___
> 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] Video Filters on Android

[René Hansen]

I never got that specific example to work, but assuming you're building
with the Android NDK, you can include:

#include 
#include 

Which will give you access to *eglGetCurrentContext()*.

I'm using the r10e ndk, since that's what works with Qt at the moment. GLES
v3 is available in toolchain v21:

$ ls ~/Code/Android/android-ndk-r10e//platforms/android-21/arch-arm/usr/lib/
crtbegin_dynamic.o  libGLESv2.solibdl.so
libstdc++.a
crtbegin_so.o   libGLESv3.solibjnigraphics.so
 libstdc++.so
crtbegin_static.o   libOpenMAXAL.so liblog.so
 libthread_db.so
crtend_android.olibOpenSLES.so  libm.a
libz.a
crtend_so.o libandroid.so   libm.so
 libz.so
libEGL.so   libc.a  libm_hard.a rs
libGLESv1_CM.so libc.so libmediandk.so

If you want to link against OpenCL, you still need to pull a
*libOpenCL.so* from
an actual device though.


/René

On Wed, 4 Apr 2018 at 01:52 Jason H  wrote:

>
> http://blog.qt.io/blog/2015/03/20/introducing-video-filters-in-qt-multimedia/
> announced video filter support, and hardware accelerated too!
>
> Code:
> http://code.qt.io/cgit/qt/qtmultimedia.git/tree/examples/multimedia/video/qmlvideofilter_opencl
>
> I'm trying to get it running on Android, but I'm going down a rabbit hole
> with OpenCL 2.0 and EGL 3.2. I have been hacking on it but I don't know
> where EGLContext is declared.
>
> Had anyone gotten this running in Android?
>
> Thanks!
> ___
> 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] Loading libGLES_mali.so on Android

[René Hansen]

Hi,


I'm working on an Android application I'm building and linking against a
device pulled version of libGLES_mali for OpenGL ES and OpenCL specifically.

However when I deploy to a device I get an *UnsatisfiedLinkError*, because
the library resides under */vendor/lib/egl* on the device and not the just
*/vendor/lib* or */system/lib*.

Afaict, this is the two default library paths available to the app process:
https://developer.android.com/reference/java/lang/System.html#getProperties
()

I haven't been able to figure out how to augment the library load path of
the Qt process on Android. I've even tried setting LD_LIBRARY_PATH with
qputenv, but no dice.


Any help much appreciated.

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

Re: [Interest] QML | Column | Buttons

[René Hansen]

You are probably looking to use a *ColumnLayout* and not a *Column*, if you
want to use *Layout.fillWidth*.

/René

On Tue, 27 Feb 2018 at 10:43 Igor Mironchik 
wrote:

> Hello,
>
> How can I shrink all buttons to the widest width in QML Column?
>
> I.e. I have:
>
> Column {
>  anchors.centerIn: parent
>  spacing: 20
>
>  Button {
>  id: btn1
>  implicitHeight: appWindow.minimumCtrlHeight
>  Layout.fillWidth: true
>  text: qsTr( "Press" )
>  }
>
>  Button {
>  id: btn2
>  implicitHeight: appWindow.minimumCtrlHeight
>  Layout.fillWidth: true
>  text: qsTr( "Press Press" )
>  }
>
>  Button {
>  id: btn3
>  implicitHeight: appWindow.minimumCtrlHeight
>  Layout.fillWidth: true
>  text: qsTr( "Press Press Press" )
>  }
>
> }
>
> On desktop these buttons are with the same width, but on Android they
> are as small as possible.
>
> Thank you.
>
> ___
> 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] QML vs Electron

[René Hansen]

On Sat, 17 Feb 2018 at 17:35 Jean-Michaël Celerier <
jeanmichael.celer...@gmail.com> wrote:

> > It would be nice to have a Qml modules manager.
>
> www.qpm.io
>

Maybe my initial comment on qpm was drowned out. :)

> And yes, I do know that qpm exists. Last I checked though, it wasn't
officially endorsed by Qt; the last commit is ~ a year old and it currently
houses 105 packages. NPM has almost 600K... It would go a long way if
developers knew Qt officially supported an initiative like qpm, or
otherwise grandfathered something similar itself.


>
>
>
>
> ---
> Jean-Michaël Celerier
> http://www.jcelerier.name
>
> On Fri, Feb 16, 2018 at 4:41 PM, Jérôme Godbout 
> wrote:
>
>> It would be nice to have a Qml modules manager. I mean, where people
>> could contribute to some common independent reusable modules. That would
>> give good kick start to generate quickly some Qml application.
>>
>> How many of us had to create a drawer Item with animation and self
>> resize, an overlay box, a Qml Popup that can contain any Items into it...
>>
>> Many of us made some great Qml Items or some JS controller that can
>> easily manipulate dynamic objects that could be reused and help Qml in
>> general (just like pip for Python, jQuery plugin listing, ...).
>>
>>
>> The manager would help to centralize and make the modules known by others
>> people and even be improve by community if lucky. Also put the download and
>> rating and you get something that could help give Qml more grip.
>> --
>> *From:* Interest  on
>> behalf of Bob Hood 
>> *Sent:* Friday, February 16, 2018 9:53:27 AM
>> *To:* Qt Interest
>> *Subject:* Re: [Interest] QML vs Electron
>>
>> I want to thank all the respondents for such an interesting discussion.
>>
>> I think René made some interesting observations regarding the massive
>> community support for JS in term of package managers, frameworks and UI
>> toolkits.  I think that is something that really presents a high bar of
>> entry for QML, that everybody wanting to use it must basically roll their
>> own.  As I pointed out, coming from a widget-rich environment to something
>> where I must create my own has always kept me from adopting QML as my
>> cross-device framework of choice.  I have to focus on writing the interface
>> itself first before I can focus on writing my application logic.  With
>> widgets, I drop them in, and only focus on interface writing if I want to
>> customize them.
>>
>> Nikos pointed out:
>>
>> Electron forces you to write the entire application in JS.
>>
>>
>> That kind of struck me.  All of JavaScript's flaws notwithstanding, how
>> could writing your application in a single language for all target devices
>> be a bad thing?  Couple that with the massive community and its support (as
>> René observed) and I think it is one of the driving factors that are
>> causing frameworks like Electron to rise, and QML to languish as an option.
>>
>> It seems like the Qt Company had a great idea, but once it was realized,
>> they expected that it would just pick up steam on its own without any
>> further effort on their part.  Certainly, it has its supporters here, but I
>> can't see it being a viable alternative to things like Electron unless it
>> is *fostered* by the Qt Company.  As René pointed out:
>>
>> It's about growing the ecosystem through marketing and outreach, while
>> lowering the bar of entry by building better primitives and tooling for
>> working with Qt. It is something that the JS world has been exceedingly
>> good at.
>>
>>
>> I would argue the same thing for "QML" if the Qt Company expects more
>> adoption of it.  Otherwise, people are turning to easier-entry
>> alternatives like Electron.
>>
>> ___
>> 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] QML vs Electron

[René Hansen]

On Thu, 15 Feb 2018 at 13:40 Shawn Rutledge <shawn.rutle...@qt.io> wrote:

>
> > On 15 Feb 2018, at 12:23, René Hansen <ren...@gmail.com> wrote:
> >
> > In my opinion Qt, (as a company), is directly responsible for the mess
> that is Electron and todays scape of the app-world. I worked for Nokia back
> in 2011, when they were trying to build, and miserably failed, the next-gen
> phone os platform, entirely as a web-runtime. The switch to a Qt/QtQuick
> approach on top of Meego was such an improvement in speed and overall
> resource usage. Being able to natively bridge with ease, while still
> keeping the door open for Javascript devs. was, and still is the single
> most killer combo out there.
>
> That phone can still be built, and it’s what I want too.  Ubuntu’s version
> looked promising until they dropped it.  Jolla did their version.  (Now if
> only they could ship their tablet, and refresh the phone hardware, and sell
> lots of them.)  Next puri.sm is up to bat.  Everyone is finding it hard
> to compete with the duopoly though, so far.
>

It definitely can, but money flows where hype goes and I've yet to see a
big player rising to the task and succeeding at scale. Personally I think
Meego would have been the one, had it not been for the whole Windows Phone
pivot / disaster.


>
> > As an engineer, being witness to the rise of Electron based apps, has
> left me completely baffled so many times. How could Qt have such a major
> head start and still fail to position themselves, as the de facto cross
> platform development framework. I mean, they even *had* Javascript, fer
> crying out loud! I've never been able to come up with a good reason for
> this. I've resorted to thinking that, either, A, Qt didn't *want* to be
> dominant in that space, and has spent efforts expanding in other markets or
> B, they've had one of the worst marketing divisions in modern tech history.
>
> OK, from your perspective are there a few small, achievable features we
> are still missing?  Or mostly just marketing focus?
>

In my opinion it is both. It's about growing the ecosystem through
marketing and outreach, while lowering the bar of entry by building better
primitives and tooling for working with Qt. It is something that the JS
world has been exceedingly good at. Pretty much any obstacle you can run
into as a new JS developer, has been solved by someone else, who most
likely built a tool or framework to help you out. That is only the case,
because that person found it easy to build and share said tool or
framework. And so on and so forth.

Now, as an example, let's pick, (and pick on), NPM.

Fundamentally I think the way that NPM is being used to dump every little
code snippet is such a broken paradigm, that it's not even funny. It is,
however, very hard to overlook how much it has catapulted growth in the
community. I do think, that what is so deeply broken about NPM, is
something that can be solved by guidance and cultivation of a different
mindset though. Other package managers doesn't suffer this problem to the
same degree.

I know it's easy to look at all the completely ridiculous tendencies, that
*do* come from the JS community at large and balk at the whole notion of
using it as a driving example and you wouldn't be completely out of line.
Choosing *what* to learn from is important here. Paramount I'd say, is
their ability to *dumb* things down enough, that anyone, regardless of
skill level can start building applications from day one.

And yes, I do know that qpm exists. Last I checked though, it wasn't
officially endorsed by Qt; the last commit is ~ a year old and it currently
houses 105 packages. NPM has almost 600K... It would go a long way if
developers knew Qt officially supported an initiative like qpm, or
otherwise grandfathered something similar itself.

Another thing is UI toolkits. If you want to build apps with web
technologies today you can have your pick of the litter of Bootstrap,
Semantic UI, ZURB Foundation, etc., etc. and what they all have in common
is that they are incredibly comprehensive and just so easy to use. QtQuick
Controls 2 is a good start, but lacks so many of the ready made components
offered by other toolkits. It is still very much BYOB.

And what about testing? In JS, the landscape is very rich when it comes to
testing frameworks. Jasmine, Mocha, Sinon, Unexpected. The list goes on. In
e.g. Ruby you have something like RSpec, a personal favourite of mine.
Minitest, Cucumber, etc.. All very extensive frameworks with tons of
documentation and examples for every little corner case. There's even very
specific guidelines and best practices attached to most of these
frameworks, which not only works as examples for newcomers, but also as an
educative tool in learning how to write better tests.

Compare that to testing in QtQuick. It is quite frankly close to a zero
value 

Re: [Interest] QML vs Electron

[René Hansen]

In my opinion Qt, (as a company), is directly responsible for the mess that
is Electron and todays scape of the app-world. I worked for Nokia back in
2011, when they were trying to build, and miserably failed, the next-gen
phone os platform, entirely as a web-runtime. The switch to a Qt/QtQuick
approach on top of Meego was such an improvement in speed and overall
resource usage. Being able to natively bridge with ease, while still
keeping the door open for Javascript devs. was, and still is the single
most killer combo out there.

As an engineer, being witness to the rise of Electron based apps, has left
me completely baffled so many times. How could Qt have such a major head
start and still fail to position themselves, as the de facto cross platform
development framework. I mean, they even *had* Javascript, fer crying out
loud! I've never been able to come up with a good reason for this. I've
resorted to thinking that, either, A, Qt didn't *want* to be dominant in
that space, and has spent efforts expanding in other markets or B, they've
had one of the worst marketing divisions in modern tech history.

Imo building native apps completely on top of a web-runtime, will *never*
be a good idea. I don't care how much Javascript developers, are a dime a
dozen, it's just plain bad engineering and I weep a salty tear, when I see
something like Atom take a good 6 seconds to launch on my 2015 MacBook Pro,
while eating away 359MB of memory, before even opening the first file. (I'm
not an Atom user, this is just an example)

How can that be acceptable, in, any, way?

I know, QtQuick does ship a web-runtime in order to execute JS, but go and
try to open the "texteditor" example from QtCreator. It flies open even in
Debug mode, and consumes about 24MB on launch. It is an entirely different
beast!

How on earth could Qt drop the ball so hard on this one...

Every single time I have to run an Electron, or
insert-name-of-other-js-based-app, I get that sour grape taste in my mouth,
because it didn't have to come to this. I really do blame Qt.

Oh well, at least laptops with 16GB of ram are easy to come by these days,
and it being wintertime, I guess it's nice that all those wasted CPU cycles
at least help to keep me warm. /end-of-rant


/René

On Thu, 15 Feb 2018 at 07:37 Jean-Michaël Celerier <
jeanmichael.celer...@gmail.com> wrote:

> > They don't really compare. Electron forces you to write the entire
> application in JS. With QML you only have to write the UI in it. The rest
> stays C++.
>
> As much as I like C++, the company I work at has been doing pure QML apps
> and they certainly have been developed faster that the equivalent in C++
> would have, with no particular performance problems (but so much bugs
> though... landmines and unimplemented features (looking at you QtMultimedia
> and fonts!) under every step).
>
> ---
> Jean-Michaël Celerier
> http://www.jcelerier.name
>
> On Thu, Feb 15, 2018 at 4:39 AM, Nikos Chantziaras 
> wrote:
>
>> They don't really compare. Electron forces you to write the entire
>> application in JS. With QML you only have to write the UI in it. The rest
>> stays C++.
>>
>> For desktops, you should be using Widgets anyway though. QML just doesn't
>> integrate well. It's made for phones, not desktops. It seems like it was
>> developed in a period of time where everybody was out of their freaking
>> mind about desktops either dying or all of them becoming glorified tablets.
>> But we all saw how well Windows 8.0 was received...
>>
>> Desktops aren't going anywhere anytime soon. And widgets are the
>> *perfect* framework for them. QML is nice for mobile.
>>
>>
>> On 15/02/18 03:45, Bob Hood wrote:
>>
>>> I'm starting to see more and more software being written in, or being
>>> ported to, Electron[1] (e.g., Skype's latest v8 update now uses Electron).
>>> I know QML is supposed to be Qt's solution to cross-device development, so
>>> I'm wondering if anybody here has had opportunity to actually use both, and
>>> what insights they might have in terms of comparing QML's declarative
>>> design to Electron's HTML5 approach.
>>>
>>> Full disclosure: I'm a hard-core Qt C++ developer, and I've made no
>>> secret of the fact that I'm not crazy about QML.  However, it's getting
>>> harder and harder to avoid having to be cross-device in my development, and
>>> while I know Qt Widgets can run on mobile devices, but it seems like a
>>> heavy weight and somewhat inelegant approach.  Something more designed for
>>> the task might be my only/better option.
>>>
>>> On a related note, has anybody done a QML (e)book yet that is focused on
>>> its uses in cross-device development?  The last/only one I saw seemed to
>>> focus only using QML to create interfaces from scratch, and that just
>>> turned me off, coming from the widget-rich environment of Qt desktop.
>>>
>>
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> 

[Interest] Custom SQLite and linking woes

[René Hansen]

Hi list,


I've run into a bit of a problem with the way, that I'd like to use SQLite
in my application.

I need to load an extension, which is turned off by default in Qt, so I've
made the following change to `qtbase/src/plugins/sqldrivers/sqlite/
sqlite.pro`:

DEFINES -= SQLITE_OMIT_LOAD_EXTENSION
DEFINES += SQLITE_ENABLE_LOAD_EXTENSION

And then recompiled and installed the plugin as advised in
http://doc.qt.io/qt-5/sql-driver.html:

I'm on macOS, so I've been building against the Homebrew version of of
sqlite3 like so:

$ ~/Code/Qt/5.9/clang_64/bin/qmake
"INCLUDEPATH+=/usr/local/Cellar/sqlite/3.21.0/include"
"LIBS+=-L/usr/local/Cellar/sqlite/3.21.0/lib -lsqlite3" sqlite.pro

I `make install` and then try to use the new plugin and then this error
appears:

dyld: Symbol not found: _sqlite3_intarray_bind
  Referenced from:
/System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
  Expected in: /usr/local/Cellar/sqlite/3.21.0/lib/libsqlite3.0.dylib
 in /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
The program has unexpectedly finished.

Apparently *CoreData* expects *_sqlite3_intarray_bind* to be defined, but
clearly this isn't present. There's a slight difference in the symbols
available from the systems installed version of sqlite3 and the Homebrew
supplied one:

$ diff <(nm -j /usr/lib/libsqlite3.dylib | grep bind) <(nm -j
/usr/local/Cellar
/sqlite/3.21.0/lib/libsqlite3.0.dylib | grep bind)
10a11
> _sqlite3_bind_pointer
18d18
< _sqlite3_intarray_bind

So, from what I've been able to gather searching for answers regarding
*_sqlite3_intarray_bind,* the solution is to just unset *DYLD_LIBRARY_PATH*,
but ... that sort of defeats the purpose of trying to use a custom version
of sqlite. E.g this answer: https://discussions.apple.com/thread/6646506.

Now, unticking the "Add build library search path to DYLD." in the run
settings, does enable the application to properly load and run but.. again,
with the wrong version of sqlite:

SELECT sqlite_version(); # returns "3.16.1"

As far as I can tell, this is the version that ships with Qt 5.9:

$ grep "3\.16\.1" ~/Code/Qt/5.9/Src/qtbase/src/3rdparty/sqlite/sqlite3.h
#define SQLITE_VERSION"3.16.1"

So, what to do here...?

The weird thing is, that if I run these queries in with that version;
3.16.1:

select sqlite_compileoption_used('ENABLE_LOAD_EXTENSION');
select sqlite_compileoption_used('OMIT_LOAD_EXTENSION');

I get back the results of *1* and *0*, which would indicate that he
recompiled plugin somehow picked up the compile time change. Trying to run
a `select load_extension(..)` query however throws back the `not authorized
Unable to fetch row` error indicating extension loading is still not
enabled. And in case you're wondering, I am running
`sqlite3_enable_load_extension(db_handle, 1)` before any of this.

I've tested the 3.21.0 binary of sqlite via the command line and it can
execute a `select load_extension(...)`, query just fine.

Any pointers with this, is much appreciated.


Best regards,

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

Re: [Interest] Qt3D/QML How to access a QTransform based property from C++

[René Hansen]

Try to register Qt3DCore::QTransform as a metatype in your main():

qRegisterMetaType("Qt3DCore::QTransform");

http://doc.qt.io/qt-5/qmetatype.html#qRegisterMetaType

On Wed, 30 Aug 2017 at 10:16 Volker Enderlein <
volker.enderl...@ifm-chemnitz.de> wrote:

> Hi all,
>
> for an animation system I try to construct some parameterized QML
> components that provide access to their transformation and material via
> properties. The QML part looks the following way:
>
> import Qt3D.Core 2.0
> import Qt3D.Render 2.0
> import QtQuick 2.0
> import Qt3D.Extras 2.0
>
> Entity {
>  id: root
>
>  property Transform frame: Transform {}
>  property Material mat: PhongMaterial { diffuse: Qt.rgba(0.8, 0.8,
> 0.8, 1.0) }
> ...
>
> }
>
> Later I try to update the Transform and Material from C++. But I cannot
> set the properties via qmlEntity->setProperty("Transform",
> QVariant(Qt3DCore::QTransform)); because QTransform is not usable as
> metatype.
>
> How would I do that, or should I use an entirely different approach?
>
>
> Cheers Volker
>
>
> --
>
> ___
> 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