Re: [Interest] Expose C++ singleton to JavaScript file?

[Jason H]

Alexey saved the day:

https://doc.qt.io/qt-5/qtqml-javascript-imports.html#importing-a-qml-module-from-a-javascript-resource

Thanks!


> Sent: Thursday, June 24, 2021 at 10:25 AM
> From: "Jason H" 
> To: "interestqt-project.org" 
> Subject: [Interest] Expose C++ singleton to JavaScript file?
>
> I attempted to google this, but I kept getting hits for the wrong thing.
>
> I have a C++ QObject class ("ApplicationDatabase") exposed to QML via
> qmlRegisterSingletonInstance("com.company", 1, 0, "ApplicationDatabase", 
> _applicationDatabase);
>
> I have a app.js (.pragma library) that is included in many QML components 
> (X.qml) I want the to use the slots/Q_INVOKABLE functions in the app.js:
>
> i.e.
> function userRoles(user) {
>return ApplicationDatabase.userRoles(user);
> }
>
> However when trying to run this, I get:
> qrc:/app.js:165: ReferenceError: ApplicationDatabase is not defined
>
>
> How do I make the .js file aware of the singleton?
>
> ___
> 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] Expose C++ singleton to JavaScript file?

[Jason H]

I attempted to google this, but I kept getting hits for the wrong thing.

I have a C++ QObject class ("ApplicationDatabase") exposed to QML via
qmlRegisterSingletonInstance("com.company", 1, 0, "ApplicationDatabase", 
_applicationDatabase);

I have a app.js (.pragma library) that is included in many QML components 
(X.qml) I want the to use the slots/Q_INVOKABLE functions in the app.js:

i.e.
function userRoles(user) {
   return ApplicationDatabase.userRoles(user);
}

However when trying to run this, I get:
qrc:/app.js:165: ReferenceError: ApplicationDatabase is not defined


How do I make the .js file aware of the singleton?

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

Re: [Interest] make check not working (macOS)

[Jason H]

> > I want a brain-dead, simple, 0-maintenance test kit.  The only thing the
> > developers should have to worry about is adding test implementations once
> > it is started.
> >
> > Can this be achieved in Qt?
>
> With Qt and QtTest, sure. But your question was "in qmake".
>
> The answer is also yes. You need to move the common parts to a qmake project
> include file (.pri) and simply include() it in each and every target, then add
> to SOURCES the main executable for each program.
>
> If build times are an issue, you may want to refactor so the common sources
> are built into a uninstalled static library, which you link into each test.
> However, using static libraries often bring headaches of their own, especially
> when C++ global statics with side-effects are involved.

That's fantastic news! Is there an example anywhere?
I'm not (yet) concerned about build times, but yes, that's a good idea. Why are 
dynamic libraries not suggested?


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

Re: [Interest] make check not working (macOS)

[Jason H]

> Sent: Wednesday, June 23, 2021 at 11:45 AM
> From: "Kai Köhne" 
> To: "Jason H" , "interestqt-project.org" 
> 
> Subject: RE: [Interest] make check not working (macOS)
>
> HI Jason,
> 
> It looks to me like you're trying to add a test case into your normal 
> application executable. Is that correct?

Yes.
 
> The canonical use of QTest is different: You create a separate project for 
> the tests, in a separate directory. If you e.g. check back on 
> https://doc.qt.io/qt-5/qttestlib-tutorial1-example.html , this creates a new 
> file testqstring.cpp, and then uns "qmake -project" in the directory to 
> create a completely new project.
> 
> Hope this helps.

Yes it does. Thanks!

So I have to manually maintain the modules being tested as a separate project? 
If so, that's pretty undesirable because of the manual effort to make sure that 
the test project is using the same source that the actual application uses. I 
hope I can automate that somehow? (Preferably requiring 0 maintenance)  I would 
not be opposed to a "tests" subdir to hold this project, but then, that needs 
it's own .pro, and it needs to automatically reference the parent project's 
files. Immediately I am thinking I can just use HEADERS/SOURCES files with ../ 
prefixes but that violates my 0-maintenance requirement.

I want a brain-dead, simple, 0-maintenance test kit.  The only thing the 
developers should have to worry about is adding test implementations once it is 
started.

Can this be achieved in Qt?





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

Re: [Interest] make check not working (macOS)

[Jason H]

Ok, I was missing Q_OBJECT

But then `make`:
 *** No rule to make target `test_sqldatabase.moc.json', needed by 
`ndx-poc-ui_metatypes.json'.  Stop.

I don't know where these .json files fit in the Qt build process.  I've never 
had to worry about them before.

> Sent: Wednesday, June 23, 2021 at 11:08 AM
> From: "Jason H" 
> To: "interestqt-project.org" 
> Subject: [Interest] make check not working (macOS)
>
> It's been a while since I use QtTest, and never on MacOS.
>
> I am following the tutorial at: https://doc.qt.io/qt-5/qtest-overview.html 
> and https://doc.qt.io/qt-5/qttestlib-tutorial1-example.html
>
> Changes from existing project:
> QT += testlib
> CONFIG += testcase no_testcase_installs
> HEADERS += test_sqldatabase.h
>
> Added a test_sqldatabase.h, containing:
> class Test_SqlDatabase: public QObject {
> ...
> private slots:
> ...tests...
> };
>
> QTEST_MAIN(Test_SqlDatabase)
> #include "moc_test_sqldatabase.h" // the tutorial says #include 
> "testqstring.moc" But it looks like the moc naming convention change
>
> // end of test_sqldatabase.h
>
> When I run `qmake && make check` it just executes the main program
>
>
> What did I miss?
> the make target is:
> check: first
> .../target_wrapper.sh $(TESTRUNNER) 
> ./$(QMAKE_TARGET).app/Contents/MacOS/$(QMAKE_TARGET) $(TESTARGS)
>
> Which makes me think TESTRUNNER is not being set?
>
> ___
> 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] make check not working (macOS)

[Jason H]

It's been a while since I use QtTest, and never on MacOS.

I am following the tutorial at: https://doc.qt.io/qt-5/qtest-overview.html and 
https://doc.qt.io/qt-5/qttestlib-tutorial1-example.html

Changes from existing project:
QT += testlib
CONFIG += testcase no_testcase_installs
HEADERS += test_sqldatabase.h

Added a test_sqldatabase.h, containing:
class Test_SqlDatabase: public QObject {
...
private slots:
...tests...
};

QTEST_MAIN(Test_SqlDatabase)
#include "moc_test_sqldatabase.h" // the tutorial says #include 
"testqstring.moc" But it looks like the moc naming convention change

// end of test_sqldatabase.h

When I run `qmake && make check` it just executes the main program


What did I miss?
the make target is:
check: first
.../target_wrapper.sh $(TESTRUNNER) 
./$(QMAKE_TARGET).app/Contents/MacOS/$(QMAKE_TARGET) $(TESTARGS)

Which makes me think TESTRUNNER is not being set?

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

Re: [Interest] Beginner DBUS Question: how to enforce the XML?

[Jason H]

> Sent: Tuesday, June 15, 2021 at 6:21 PM
> From: "Thiago Macieira" 
> To: "interestqt-project.org" 
> Cc: "Jason H" 
> Subject: Re: [Interest] Beginner DBUS Question: how to enforce the XML?
>
> On Tuesday, 15 June 2021 13:24:12 PDT Jason H wrote:
> > So I think the Qt docs and support on DBUS are quite good. But I keep coming
> > back to a non-Q- non-G DBUS question: When interfacing with C/CPP code
> > using libdbus or sdbus, which manually pack parameters to messages, how is
> > "proper" DBUS messaging enforced?
>
> There is no XML when messages are being exchanged. So there's nothing to be
> enforced.
>
> > Example:
> > I have a XML Definition for a service I publish, I use tools to generate the
> > wrappers for it. Someone using libdbus/sdbus consumes that service. I
> > update the XML (say add or remove a parameter), do my workflow, and now
> > their client is expecting the wrong parameters.
> >
> > Reverse example:
> > I consume a DBUS service and they update their libdbus/sdbus code, they
> > don't have an XML, how do I identify it before it gets deployed?
> >
> > I'm interested in some kind of build-time compilation process check. I'm
> > thinking:
> > 1. Force them to publish a XML.
> > 2. Generate a header from it
> > 3. Force them to have an implementation that consumes the header
> > 4. Rely on the compiler to error when the header doesn't match the
> > implementation.
>
> Ok, that makes sense.

Glad to hear it :-)

> > However there are two bug flaws with this:
> > 1. I'm forcing them to adhere to the development protocol (maybe a makefile
> > is sufficiently forceful?)
> > 2. I can't guarantee the functions are actually the ones used (a bigger
> > issue I know)
>
> If they aren't used, why do you care? It's the same as requiring everyone to
> use blue pens: if it's not part of something you see, why do you care?

Well it's more about not trusting the competence of the other side. Or,
alternatively, them not trusting a n00b (me). Perhaps I waxed too philosophical.
Yeah, it would be possible to use an alternative function, which should be
caught in code review, but I'm looking for something brain-dead simple
and preferably enforceable by the CI system.

It seems that I've got to invent some kind of Qt and C (no ++, libdbus/sdbus
legacy codebase) workflow that everyone can agree on. I was hoping that this
workflow already existed in the world.









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

[Interest] Beginner DBUS Question: how to enforce the XML?

[Jason H]

So I think the Qt docs and support on DBUS are quite good. But I keep coming 
back to a non-Q- non-G DBUS question: When interfacing with C/CPP code using 
libdbus or sdbus, which manually pack parameters to messages, how is "proper" 
DBUS messaging enforced?


Example:
I have a XML Definition for a service I publish, I use tools to generate the 
wrappers for it. Someone using libdbus/sdbus consumes that service. I update 
the XML (say add or remove a parameter), do my workflow, and now their client 
is expecting the wrong parameters.

Reverse example:
I consume a DBUS service and they update their libdbus/sdbus code, they don't 
have an XML, how do I identify it before it gets deployed?



I'm interested in some kind of build-time compilation process check. I'm 
thinking:
1. Force them to publish a XML.
2. Generate a header from it
3. Force them to have an implementation that consumes the header
4. Rely on the compiler to error when the header doesn't match the 
implementation.

However there are two bug flaws with this:
1. I'm forcing them to adhere to the development protocol (maybe a makefile is 
sufficiently forceful?)
2. I can't guarantee the functions are actually the ones used (a bigger issue I 
know)
3. Most of the tools generate "ugly bindings"  - that is I can't take:



  

  
  
  
  
  

  


and have it generate:

void ManyArgs(unsigned int x, std::string str, double trouble, double* d_ret, 
std::string *out);

for which they provide a matching implementation for. But most of the tools 
generate accurate and correct code.

An alternative approach would be to proxy the commands against the XML, so make 
sure every message sent/received conforms to it. I don't know if there is 
software to enable this?

Has anyone handled this before? How/Are DBUS signals versioned?

Many thanks for any insights.

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

Re: [Interest] QNetwork classes for submitting google forms

[Jason H]

> Sent: Monday, June 14, 2021 at 2:07 PM
> From: "Jason H" 
> To: "Jason H" 
> Cc: "Scott Bloom" , "Thiago Macieira" 
> , "interest@qt-project.org" 
> 
> Subject: Re: [Interest] QNetwork classes for submitting google forms
>
> 
> 
> > Sent: Monday, June 14, 2021 at 1:42 PM
> > From: "Jason H" 
> > To: "Scott Bloom" 
> > Cc: "Thiago Macieira" , 
> > "interest@qt-project.org" 
> > Subject: Re: [Interest] QNetwork classes for submitting google forms
> >
> > 
> > 
> > > Sent: Monday, June 14, 2021 at 1:12 PM
> > > From: "Scott Bloom" 
> > > To: "Thiago Macieira" , 
> > > "interest@qt-project.org" 
> > > Subject: Re: [Interest] QNetwork classes for submitting google forms
> > >
> > > This has come up a couple times for me through the years (essentially 
> > > make a network request and don’t return until the request has finished).
> > > 
> > > Is there an example anywhere of the "Thiago" (proper..  ) way to code 
> > > this?  I see this issue in a similar vane to using QThread, when the 
> > > Trolls/Nokia/TQP (I forget who originally wrote it) wrote up a small but 
> > > very effective white paper on the proper method of using Qthread, it 
> > > clarified a ton of questions for many people.
> > > 
> > 
> > 
> > You'd probably get feedback that QThread is "too heavy" and for i/o bound 
> > processes one async event loop is enough. (I've been on the rx end of that)
> > 
> > I think my highest of levels approach is correct:
> > https://lists.qt-project.org/pipermail/interest/attachments/20210602/9366d8ea/attachment-0001.html
> >  (apologies for the HTML, but my mailer responds by what ever I am replying 
> > to.)
> > 
> > The one caveat to my code, is if you don't need synchronous requests 
> > (regrettably, this part of my app requires them) then you can ignore the 
> > QEventloop stuff, that is leave lines that references `loop` it out, and 
> > you'll have a fully async inline lambda.
> > 
> > You however are asking for a synchronous and this I think is the best way. 
> > Feel free to assault the code, (Thiago and others.) I would like Qt to 
> > adopt some kind of this pattern.
> 
> I cleaned this up a bit:

https://gist.github.com/jhihn/19a4f03eeae473f3083dcecb4e25ad59

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

Re: [Interest] QNetwork classes for submitting google forms

[Jason H]

> Sent: Monday, June 14, 2021 at 1:42 PM
> From: "Jason H" 
> To: "Scott Bloom" 
> Cc: "Thiago Macieira" , "interest@qt-project.org" 
> 
> Subject: Re: [Interest] QNetwork classes for submitting google forms
>
> 
> 
> > Sent: Monday, June 14, 2021 at 1:12 PM
> > From: "Scott Bloom" 
> > To: "Thiago Macieira" , 
> > "interest@qt-project.org" 
> > Subject: Re: [Interest] QNetwork classes for submitting google forms
> >
> > This has come up a couple times for me through the years (essentially make 
> > a network request and don’t return until the request has finished).
> > 
> > Is there an example anywhere of the "Thiago" (proper..  ) way to code 
> > this?  I see this issue in a similar vane to using QThread, when the 
> > Trolls/Nokia/TQP (I forget who originally wrote it) wrote up a small but 
> > very effective white paper on the proper method of using Qthread, it 
> > clarified a ton of questions for many people.
> > 
> 
> 
> You'd probably get feedback that QThread is "too heavy" and for i/o bound 
> processes one async event loop is enough. (I've been on the rx end of that)
> 
> I think my highest of levels approach is correct:
> https://lists.qt-project.org/pipermail/interest/attachments/20210602/9366d8ea/attachment-0001.html
>  (apologies for the HTML, but my mailer responds by what ever I am replying 
> to.)
> 
> The one caveat to my code, is if you don't need synchronous requests 
> (regrettably, this part of my app requires them) then you can ignore the 
> QEventloop stuff, that is leave lines that references `loop` it out, and 
> you'll have a fully async inline lambda.
> 
> You however are asking for a synchronous and this I think is the best way. 
> Feel free to assault the code, (Thiago and others.) I would like Qt to adopt 
> some kind of this pattern.

I cleaned this up a bit:

What to request : http://1270.0.1:4321/file?f=1234 (GET)
What to do: { /* save file */ } or { /* handle error */ }
  
Invocation:
   remoteCloud->synchronousPostFile("http://1270.0.1:4321/file?f=1234;  
   
   [=] (QNetworkReply* reply, QString filename) {
   if (reply->error() == QNetworkReply::NoError) {
  { /* save file */ }
   } else {
  { /* handle error */ }
   }
} // end of lambda
   ); // end of call


void RemoteCloud::synchronousGetFile(const QString& endpoint, 
std::function lambda) {
QEventLoop loop; 
QNetworkReply * reply = remoteCloud->get(endpoint);
QObject::connect(reply, ::finished, , 
::quit); 
QObject::connect(reply, ::finished, reply, [=]{
lambda(reply);
reply->deleteLater(); 
});
loop.exec(); // wait for finished before returning
}


void RemoteCloud::getFile(const QString& endpoint, std::function lambda) {
QNetworkReply * reply = remoteCloud->get(endpoint);
QObject::connect(reply, ::finished, reply, [=]{
lambda(reply);
reply->deleteLater(); // always cleanup after the lambda ran
});
}
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QNetwork classes for submitting google forms

[Jason H]

> Sent: Monday, June 14, 2021 at 1:12 PM
> From: "Scott Bloom" 
> To: "Thiago Macieira" , "interest@qt-project.org" 
> 
> Subject: Re: [Interest] QNetwork classes for submitting google forms
>
> This has come up a couple times for me through the years (essentially make a 
> network request and don’t return until the request has finished).
> 
> Is there an example anywhere of the "Thiago" (proper..  ) way to code this?  
> I see this issue in a similar vane to using QThread, when the 
> Trolls/Nokia/TQP (I forget who originally wrote it) wrote up a small but very 
> effective white paper on the proper method of using Qthread, it clarified a 
> ton of questions for many people.
> 


You'd probably get feedback that QThread is "too heavy" and for i/o bound 
processes one async event loop is enough. (I've been on the rx end of that)

I think my highest of levels approach is correct:
https://lists.qt-project.org/pipermail/interest/attachments/20210602/9366d8ea/attachment-0001.html
 (apologies for the HTML, but my mailer responds by what ever I am replying to.)

The one caveat to my code, is if you don't need synchronous requests 
(regrettably, this part of my app requires them) then you can ignore the 
QEventloop stuff, that is leave lines that references `loop` it out, and you'll 
have a fully async inline lambda.

You however are asking for a synchronous and this I think is the best way. Feel 
free to assault the code, (Thiago and others.) I would like Qt to adopt some 
kind of this pattern.


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

Re: [Interest] QNetwork classes for submitting google forms

[Jason H]

> Sent: Monday, June 14, 2021 at 10:36 AM
> From: "Jason H" 
> To: "Max Paperno" 
> Cc: interest@qt-project.org
> Subject: Re: [Interest] QNetwork classes for submitting google forms
>
> You might want to look at my pos on Jun 2 "Re: [Interest] QNetworkReply 
> lambdas?"
>
> Where I give example code on how to set up a lambda. You can ignore the 
> synchronous parts.

After reading more replies on this thread, you might want to look at the 
synchronous parts on how to properly wield an event loop in this situation.


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

Re: [Interest] QNetwork classes for submitting google forms

[Jason H]

You might want to look at my pos on Jun 2 "Re: [Interest] QNetworkReply 
lambdas?"

Where I give example code on how to set up a lambda. You can ignore the 
synchronous parts.

> Sent: Friday, June 11, 2021 at 8:29 PM
> From: "Max Paperno" 
> To: interest@qt-project.org
> Subject: Re: [Interest] QNetwork classes for submitting google forms
>
> Ah yeah, it would help a lot to have a Qt event loop to actually deliver 
> the signals... silly me. Also forgot to delete the reply as per docs.
> 
> Tested, works:
> 
> 
> int main(int argc, char**argv)
> {
>    QCoreApplication app(argc, argv);
>    QUrlQuery postData;
>    postData.addQueryItem("entry.2020959411", "Qt Query");
> 
>    QUrl serviceUrl("http://httpbin.org/post;);
>    QNetworkRequest request(serviceUrl);
>    QNetworkAccessManager networkManager;
> 
>    QObject::connect(, ::finished,
>     [&](QNetworkReply *reply) {
>    int status = 
> reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt();
>    qDebug() << "Got status:" << status << "Data:" << reply->readAll();
>    //  etc
>    reply->deleteLater();
>    app.exit();
>    });
> 
>    networkManager.post(request,
> postData.toString(QUrl::FullyEncoded).toUtf8());
> 
>    return app.exec();
> }
> 
> 
> 
> Please reply to the list, not to me, thanks.
> 
> HTH,
> -Max
> 
> 
> On 6/11/2021 6:53 PM, Nicholas Yue wrote:
> > ```
> > intmain()
> > {
> > QUrlQuerypostData;
> > postData.addQueryItem("emailAddress","abc@gmail.com 
> > ");
> > postData.addQueryItem("entry.2020959411","QtQuery");
> > QUrlserviceUrl("https://docs.google.com/forms/d/152CTd4VY9pRvLfeACOf6SmmtFAp1CL750Sx72Rh6HJ8/formResponse;);
> > QNetworkRequestrequest(serviceUrl);
> > QNetworkAccessManagernetworkManager;
> > boolgotResponse=false;
> > QObject::connect(,::finished,
> > [](QNetworkReply*reply){
> > intstatus=reply->attribute(
> > QNetworkRequest::HttpStatusCodeAttribute).toInt();
> > qDebug()< > //etc
> > gotResponse=true;
> > });
> > networkManager.post(request,
> > postData.toString(QUrl::FullyEncoded).toUtf8());
> > while(!gotResponse){
> > QThread::sleep(1);//orwhateversleepmethod,justwaitingforaresponse.
> > qDebug()<<"Slept1second";
> > }
> > return0;
> > }
> > ```
> > It just sits there, I get the regular print out about 'Slept 1 second', 
> > other than that, it does not seems to be working
> >
> > On Fri, 11 Jun 2021 at 14:18, Max Paperno  > > wrote:
> >
> >
> > > QObject::connect(, ::finished, ...
> >
> > Whoops, should really be
> > QObject::connect(,
> > ::finished, ...
> >
> > -Max
> > ___
> > Interest mailing list
> > Interest@qt-project.org 
> > https://lists.qt-project.org/listinfo/interest
> >
> >
> >
> > -- 
> > Nicholas Yue
> > Graphics - Arnold, Alembic, RenderMan, OpenGL, HDF5
> > Custom Dev - C++ porting, OSX, Linux, Windows
> > http://au.linkedin.com/in/nicholasyue
> > https://vimeo.com/channels/naiadtools
> 
> 
> ___
> 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] QJsonDocument::fromVariant failing with list

[Jason H]

> Sent: Wednesday, June 09, 2021 at 10:48 AM
> From: "Thiago Macieira" 
> To: interest@qt-project.org
> Subject: Re: [Interest] QJsonDocument::fromVariant failing with list
>
> On Wednesday, 9 June 2021 07:28:08 PDT Jason H wrote:
> > One hack I would workfor me is a new class, QVariantMapList, (List of
> > QVariantMaps) which is really all I need at the moment, unless there'd be a
> > need for QVariantListList too? (That's a terrible name though)
> >
> > Ultimately, I just want to express JSON as closely as I can in C++.
> > Ideally:
> > QVariantMap map {
> > {"err", QVariant()},
> > {"letters", QVariantMapList {
> > {{"a",1}},
> > {{"b",2}},
> > {{"c",3}}
> > }}
> > };
>
> Stop using QVariantMapList. You want a QVariantMap.

I think you meant QVariantList?:
 QVariantMap map {
   {"err", QVariant()},
   {"letters", QVariantList {
 QVariantMap {{"a",1}},
 QVariantMap {{"b",2}},
 QVariantMap {{"c",3}}
   }}
 };

I had hoped that by using QList that I could omit the 3 
QVariantMaps above.

If you didn't mean QVariantList, then I have confused you, what I wanted was
(JSON) [{"a":1}, {"b":2}, {"c":3}] not {"a":1, "b":2, "c":3}
Perhaps I confused you by using sequential letters but [{"a":1}, {"a":2}, 
{"a":3}] could be just as valid.

But anyway, it seems my mistake was thinking that QVariant hold a 
QList, the best thing possible is the more general case of 
QVariantList, and this can be a heterogeneous collection of QVariants. Neither 
compiler nor Qt is capable of enforcing homogeneity as a QList of QVariantMaps 
AND having that collection being a QVariant itself, in a declaration. It would 
have to be built at runtime.

Did I get that right?




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

Re: [Interest] QJsonDocument::fromVariant failing with list

[Jason H]

One hack I would workfor me is a new class, QVariantMapList, (List of QVariantMaps) which is really all I need at the moment, unless there'd be a need for QVariantListList too? (That's a terrible name though)

 


Ultimately, I just want to express JSON as closely as I can in C++.

Ideally:


	QVariantMap map {
		{"err", QVariant()},
		{"letters", QVariantMapList {
{{"a",1}},
{{"b",2}},
{{"c",3}}
		}}
	};


 

Sent: Wednesday, June 09, 2021 at 10:15 AM
From: "Jérôme Godbout" 
To: "Thiago Macieira" , "interest@qt-project.org" 
Subject: Re: [Interest] QJsonDocument::fromVariant failing with list




I understand the homogenous part when you do decoding, but encoding to json should support the homogenous, isn’t? why not? I understand that the decode of that json would alter the type.

 

QList  encode json  [{‘a’: ‘b’}, {‘c’:’d’}]   decode json   QList 

 

Should be possible as long as QList where T can be convert to QVariant. Maybe an external converter function should be used. If this is not supported, is there a way where we could trap this at compile time warning?

 

Maybe there is a limitation I do not see here.

 

 


From: Interest  on behalf of Thiago Macieira 
Date: Wednesday, June 9, 2021 at 10:08 AM
To: interest@qt-project.org 
Subject: Re: [Interest] QJsonDocument::fromVariant failing with list



On Wednesday, 9 June 2021 00:34:40 PDT Allan Sandfeld Jensen wrote:
> > QList is not a type, it's a template. Neither QVariant nor QJsonDocument
> > can know all possible QList instantiations. So they have coded only a few
> > (QVariantList and QStringList only, possibly QVector and
> > QVector in Qt 5 too, I don't remember).
>
> I guess our system could detect QList as QVariantList and
> QList as QStringList. They should be binary identical anyway.

They already do.

The problem is QList of other things that it's not coded for, like
QList in this case, or QList or QList. Since JSON
arrays are not expected to be homogeneous, QJsonDocument does not support
them.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
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] QJsonDocument::fromVariant failing with list

[Jason H]

> Sent: Wednesday, June 09, 2021 at 3:34 AM
> From: "Allan Sandfeld Jensen" 
> To: interest@qt-project.org
> Cc: "Thiago Macieira" 
> Subject: Re: [Interest] QJsonDocument::fromVariant failing with list
>
> On Dienstag, 8. Juni 2021 23:47:50 CEST Thiago Macieira wrote:
> > On Tuesday, 8 June 2021 13:57:53 PDT Jason H wrote:
> > > Which is neiher what I acually had but performs the same bad conversion as
> > > what I had. I am not sure why the QVariantList vs QList have different
> > > fidelity - the one with more fidelity - QList - actually has has less
> > > specificity.
> >
> > Because that's how C++ works.
> >
> > QList is not a type, it's a template. Neither QVariant nor QJsonDocument can
> > know all possible QList instantiations. So they have coded only a few
> > (QVariantList and QStringList only, possibly QVector and
> > QVector in Qt 5 too, I don't remember).
>
> I guess our system could detect QList as QVariantList and
> QList as QStringList. They should be binary identical anyway.

That is what I was expecting. I thought they were just a typedef? (Though I am 
lying there, I know QStringList inherits from QList) The instant case 
of QList is just a typedef though, so I am confused as why it wasn't 
working. I thought typedefs were indistinguishable?  The expressiveness of 
C++11 initializers of creating objects that end up in CBOR and JSON for I/O, 
and QVariant based trees (incl arrays) for in-app databases is just awesome. 
But then you get someone wielding C++ clumsily like me. :-)


I attempted to summarize and filed https://bugreports.qt.io/browse/QTBUG-94371


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

Re: [Interest] QJsonDocument::fromVariant failing with list

[Jason H]

 


Yeah, in coming up with a minimal example, I was a little too far from my example, but it all holds. My actual code was this:

QList letters {
                       {{"a",1}},
   {{"b",2}},
                       {{"c",3}}
};

but can be modified to:

 

QVariantList letters {
                        QVariantMap {{"a",1}},
    QVariantMap {{"b",2}},
    QVariantMap {{"c",3}}
 };


 

In which case it works.

 

But I typed out (here)

    QList letters {
    QVariantMap {{"a",1}},
    QVariantMap {{"b",2}},
    QVariantMap {{"c",3}}
    };

 

Which is neiher what I acually had but performs the same bad conversion as what I had. I am not sure why the QVariantList vs QList have different fidelity  - the one with more fidelity - QList - actually has has less specificity.

 


Sent: Tuesday, June 08, 2021 at 4:42 PM
From: "Jérôme Godbout" 
To: "Jason H" , "interestqt-project.org" 
Subject: Re: [Interest] QJsonDocument::fromVariant failing with list




Most likely the QJson doesn’t known what to do with your QList<> type object. You should put those object into a QVariantList, right now you have a QVariantList that contain a QList as first element. You should convert the Qlist to a QVariant (not sure you want 2 level deep array, but right now you do). You QList and QVariantList is QList.

 

Right now if it could do something with the QList you would get this:

{"err":null,"letters":[[{"a": 1},{"b": 2},{"c": 3}]]}

 

Something like this, not sure this is possible declaration but you are looking to get this in the end. Or make a converter that convert your QList to a QVariantList if you still need that QList absolutely.

 

QVariantList letters {
    QVariantMap {{"a",1}},
    QVariantMap {{"b",2}},
    QVariantMap {{"c",3}}
    };

 

Not tested just giving the idea

// can use traits if T is QVariant to simply convert by casting since it’s the same

Template

QVariantList Convert(const QList& l)

{

    QVariantList rv;

    Rv.reserve(l.size());

    for(auto i in l)

    {

    rv.append(QVariant::fromValue(i));

}

return rv;

}

 

 


From: Interest  on behalf of Jason H 
Date: Tuesday, June 8, 2021 at 4:23 PM
To: interestqt-project.org 
Subject: [Interest] QJsonDocument::fromVariant failing with list



I'm having trouble with QJsonDocument::fromVariant() is not handling arrays:

    QVariant list;

    QList letters {
    QVariantMap {{"a",1}},
    QVariantMap {{"b",2}},
    QVariantMap {{"c",3}}
    };

    list.setValue(letters);
    map["err"] = QVariant(); // null
    map["letters"] = list;

    qDebug() << QJsonDocument::fromVariant(map)
    .toJson(QJsonDocument::Compact);

Output:
{"err":null,"letters":null}

I'm expecting:
{"err":null,"letters":[{"a": 1},{"b": 2},{"c": 3}]}

The debugger (screenshot attached) sees it. Is this a bug or am I doing it wrong?







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

Re: [Interest] QJsonDocument::fromVariant failing with list

[Jason H]

> Sent: Tuesday, June 08, 2021 at 4:23 PM
> From: "Jason H" 
> To: "interestqt-project.org" 
> Subject: [Interest] QJsonDocument::fromVariant failing with list
>
> I'm having trouble with QJsonDocument::fromVariant() is not handling arrays:
>
>   QVariant list;
>
>   QList letters {
>   QVariantMap {{"a",1}},
>   QVariantMap {{"b",2}},
>   QVariantMap {{"c",3}}
>   };
>
>   list.setValue(letters);
>   map["err"] = QVariant(); // null
>   map["letters"] = list;
>
>   qDebug() << QJsonDocument::fromVariant(map)
>   .toJson(QJsonDocument::Compact);
>
> Output:
> {"err":null,"letters":null}
>
> I'm expecting:
> {"err":null,"letters":[{"a": 1},{"b": 2},{"c": 3}]}


So it looks like it works with:
QList letters {...}
It seems like QList vs QList should have the same 
behavior as each other?



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

[Interest] QJsonDocument::fromVariant failing with list

[Jason H]

I'm having trouble with QJsonDocument::fromVariant() is not handling arrays:

QVariant list;

QList letters {
QVariantMap {{"a",1}},
QVariantMap {{"b",2}},
QVariantMap {{"c",3}}
};

list.setValue(letters);
map["err"] = QVariant(); // null
map["letters"] = list;

qDebug() << QJsonDocument::fromVariant(map)
.toJson(QJsonDocument::Compact);

Output:
{"err":null,"letters":null}

I'm expecting:
{"err":null,"letters":[{"a": 1},{"b": 2},{"c": 3}]}

The debugger (screenshot attached) sees it. Is this a bug or am I doing it 
wrong?___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] is it possible to add C# compiler?

[Jason H]

> Sent: Monday, June 07, 2021 at 7:48 AM
> From: "David Skoland" 
> To: "David M. Cotter" 
> Cc: "Qt Interest" 
> Subject: Re: [Interest] is it possible to add C# compiler?
>
> Hi,
> 
> Generally, no. I believe the reason you can compile Objective C on MacOS with 
> Qt is clang’s ability to link ObjC to C++ libraries (Qt). I haven’t heard of 
> MSVC or any other compiler which can do the same with C#, which might already 
> be tricky since C# isn’t typically compiled to native assembly.
> 
> > On 5 Jun 2021, at 20:07, David M. Cotter  wrote:
> > 
> > I just saw a message go by about someone adding another compiler to Qt 
> > Creator?
> > 
> > I know that Qt Creator can compile Objective C on mac.
> > 
> > Made me wonder if it could be possible to add a compiler for C# on windows?
> > 
> > Or is that already there and i don't know about it?
> > 
> > -dave

C# (and any other .NET assembly) can be interacted with using the CLR Handle 
type ('^' vs C's '*'), which gives the necessary indirection for the .NET 
GC(compaction) to function.

However as stated, Mixed-languge files (ObC/C++, ending in .mm) are unique, For 
the .NET CLR, it's one language, on compiler per file, so you'll still have C# 
and cpp files, just those .cpp files can have ^ in them.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QML MenuBar : works with PySide2 but not c++ ?

[Jason H]

Why? QML elements are capitalized. They must be. 

the only exception is js imports: import "app.js" as App

 

 
 

Sent: Thursday, June 03, 2021 at 4:10 AM
From: "Frank Mertens" 
To: interest@qt-project.org
Subject: Re: [Interest] QML MenuBar : works with PySide2 but not c++ ?

Try a lowercase file name, e.g.: "qrc:/menuBar.qml".

;)
 

On 03.06.21 06:08, Nicholas Yue wrote:



I copied the qml loading code from another working example, I was just testing a change in the QML content.

 

I'd have to dig further about the lambda

 
MenuBar.pro

===
QT += quick

CONFIG += c++11

# The following define makes your compiler emit warnings if you use
# any Qt feature that has been marked deprecated (the exact warnings
# depend on your compiler). Refer to the documentation for the
# deprecated API to know how to port your code away from it.
DEFINES += QT_DEPRECATED_WARNINGS

# You can also make your code fail to compile if it uses deprecated APIs.
# In order to do so, uncomment the following line.
# You can also select to disable deprecated APIs only up to a certain version of Qt.
#DEFINES += QT_DISABLE_DEPRECATED_BEFORE=0x06    # disables all the APIs deprecated before Qt 6.0.0

SOURCES += \
        main.cpp

RESOURCES += main.qrc

# Additional import path used to resolve QML modules in Qt Creator's code model
QML_IMPORT_PATH =

# Additional import path used to resolve QML modules just for Qt Quick Designer
QML_DESIGNER_IMPORT_PATH =

# Default rules for deployment.
qnx: target.path = /tmp/$${TARGET}/bin
else: unix:!android: target.path = /opt/$${TARGET}/bin
!isEmpty(target.path): INSTALLS += target

main.qrc

===  

    
        MenuBar.qml
    

 

 


On Wed, 2 Jun 2021 at 20:36, Tony Rietwyk  wrote:



Hi Nicholas,

The short answer is because your C++ is doing completely different things to the python code.  :O)

I'm not sure about using QML.  Have you included the qml file as a resource correctly to access via qrc:?  You aren't checking the result of the engine.load.  Also, why is the lambda exiting the application when the objectCreated matches the url?

Have run the Qt QML examples?  How is your C++ code different to those?

Hope that helps, Tony

 

On 3/06/2021 11:33 am, Nicholas Yue wrote:


Hi,
 

  I am learning about QML.

 

  I would like to find out why the PySide2 loading of the QML file results in a visible window but the C++ one does not. The compiled application runs but no window is displayed.

MenuBar.qml
===
import QtQuick 2.4
import QtQuick.Controls 2.13

ApplicationWindow {
    visible: true
    width: 720
    height: 480
    title: "simple window"

    menuBar: MenuBar{
        Menu{
            title: "Menu1"
        }

        Menu{
            title: "Menu2"
        }

        Menu{
            title: ""
        }
    }
}

main.cpp

#include 
#include 

int main(int argc, char *argv[])
{
    QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling);

    QGuiApplication app(argc, argv);

    QQmlApplicationEngine engine;
    const QUrl url(QStringLiteral("qrc:/MenuBar.qml"));
    QObject::connect(, ::objectCreated,
                     , [url](QObject *obj, const QUrl ) {
        if (!obj && url == objUrl)
            QCoreApplication::exit(-1);
    }, Qt::QueuedConnection);
    engine.load(url);

    return app.exec();
}

main.py
===
import sys
from PySide2 import QtCore, QtGui, QtQml

if __name__ == '__main__':

    QtCore.QCoreApplication.setAttribute(QtCore.Qt.AA_EnableHighDpiScaling)
    app = QtGui.QGuiApplication(sys.argv)

    engine = QtQml.QQmlApplicationEngine()

    url = "">
    engine.load(url)
    if not engine.rootObjects():
        sys.exit(-1)

    sys.exit(app.exec_())
 
--


Nicholas Yue
Graphics - Arnold, Alembic, RenderMan, OpenGL, HDF5
Custom Dev - C++ porting, OSX, Linux, Windows
http://au.linkedin.com/in/nicholasyue
https://vimeo.com/channels/naiadtools



 

 

___
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

 

 
--


Nicholas Yue
Graphics - Arnold, Alembic, RenderMan, OpenGL, HDF5
Custom Dev - C++ porting, OSX, Linux, Windows
http://au.linkedin.com/in/nicholasyue
https://vimeo.com/channels/naiadtools

 

 

___
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] QNetworkReply lambdas?

[Jason H]

After playing with this for the day, here's what I got:

// Application code


    struct FileResource {
        QString endpoint;
        QString sql;
        std::function func;
    };

    QList fileResources = {
        {
            "images",
            "SELECT filename FROM images WHERE synced is NULL ORDER BY created ASC",
            [=] (QNetworkReply* reply, QString filename){
                if (reply->error() == QNetworkReply::NoError) {
                    update("images",
                        {{"synced", QDateTime::currentDateTime()}},
                        {{"filename",filename}});
                }
            }
        }
    };


    for (const auto& resource : fileResources) {
        QSqlQuery rows(resource.sql);
        while(rows.next()) {
            remoteCloud->synchronousPostFile(remoteCloud, resource.endpoint,
                                             {rows.value("filename").toString()},
                                             resource.func);
        }
    }


 

// Library code:


void RemoteCloud::synchronousPostFile(RemoteCloud *remoteCloud, const QString& endpoint,
                    const QStringList& filenames,
                    std::function lambda) {
    QEventLoop loop;

    for (const auto& filename: filenames) {
        QFile *file = new QFile(filename);
        if (file->open(QIODevice::ReadOnly)) {
            m_filePointers[filename] = file;
            QNetworkReply * reply = remoteCloud->post(endpoint, mimeFromFilename(filename), file);
            QObject::connect(reply, ::finished, , ::quit);
            QObject::connect(reply, ::finished, reply, [=]{
                lambda(reply, filename);
                QFile *file = m_filePointers[filename];
                if (m_filePointers.remove(filename)) {
                    file->close();
                    file->deleteLater();
                }
                reply->deleteLater();
            });
            loop.exec(); // wait for finished
        } else {
            qWarning() << Q_FUNC_INFO << "could not open" << filename;
            delete file;
        }
    }
}

 

 

Which, because i call the lambda, I can make sure reply always gets deleted. You can call deleteLater() as many times as you want.  



Sent: Wednesday, June 02, 2021 at 11:16 AM
From: "Jérôme Godbout" 
To: "Jason H" , "interestqt-project.org" 
Subject: Re: [Interest] QNetworkReply lambdas?




Hi, might help, this won’t answer you question directly but might give some helper idea to ease the pain. What we did is a wrapper around QNetworkAccessManager class call RequestManager that own a QNetworkManager. It expose the following methods:

 

QNetworkReply* postRequest(QNetworkRequest& request, const QByteArray& payload);

// Do the same for put, update, get…

 

And signal slots:

signals:

    void replySuccess(QNetworkReply* reply);

    void replyError(QNetworkReply* reply);

 

public slots:

    void handleFinished(QNetworkReply *networkReply);

 

It manage the return code immediate and signal then valide the answer is a success or a failure. You can store the context or object into a map with your request, the reply will have the request into it so you can load back the needed information when you receive the replySuccess or reply Error signals back.  Make some helper to convert you payload to QByteArray so you can use it with json, text, etc…

 

I also made some ScopeAction class so my NetworkAccess manager reply handler can make sure the delete later is not forgetten:

 

connect(_manager, ::finished, this, ::handleFinished);

 

 

void RequestManager::handleFinished(QNetworkReply *networkReply)

{

    ScopeAction action_delete([&](){ networkReply->deleteLater(); });

… // process the reply error or success here and emit either the replySuccess or replyError signal here, this need to be non queued connection to avoid bad object access.

}

 

This helped me a lot to clean my network management for upper layer. So I can simply connect to the reply success or replyError and with the request pointer form the reply you can load the associated data and continue form that point easily.

 

The async/await would be nice, but I’m not sure this would play well with the Qt event loop and the object memory management. They are also super hard to debug the call stack is lost.

 



Jérôme Godbout, B. Ing.


Software / Firmware Team Lead
O: (418) 682-3636 ext.: 114  

C: (581) 777-0050 
godbo...@dimonoff.com



dimonoff.com

1015 Avenue Wilfrid-Pelletier, 

Québec, QC G1W 0C4, 4e étage



 

 


From: Interest  on behalf of Jason H 
Date: Wednesday, June 2, 2021 at 10:41 AM
To: interestqt-project.org 
Subject: [Interest] QNetworkReply lambdas?



I'm trying to figure out a more flexible way to do QNetworkReply. Ideally this would be through some async/await

Re: [Interest] QNetworkReply lambdas?

[Jason H]

 


Yeah, we're both convergently evolving to the same thing. :-) I've used a similar approach to yours in the past with the success and fail handlers (just in JS though). I don't know that my current attempt will be superior.

 

If I were you... I would try with a variation of what I proposed (assuming we figure it out):

 

QNetworkReply* postRequest(QNetworkRequest& request, const QByteArray& payload, std::function successHandler, std::function failHandler);

 

rm->postRequest(req, payload, [](QNetworkReply *reply) { // success

        qDebug() << "joy" << req << *reply;

    },


    [](QNetworkReply *reply) { // fail

        qDebug() << "sad" << req << reply;

    }

);


 

 

Which, I debated but thought that 

 


rm->postRequest(req, payload, [req](QNetworkReply *reply) {

    if ( reply->error() == QNetworkReply::NoError)

        qDebug() << "joy" << req << *reply;

    else


        qDebug() << "sad" << req << *reply;

    

);

 

was marginally more readable, and having them defined seperately didn't add anything, but you can supply a default fail handler a little cleaner. 

 

 


rm->postRequest(req, payload, [](QNetworkReply *reply) { // success

        qDebug() << "joy" << req << *reply;

    },


    defaultFailHandler

);



 

 

 



Sent: Wednesday, June 02, 2021 at 11:16 AM
From: "Jérôme Godbout" 
To: "Jason H" , "interestqt-project.org" 
Subject: Re: [Interest] QNetworkReply lambdas?




Hi, might help, this won’t answer you question directly but might give some helper idea to ease the pain. What we did is a wrapper around QNetworkAccessManager class call RequestManager that own a QNetworkManager. It expose the following methods:

 

QNetworkReply* postRequest(QNetworkRequest& request, const QByteArray& payload);

// Do the same for put, update, get…

 

And signal slots:

signals:

    void replySuccess(QNetworkReply* reply);

    void replyError(QNetworkReply* reply);

 

public slots:

    void handleFinished(QNetworkReply *networkReply);

 

It manage the return code immediate and signal then valide the answer is a success or a failure. You can store the context or object into a map with your request, the reply will have the request into it so you can load back the needed information when you receive the replySuccess or reply Error signals back.  Make some helper to convert you payload to QByteArray so you can use it with json, text, etc…

 

I also made some ScopeAction class so my NetworkAccess manager reply handler can make sure the delete later is not forgetten:

 

connect(_manager, ::finished, this, ::handleFinished);

 

 

void RequestManager::handleFinished(QNetworkReply *networkReply)

{

    ScopeAction action_delete([&](){ networkReply->deleteLater(); });

… // process the reply error or success here and emit either the replySuccess or replyError signal here, this need to be non queued connection to avoid bad object access.

}

 

This helped me a lot to clean my network management for upper layer. So I can simply connect to the reply success or replyError and with the request pointer form the reply you can load the associated data and continue form that point easily.

 

The async/await would be nice, but I’m not sure this would play well with the Qt event loop and the object memory management. They are also super hard to debug the call stack is lost.

 



Jérôme Godbout, B. Ing.


Software / Firmware Team Lead
O: (418) 682-3636 ext.: 114  

C: (581) 777-0050 
godbo...@dimonoff.com



dimonoff.com

1015 Avenue Wilfrid-Pelletier, 

Québec, QC G1W 0C4, 4e étage



 

 


From: Interest  on behalf of Jason H 
Date: Wednesday, June 2, 2021 at 10:41 AM
To: interestqt-project.org 
Subject: [Interest] QNetworkReply lambdas?



I'm trying to figure out a more flexible way to do QNetworkReply. Ideally this would be through some async/await but I don't think Qt is "there" yet. (C++20 defines async/await, but there is not a library yet, and even Qt6 doesn't target C++20). So the callback lambda handler looks like the best option for now.

I have a QObject derived class, with a post() function. It takes an endpoint, and object (to be converted to JSON) and a lambda. Example:
remoteCloud->post("/login", credentials, [=](QNetworkReply* reply){
    if (reply->error() == QNetworkReply::NoError) {
    update("cartridge",
   {{"synced", QDateTime::currentDateTime()}},
   {{"cartridgeId", map["cartridgeId"]}});
    }
    reply->deleteLater();
});

With an implementation of:
template
QNetworkReply *RemoteCloud::post(const QString& endpoint, const QVariantMap& item, F ) {
    QNetworkReply* reply = m_nam.post(QNetworkReque

[Interest] QNetworkReply lambdas?

[Jason H]

I'm trying to figure out a more flexible way to do QNetworkReply. Ideally this 
would be through some async/await but I don't think Qt is "there" yet. (C++20 
defines async/await, but there is not a library yet, and even Qt6 doesn't 
target C++20). So the callback lambda handler looks like the best option for 
now.

I have a QObject derived class, with a post() function. It takes an endpoint, 
and object (to be converted to JSON) and a lambda. Example:
remoteCloud->post("/login", credentials, [=](QNetworkReply* reply){
if (reply->error() == QNetworkReply::NoError) {
update("cartridge",
   {{"synced", QDateTime::currentDateTime()}},
   {{"cartridgeId", map["cartridgeId"]}});
}
reply->deleteLater();
});

With an implementation of:
template
QNetworkReply *RemoteCloud::post(const QString& endpoint, const QVariantMap& 
item, F ) {
QNetworkReply* reply = m_nam.post(QNetworkRequest(endpoint), 
JSON(item));
connect(reply, ::finished, lambda);
return reply;
}


Note that a lot of the Qt examples use a connect statement like this:
connect(reply, ::finished, [request, reply](){ ... });

But when I tried to set this up, I either got static assert errors or l-value 
errors.

However I am trying to go one better and have my RemoteCloud::post set up the 
connect with the lambda. Is this possible?

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

Re: [Interest] Can't JSON.stringify an object in QML

[Jason H]

> Sent: Tuesday, June 01, 2021 at 9:22 PM
> From: "Tony Rietwyk" 
> To: interest@qt-project.org
> Subject: Re: [Interest] Can't JSON.stringify an object in QML
>
> HI Jason,
>
> I'm pretty sure this is NOT valid JSON:
>
>{"that": "other": {} }
>
> Either the value and comma for "that" is missing, or "other": {} should


Ok, so I was typing that as an example, and meant to type:
{"that": {"other": {} } }
In that I was trying to illustrate an empty object (which may or may not be 
valid JSON)... but it works with Qt's QJsonDocument::toJson()




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

Re: [Interest] Can't JSON.stringify an object in QML

[Jason H]

> Some JSON serialisers replace that with null nowadays.
> 
> I guess you could write some code to test whether it’s cyclical
> and at which elements it recurses. If you feel not up to it,
> write back and I’ll try (ECMAscript is not a language I feel
> comfortable in either but I think I could manage).


Well, if it were cyclical (I really don't think it is),  I would expect that 
the line: 
return QJsonDocument::fromVariant(v).toJson(QJsonDocument::Compact);

Would never return. However it does, and it gives me the exact string I would 
expect.
So I'm still at a loss there.


The object does contain an empty object, could that be it? For example:
{"that": "other": {} }




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

[Interest] Can't JSON.stringify an object in QML

[Jason H]

I've got a really weird error:
qml: type: object [DEBUG-12344567890,N]
qrc:/screens/Result.qml:32: TypeError: Type error

The statements are:
console.log("type:", typeof App.result, Object.keys(App.result)) // this works
console.log("result:", JSON.stringify(App.result)); // this does not

App is an import (`import "app.js" as App`)
result is s simple JS Object: var result = { "DEBUG-12344567890": {...},"N": { 
... } };

Is it possible to figure out why the stringification is failing? How could it 
even fail?
Better yet, can it fail with a better error. or are we locked into some 
terrible Javascript standard?

I added a C++ function to print it out, but the contents are as I expect.

QString Wtf::stringify(const QJSValue ) const {
QVariant v = var.toVariant();
return QJsonDocument::fromVariant(v).toJson(QJsonDocument::Compact); // 
works
}

Any idea why that console.log is failing?




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

Re: [Interest] WASM build Error: Bad relocation type

[Jason H]

> However I blew away the build dir and did a full rebuild now and got:
> wasm-ld: error: initial memory too small, 21088512 bytes needed
>
> Command line contains: "--initial-memory=16777216 --no-entry 
> --global-base=1024"
>
> Progress! :-) How do I change the memory setting [in QtCreator]? According to 
> something I read on the internet,
> wasm {
>   QMAKE_TOTAL_MEMORY=21233664
> }
>
> Should fix it. But the commandline --inital-memory didn't change. Help?



Ok Success, kinda. It crashes.

Firat: Fixing the inital memory error:

wasm {
QMAKE_TOTAL_MEMORY=21495808 # ignored for some reason
QMAKE_LFLAGS += -s TOTAL_MEMORY=21495808
}

Then, when QtCreator attempts to start the page:
 /bin/sh /Users/jason/Projects/emsdk/upstream/emscripten/emrun --browser chrome 
--port 3 --no_emrun_detect --serve_after_close 
/Users/jason/Projects/poc-ui-Qt_5_15_1_WebAssembly-Debug/poc-ui.html
from: can't read /var/mail/tools
/Users/jason/Projects/emsdk/upstream/emscripten/emrun: line 9: syntax error 
near unexpected token `__file__'
/Users/jason/Projects/emsdk/upstream/emscripten/emrun: line 9: `  
python_selector.run(__file__)'

However, this confuses python (and me). Removing the /bin/sh from the QtCreator 
command line (at a console)gets it to start and load the page.
Leaving the /bin/sh in, gets you that `from: can't read /var/mail/tools`, 
because it is interpreting the python code as a shell script.

Being on Mac, I wondered if it was a zsh issue, but running a bash shell then 
the QtCreator command line, I get the same result.

Changing the "effective run call" in QtC did not help





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

Re: [Interest] WASM build Error: Bad relocation type

[Jason H]

> Ah see, you have to read the fine print: https://doc.qt.io/qt-5/wasm.html is 
> the authoritative documentation. I made that clearer on the wiki now; 
> apologies for the confusion.
> 
> fastcomp (the older fork-of-llvm compiler) is long since history, except if 
> you are using an older version of Qt and want to match the emsdk version Qt 
> was developed with. If you are using Qt 5.15 then emsdk 1.39.8 the 
> recommended version.
> 
> I’m not sure what’s going on with the “bad relocation” error, I would try 
> upgrading to emsdk 1.39.8 first.


Despite the rumors to the contrary, I can follow directions. :-)

jason@Jasons-MacBook-Pro emsdk % ./emsdk install 1.39.8
Installing SDK 
'sdk-releases-upstream-9e60f34accb4627d7358223862a7e74291886ab6-64bit'..
Skipped installing node-14.15.5-64bit, already installed.
Skipped installing python-3.9.2-1-64bit, already installed.
Skipped installing 
releases-upstream-9e60f34accb4627d7358223862a7e74291886ab6-64bit, already 
installed.
All SDK components already installed: 
'sdk-releases-upstream-9e60f34accb4627d7358223862a7e74291886ab6-64bit'.
jason@Jasons-MacBook-Pro emsdk % ./emsdk activate --embedded 1.39.8
embedded mode is now the only mode available
Setting the following tools as active:
   node-14.15.5-64bit
   python-3.9.2-1-64bit
   releases-upstream-9e60f34accb4627d7358223862a7e74291886ab6-64bit

Next steps:
- To conveniently access emsdk tools from the command line,
  consider adding the following directories to your PATH:
/Users/jason/Projects/emsdk
/Users/jason/Projects/emsdk/node/14.15.5_64bit/bin
/Users/jason/Projects/emsdk/upstream/emscripten
- This can be done for the current shell by running:
source "/Users/jason/Projects/emsdk/emsdk_env.sh"
- Configure emsdk in your bash profile by running:
echo 'source "/Users/jason/Projects/emsdk/emsdk_env.sh"' >> 
$HOME/.bash_profile


However I blew away the build dir and did a full rebuild now and got:
wasm-ld: error: initial memory too small, 21088512 bytes needed

Command line contains: "--initial-memory=16777216 --no-entry --global-base=1024"

Progress! :-) How do I change the memory setting [in QtCreator]? According to 
something I read on the internet, 
wasm {
QMAKE_TOTAL_MEMORY=21233664
}

Should fix it. But the commandline --inital-memory didn't change. Help?



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

Re: [Interest] WASM build Error: Bad relocation type

[Jason H]

> I have retried with:
> `./emsdk activate sdk-fastcomp-1.38.27-64bit`

> I'll keep looking into this.

So, It's a bit confusing why fastcomp is mentioned, if it isn't supported?

Anyway, I can't get past the
wasm-ld: error: test-ui.js_qml_plugin_import.o: Bad relocation type:
shared:ERROR: '...'

message. I know it's not your message (it's wasm-ld's)  but that import.o is 
generated by Qt.

I wonder if it has to do with the way I am using QML_ELEMENT imports?



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

Re: [Interest] WASM build Error: Bad relocation type

[Jason H]

> > I'm not sure what to do no >
> > I made sure I activated the right version (per 
> > https://wiki.qt.io/Qt_for_WebAssembly) (1.39.8)
>
>
> I just tested an empty qml swipe app on my mac, and is working for me.
>
> When you activated this, did you include the --embedded argument to emsdk?
> If so, this is incompatible with QtCreator.

Yea, because that was the instruction:
`./emsdk activate --embedded sdk-fastcomp-1.38.27-64bit or (was) 
sdk-1.38.16-64bit`

However, I parsed that statement as:
`./emsdk activate --embedded [sdk-fastcomp-1.38.27-64bit | sdk-1.38.16-64bit ]`

So what I executed was:
`./emsdk activate --embedded sdk-fastcomp-1.38.27-64bit`

I have retried with:
`./emsdk activate sdk-fastcomp-1.38.27-64bit`

And got a new errors, however these are regarding QtMultimedia classes, so this 
is expected. I #ifndef'ed around them, and got the same relocation error.  The 
files in the build dir are:
ASCII text
HTML document text, ASCII text
JSON data
Qt C-code resource file, ASCII text
SVG Scalable Vector Graphics image
WebAssembly (wasm) binary module version 0x1 (MVP)
c program text, ASCII text
makefile script text, ASCII text, with very long lines

I'll keep looking into this.


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

[Interest] Idea: QML Text source property?

[Jason H]

I wanted to post a thought I had about adopting a source property approach for 
text-ish things (Text, TextEdit, Text*) as well as images. Currently, images 
support a source property, which can be routed to a remote url, local file, 
compiled resource, or QQuickImageProvider.

I think it could be argued that there could be a use case for text to have a 
similar source scheme as well.  Example:
Text {
   source: "https://qt.io/eula;
   source: "sqlite://query?queryparams"
}

Reading is simple, writing a little more complicated. The "QQuickTextProvider" 
provider would have to provide a setter in addition to getter and might have to 
have a notifier signal.

Currently, yes, all this could be done by just having a QObject with exposed 
properties and binding the Text.text property to the object property. BUT I'm 
working on model where I want to be able to reuse the UI. And to do it, I want 
to specify:
Repeater {
  model : [
{"label": "First name", "source": "provider://"+rowid+"?first"},
{"label": "Last name", "source": "provider://"+rowid+"?last"}
  ]
  Column {
Text {text: model[index].label}
TextEdit {text: model[index].source}
  }
}

But the gist is that the value being bound to is provided /as data/. I think it 
would be really useful to have this level of indirection.
Yeah, SQLLite doesn't support 
LISTEN(https://www.postgresql.org/docs/9.0/sql-listen.html), but I'd expect the 
provider to implement the notification internally, through whatever means 
necessary.


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

[Interest] WASM build Error: Bad relocation type

[Jason H]

I was giving QtC 4.15 a spin today and saw the prompt for WebAssembly. It had 
been a while since I last tried it and wanted to check it out again. I 
configured it, adjusted my project, but errored during build at:

wasm-ld: error: test-ui.js_qml_plugin_import.o: Bad relocation type:
shared:ERROR: '/Users/jason/Projects/emsdk/upstream/bin/wasm-ld -o 
/var/folders/sp/2twrspnd5tz9w2m09nldl0yrgp/T/emscripten_temp_mzJVeK/test-ui.wasm
 [snipped command]'

`file test-ui.js_qml_plugin_import.o` gives:
test-ui.js_plugin_import.o: WebAssembly (wasm) binary module version 0x1 (MVP)

I'm not sure what to do now.

I made sure I activated the right version (per 
https://wiki.qt.io/Qt_for_WebAssembly) (1.39.8)




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

Re: [Interest] Android build fails with "Could not determine java version from '11.0.8'" error

[Jason H]

Your java is too new. In QtCreator, click the globe in the Devices pane:
  JDK Location > [...] [Choose] [globe] 
and select OpenJDK 8.



> Sent: Wednesday, May 19, 2021 at 2:40 PM
> From: "Alexander Dyagilev" 
> To: "Qt Project" 
> Subject: [Interest] Android build fails with "Could not determine java 
> version from '11.0.8'" error
>
> Hello,
> 
> My project builds fine on my old laptop (Qt Creator 4.15.0 + Qt 5.12.10).
> 
> I'm setting up development environment on my new laptop.
> 
> Just installed Android Studio + Qt Creator + Qt 5.12.10.
> 
> All Android settings are fine in Qt Creator (as it reports).
> 
> However, androiddeployqt.exe fails with this strange error. Any help, 
> please? :)
> 
> 21:33:10: Starting: 
> "C:\Work\Qt\5.12.10\android_armv7\bin\androiddeployqt.exe" --input 
> C:/Work/Source/build-fdm-Android_Qt_5_12_10_Clang_armeabi_v7a-Debug/ui/android-libfdm.so-deployment-settings.json
>  
> --output 
> C:/Work/Source/build-fdm-Android_Qt_5_12_10_Clang_armeabi_v7a-Debug/android-build
>  
> --android-platform android-30 --jdk "C:/Program Files/Android/Android 
> Studio/jre" --gradle
> Generating Android Package
>    Input file: 
> C:/Work/Source/build-fdm-Android_Qt_5_12_10_Clang_armeabi_v7a-Debug/ui/android-libfdm.so-deployment-settings.json
>    Output directory: 
> C:/Work/Source/build-fdm-Android_Qt_5_12_10_Clang_armeabi_v7a-Debug/android-build/
>    Application binary: 
> C:/Work/Source/build-fdm-Android_Qt_5_12_10_Clang_armeabi_v7a-Debug/bin/libfdm.so
>    Android build platform: android-30
>    Install to device: No
> 
> FAILURE: Build failed with an exception.
> 
> * What went wrong:
> Could not determine java version from '11.0.8'.
> 
> ___
> 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 Singleton and QTimer?

[Jason H]

> Sent: Monday, May 10, 2021 at 3:08 AM
> From: "Ulf Hermann" 
> To: interest@qt-project.org
> Subject: Re: [Interest] QML Singleton and QTimer?
>
> Hi,
>
> > GuiApplication::GuiApplication(int argc, char*argv[]):
> > QGuiApplication::QGuiApplication(argc, argv)
> > {
> > m_hardwareInterface = new HardwareInterface;
> > qmlRegisterSingletonInstance("com.company", 1, 0, "HardwareInterface", 
> > m_hardwareInterface);
> > }
>
> qmlRegisterSingletonInstance() is dangerous if you create your singleton
> in a different thread than the one the QML engine runs on. The QML
> engine expects to be able fiddle with internals of those objects via the
> metaobject system.
>
> It also does surprising things when you have multiple QML engines: The
> first one to access it grabs the objects and all others only see null.
>
> It also does not play ball with qmlRegisterTypesAndRevisions() the way I
> had intended. You cannot register an instance before the type because
> the type will then get rejected. You also cannot register an instance
> after the type because there is no way to hook into the type
> registration procedure without providing some kind of callback. If you
> could provide a callback, then that would be pretty much the same as
> providing a factory function, though.
>
> The whole qmlRegisterSingletonInstance() was a mistake, sorry about
> that. It's too easy to shoot yourself in the foot with it and there is
> no way to make its type visible at compile time. You should really use
> the QML_SINGLETON macro and let the QML engine handle the life cycle of
> the object. The QML engine will make sure to create and destroy it on
> the right thread. qmlRegisterSingletonInstance() will be deprecated
> before Qt 7.

It definitely seems that way! I hope this can be added to the documentation to
avoid other people going down this path? I was eager to finally use it, as it
would have simplified things on my side. But it looks like it is a difficult
thing to wield properly.


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

Re: [Interest] QML Singleton and QTimer?

[Jason H]

Well, the documentation gives the example of the singleton being instantiated at the main.cpp:main() level.

 

It felt a little wrong, but I subclassed QGuiApplication, and created and registered the singleton there:


GuiApplication::GuiApplication(int argc, char*argv[]):
	QGuiApplication::QGuiApplication(argc, argv)
{
	m_hardwareInterface = new HardwareInterface;
	qmlRegisterSingletonInstance("com.company", 1, 0, "HardwareInterface", m_hardwareInterface);
}

 

This seems to work, but seemed unnatural.

 


 

 

 

 
 

Sent: Thursday, May 06, 2021 at 5:42 PM
From: "Jérôme Godbout" 
To: "Jason H" , "interestqt-project.org" 
Subject: Re: [Interest] QML Singleton and QTimer?




You can check the thread affinity of an object and the current thread that will display the problem you encounter. Use a queued signal into the QTimer thread to sent the start (it will be delayed until the thread process the event, hopefully you do no need precision there).

 



Jérôme Godbout, B. Ing.


Software / Firmware Team Lead
O: (418) 682-3636 ext.: 114  

C: (581) 777-0050 
godbo...@dimonoff.com



dimonoff.com

1015 Avenue Wilfrid-Pelletier, 

Québec, QC G1W 0C4, 4e étage



 

 


From: Interest  on behalf of Jason H 
Date: Thursday, May 6, 2021 at 5:34 PM
To: interestqt-project.org 
Subject: [Interest] QML Singleton and QTimer?



I'm trying to have a simple singleton class, but it doesn't appear that I can use timers?


HardwareInterface::HardwareInterface(QObject *parent) : QObject(parent)
{
    m_timer = new QTimer(this);

    connect(m_timer, ::timeout, this, [=](){
    qDebug() << Q_FUNC_INFO;
    });

    m_timer->start(100); // QObject::startTimer: Timers can only be used with threads started with QThread

}

main.cpp: int main() {
...
qmlRegisterSingletonInstance("com.company.example", 1, 0, "HardwareInterface", );
...

How do we go about using timers in singletons?

___
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] QML Singleton and QTimer?

[Jason H]

I'm trying to have a simple singleton class, but it doesn't appear that I can 
use timers?


HardwareInterface::HardwareInterface(QObject *parent) : QObject(parent)
{
m_timer = new QTimer(this);

connect(m_timer, ::timeout, this, [=](){
qDebug() << Q_FUNC_INFO;
});

m_timer->start(100); // QObject::startTimer: Timers can only be used 
with threads started with QThread

}

main.cpp: int main() {
...
qmlRegisterSingletonInstance("com.company.example", 1, 0, "HardwareInterface", 
);
...

How do we go about using timers in singletons?

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

[Interest] Windows-64 specific QML UI flickering

[Jason H]

I use mainly Mac and Android and I don't see these issues, however the Windows 
64 experience is very crunchy. I was asked to make a simple serial port 
monitor. I developed on my mac. It's solid.
It's got QML UI using Rows, Columns, Text, TextEdits (Controls v2), and a 
ComboBox (Controls v2) for selecting the serial port.

However, I've tried it on 2 HP laptops:
- The first shows triangular artifacts, like a GL triangle is glitching, but 
the triangle is very acute, and fleeting.

- The other one doesn't glitch with the triangle, it redraws the background 
then draws on top of it (as it should). But here's the crazy thing, it's got a 
rhythm like a heart beat like .|.|;.|.|; where the | indicate the text 
fields disappearing, reappearing. (so in one cycle the controls flicker twice 
with a short pause between them, and. along pose separating them) One cycle is 
on the order of about 2 seconds.

Nothing in the UI falls into this pattern.  The serial port stuff is async.

How do I fix this?


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

Re: [Interest] Another Qt disappointment

[Jason H]

And me as well. 

 

At what point is Qt no longer considered open source? As someone who has been using Qt professionaly since 3.3.3, I have a hard time considering it 'Open Source" anymore. It's basically the most closed opensource project I know of. While I have not really contibuted to the project in terms of lines of code(I've been maonly a bug reporter) and multiple commercial licensee, I am now leery to do so beccause it's basically be free work for Digia, which they wll probably just change the license on later, anyway. At one time I would have loved to worked on Qt for my job, but not anymore. 

 

Qt reached the pinnacle of openess when Nokia LGPL'd it, and it's been downhill ever since. 

 

The continued screw-tightening by Digia makes Qt harder for me to use even in my own personal, non-distributed, non commercial projects. 

 

I do think Qt is technically great but the behavior of Digia makes the product unattractive. 

 

I don't know how they can justify the change to commercial providing of a LTS release. That's just blantaly evil/bad/whatever. I don't know how they can sleep at night. 

 

IMHO, Digia will continue to inconvenience users to the point of forcing them to use git repos only, not realizing that every other open source project makes it trivial to use with their own package manager (npm, pip, etc).  (Sorry if that gave them ideas, but they would have iterated to that eventually)

 

I wonder if any of the engineers are pushing back internally?

 

 
 

Sent: Tuesday, May 04, 2021 at 9:53 AM
From: "Bob Hood" 
To: interest@qt-project.org
Subject: Re: [Interest] Another Qt disappointment

On 5/3/2021 8:44 AM, Jason H wrote:

I have a load cell. It's a sensor that measures weight. I wanted to make a quick UI for it in Qt.
That went as expected. Then I wanted to put the app on a spare Amazon Fire tablet rather than tie up a computer with it.

I was running with Qt 5.15.2, but there's. bug with Bearer in Qt 5.15.2, so I went to update it, and lo and behold, there is no 5.15.3. It's apparently, commercial-only. So I figured I'd finally update to Qt 6, except that after installing, it turns out Qt 6.0 doesn't have androidextras.

It's not just me that is disappointed, everyone in the comments at https://www.qt.io/blog/commercial-lts-qt-5.15.3-released seems disappointed that 5.15.3 is commercial-only.

So as I sit here waiting for Qt 6 and Qt 5.15 to uninstall, and Qt 5.12 to install, I figured that I'd drop this note about how things are going the wrong way.


I believe the post in early January (titled "Qt 5.15 pull out of open source?!") made a similar observation, and served as the snowball which ended with the late unpleasantness.

Let's be real: It was a blatantly stupid decision to cut off open source support within the production 5.15 line.  Compound that with some of the licensing decisions made with Qt6, and it leaves me, both personally and professionally, with a distrust of TQC's road map for Qt.  I'm hesitant now to base any software designs on it because of this new baggage.
___ 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] L Word

[Jason H]

The problem isn't Qt, it's not dashboards or medical. It's all about how you mitigate the risk.

 

I think Qt is fine for dashboards and medical, if the risks are properly managed. I think it is ok that a desktop app does not have the same risk profile as a medical device. What is important from a Qt sales/usage perspective is that you can construct a solution that includes Qt AND mitigates the risks. People ARE using Qt for dashbaords and medical. 

 

I think Roland was big a bit hyperbolic there, but his point was correct that recent decicions of QtCo make Qt less attractive. 

 

 
 

Sent: Monday, May 03, 2021 at 11:23 AM
From: eric.fedosej...@gmail.com
To: "'Benjamin TERRIER'" , "'Bob Hood'" 
Cc: "'Qt Interest'" 
Subject: Re: [Interest] L Word




I find this whole argument that Qt is not appropriate for functional safety very puzzling. Aren’t vehicle dashboards QtC’s main market these days? What are vehicle dashboards if not safety critical?

 

If Qt is no longer appropriate for embedded medical devices, why is it still appropriate for vehicle dashboards?

 


From: Interest  On Behalf Of Benjamin TERRIER
Sent: Thursday, April 29, 2021 11:27 AM
To: Bob Hood 
Cc: Qt Interest 
Subject: Re: [Interest] L Word


 



 


 



On Thu, 29 Apr 2021 at 15:15, Bob Hood  wrote:




On 4/29/2021 4:02 AM, Bernhard Lindner wrote:
 


Obviously, Qt has nothing to do with this type of software engineering. And it's obviously

not suitable for functional safety (at least not if you take it seriously).



If this statement is true and Roland's statement that TQC actively courted that industry is also true, then it seems to me that he has a valid grievance, regardless of how he presents it.




 



TQC actively courted that industry, but it does not mean that they intended Qt to be part of the functional safety stack.



As a proof to my above statement I bring you the Qt Safe Renderer. It is a commercial product from TQC targeted to functional safety industry, so yes TQC has courted this industry.



However, it also means that Qt itself was never meant to be a part of the functional safety stack and is not supposed to mess with it.



The issue at hand here is not that Roland has a valid grievance or not. At least some of the issues he raised are valid.



The issue is that his emails are numerous and have a very low signal/noise ratio, that he is borderline insulting to anyone who is out of his industry and that in the end it lowers the value users are getting from this mailing list.



And personally I'd add that he is so badly advocating for his grievance that I'd prefer him not to advocate for the points where I agree with him.




___ 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] Another Qt disappointment

[Jason H]

I have a load cell. It's a sensor that measures weight. I wanted to make a 
quick UI for it in Qt.
That went as expected. Then I wanted to put the app on a spare Amazon Fire 
tablet rather than tie up a computer with it.

I was running with Qt 5.15.2, but there's. bug with Bearer in Qt 5.15.2, so I 
went to update it, and lo and behold, there is no 5.15.3. It's apparently, 
commercial-only. So I figured I'd finally update to Qt 6, except that after 
installing, it turns out Qt 6.0 doesn't have androidextras.

It's not just me that is disappointed, everyone in the comments at 
https://www.qt.io/blog/commercial-lts-qt-5.15.3-released seems disappointed 
that 5.15.3 is commercial-only.

So as I sit here waiting for Qt 6 and Qt 5.15 to uninstall, and Qt 5.12 to 
install, I figured that I'd drop this note about how things are going the wrong 
way.






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

[Interest] Online Windows Installer DLL dependency

[Jason H]

For anyone who may find it useful, the Qt online windows installer needs the
"MS Visual C++ 2015-2016 Redistributable (x86)"
installed, even though it is on a x64 system. The (x64) version will not work.


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

Re: [Interest] L Word

[Jason H]

Not to Jeffery specifically,

 

I have mixed feelings about the whole situation. I think Roland is right, or at least has a valid point most of the time, even if it is technical or limited to a specific use case. However his speech is often hyperbolic, absolutust, and not really tolerant of any other opinion. 

 

I think licensing, project direction, and other "soft" discussions ARE appropriate for "qt-interest" mailing list. I don't think the hyperbole is appropriate though.  

 

Maybe the answer is another mailing list, "qt-offtopic" or whatever, and we can say that such hyperbole is appropriate there, but not here. I do appreciate the comments that for people looking for a dense, tenchical resource, the hyperbole is diluting. 

 

I hope Giuseppe comes back. He's been fantastic. 

 

Personally, I don't understand why if he hates it so much he participates the way he does? It seems like ge's mobing away from Qt on his own? I suspect that he probably won't return after the ban.

 




Sent: Friday, April 30, 2021 at 10:12 AM
From: "Jeffrey Brendecke" 
To: interest@qt-project.org
Subject: Re: [Interest] L Word


I, too, am one of those list lurkers looking for interesting information and discussions on Qt, but all too often I instead see posts from one unpleasant person repeatedly dominating discussions with belligerent, non-productive rantings. I wonder why he even uses Qt or even spends time thinking about it.
 

Given that there is at least one large development company in the US making money off using Qt on medical devices, among others, I think that this one difficult person is definitely not the sole fountain of knowledge on the subject and should not be given more credence than necessary. If Qt has short-comings in the medical device realm, constructive discussion would bring more than infantile rants. He would have done better to convince the Qt Company to hire him on as a consultant to improve their technology for use on medical devices, as that seems to be something the company wants to be successful in. Instead, I would not want to go anywhere near the guy

 

I have experienced Giuseppe D'Angelo as a fabulous, caring instructor and am sorry to see him leave this discussion. All of us are the poorer because of it.

 

If any person's postings on this list (or really in any context) are causing excellent contributors like Giuseppe to leave, then that is a very good indication that that person needs to be removed from the list.

 

Jeffrey

 

-
 

On Apr 29, 2021, at 21:30, Rui Oliveira  wrote:
 


And so we lost one of the most active, contributing, and knowledgeable members of this mailing list. 

Cue "the worst trade deal maybe ever signed anywhere" meme. 

I was thinking of putting him in CC but I don't think I should bother the man. 

I sure did respect Giuseppe, and I can totally get behind his no-BS personality.

With wishes of talking about code again,
Rui

Às 09:22 de 29/04/2021, Giuseppe D'Angelo via Interest escreveu:

On 29/04/2021 00:42, Giuseppe D'Angelo via Interest wrote: 

If the answer is yes, you were lying. If the answer is no, or you don't 
answer, then you're trolling the mailing list. You'll get my apology; 
I'll even throw in, for free, my personal congratulations for the long 
trolling. But, you'll get a nice permanent ban from here. 

No reply. Yes, you're not the only one who can set arbitrary deadlines for other people, pal. 


I'll just go with the script then: you DID believe those links to be true. 

Then, please accept my deepest and most sincere apologies for calling you a liar. 

I'll state it again, very clearly, all uppercase: 

YOU NEVER LIED. I WAS WRONG. 

Please accept the attached fruit basket as a gesture of good will. 

=== 

Where does this leave us, then? 

At BEST, you have been trolling the mailing list, sending inflammatory false content with the purpose of getting a strong reaction from the participants. 

At WORST, you have demonstrated some abysmal gross incompetence, since in order to win an argument you: 

* googled some keywords; 
* got the first couple of links that seemed to match your thesis; 
* didn't even bother to read the contents; 
* pasted the links here believing they were true, without questioning the veracity of such explosive statements; 
* when busted, dug your hole even deeper by keeping arguing in that direction. 

(...I'm not alone about bringing this possibility forward...) 

Spoiler alert, the links were April fools' jokes. They have never been true, and it was even written in the articles that they were jokes. With such precedents, why should anyone believe *any* other argument you bring forward? 

=== 

In either case, it is abundantly clear who's full of shit around here. 

It is also clear to me that moderation on this list doesn't exist, or if it exists, it doesn't want to get sides, and/or considers these behaviours acceptable. 

I don't. And I don't send ultimatums or threats of libel 

Re: [Interest] Svar: Qt permanently broke on computer

[Jason H]

Good news everybody, I have partialyl figured it out, but I hope you can help me further.

 


MYPROJ = ../phidget-spinner
win32 {
INCLUDEPATH +=$$MYPROJ/libraries/phidget22-windevel/lib/c
#this works:
LIBS +=-L$$PWD/../phidget-spinner/libraries/phidget22-windevel/lib/c/x64 -lphidget22
#these breaks Qt (each):
   LIBS +=-L$$MYPROJ/libraries/phidget22-windevel/lib/c/x64 -lphidget22
   LIBS +=-L"$${MYPROJ}/libraries/phidget22-windevel/lib/c/x64" -lphidget22
   LIBS +=-L$${MYPROJ}/libraries/phidget22-windevel/lib/c/x64 -lphidget22

}


message("PWD")
message($${PWD})
message("MYPROJ")
message($$MYPROJ)
message("INCLUDEPATH")
message($${INCLUDEPATH})
message("LIBS")
message($${LIBS})

 

Working:

Project MESSAGE: PWD
Project MESSAGE: C:/Users/Admin/phidget-spinner
Project MESSAGE: MYPROJ
Project MESSAGE: ../phidget-spinner
Project MESSAGE: INCLUDEPATH
Project MESSAGE: ../phidget-spinner/libraries/phidget22-windevel/lib/c
Project MESSAGE: LIBS
Project MESSAGE: -LC:/Users/Admin/phidget-spinner/../phidget-spinner/libraries/phidget22-windevel/lib/c/x64 -lphidget22

 

Now working:

Project MESSAGE: PWD
Project MESSAGE: C:/Users/Admin/phidget-spinner
Project MESSAGE: MYPROJ
Project MESSAGE: ../phidget-spinner
Project MESSAGE: INCLUDEPATH
Project MESSAGE: ../phidget-spinner/libraries/phidget22-windevel/lib/c
Project MESSAGE: LIBS
Project MESSAGE: -L../phidget-spinner/libraries/phidget22-windevel/lib/c/x64 -lphidget22

 

 



Not sure why $$MYPROJ works for INCLUDEPATH but breaks the linker? If the link path is wrong I would expect it to fail the build, bot break Qt?

 

 


 
 

Sent: Monday, April 26, 2021 at 2:47 PM
From: "Andy Shaw" 
To: "Jérôme Godbout" , "Jason H" 
Cc: "interestqt-project.org" 
Subject: Svar: [Interest] Qt permanently broke on computer




What is also useful to check is to set QT_DEBUG_PLUGINS=1 as your environment variable, it can tell you where it is looking for the plugin then. Maybe it finds a qt.conf file and it is influencing the paths incorrectly there.

 

Andy

 


Fra: Interest  på vegne av Jérôme Godbout 
Dato: mandag, 26. april 2021 kl. 19:33
Til: Jason H 
Kopi: interestqt-project.org 
Emne: Re: [Interest] Qt permanently broke on computer


You might try to delete the .user files for the project and clean the build folder manually (erase the whole folder). Check the project config to spot any differences there. If some project work with the same Qt version, the Qt install is probably good. Make sure all you dependencies are ok.

 

 


From: Interest  on behalf of Jason H 
Date: Monday, April 26, 2021 at 11:11 AM
To: Jason H 
Cc: interestqt-project.org 
Subject: Re: [Interest] Qt permanently broke on computer





> Sent: Monday, April 26, 2021 at 11:01 AM
> From: "Jason H" 
> To: "Jason H" 
> Cc: "interestqt-project.org" 
> Subject: Re: [Interest] Qt permanently broke on computer
>
> > I tried to port an app on a Win10 PC. That went well. Then I tried to deploy (windeployqt) it.
> >
> > Now when I run it in creator I get:
> > 10:26:28: Starting C:\Users\Admin\Projects\build-phidget-spinner-Desktop_Qt_5_15_2_MinGW_64_bit-Debug\debug\phidget-spinner.exe ...
> > qt.qpa.plugin: Could not find the Qt platform plugin "windows" in ""
> >
> > I have deleted the C:\Qt dir and re-installed.
> > I have cleaned the app source dir and deleted the shadow build dirs, deleted the .pro.user file,
> > I launched QtC from the start menu.
> >
> > I have no idea how to get this working again.
>
> Some additional info:
> Other projects work.
> The crash is in this statement:
> QGuiApplication app(argc, argv);
>
> the stack indicates a crash starting at:
> QGuiApplicationPrivate::createPlatformIntegration()
>
>
> All the online help (stackexchange) seems to be about deployment, but I'm just trying to run it in creator.

Update #2:

The same thing happens on a totaly new computer, never had qt on it before, installed Qt, copied the source and built it, some error.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest







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

Re: [Interest] Qt permanently broke on computer

[Jason H]

> Sent: Monday, April 26, 2021 at 11:01 AM
> From: "Jason H" 
> To: "Jason H" 
> Cc: "interestqt-project.org" 
> Subject: Re: [Interest] Qt permanently broke on computer
>
> > I tried to port an app on a Win10 PC. That went well. Then I tried to 
> > deploy (windeployqt) it.
> >
> > Now when I run it in creator I get:
> > 10:26:28: Starting 
> > C:\Users\Admin\Projects\build-phidget-spinner-Desktop_Qt_5_15_2_MinGW_64_bit-Debug\debug\phidget-spinner.exe
> >  ...
> > qt.qpa.plugin: Could not find the Qt platform plugin "windows" in ""
> >
> > I have deleted the C:\Qt dir and re-installed.
> > I have cleaned the app source dir and deleted the shadow build dirs, 
> > deleted the .pro.user file,
> > I launched QtC from the start menu.
> >
> > I have no idea how to get this working again.
>
> Some additional info:
> Other projects work.
> The crash is in this statement:
> QGuiApplication app(argc, argv);
>
> the stack indicates a crash starting at:
> QGuiApplicationPrivate::createPlatformIntegration()
>
>
> All the online help (stackexchange) seems to be about deployment, but I'm 
> just trying to run it in creator.

Update #2:

The same thing happens on a totaly new computer, never had qt on it before, 
installed Qt, copied the source and built it, some error.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt permanently broke on computer

[Jason H]

> I tried to port an app on a Win10 PC. That went well. Then I tried to deploy 
> (windeployqt) it.
>
> Now when I run it in creator I get:
> 10:26:28: Starting 
> C:\Users\Admin\Projects\build-phidget-spinner-Desktop_Qt_5_15_2_MinGW_64_bit-Debug\debug\phidget-spinner.exe
>  ...
> qt.qpa.plugin: Could not find the Qt platform plugin "windows" in ""
>
> I have deleted the C:\Qt dir and re-installed.
> I have cleaned the app source dir and deleted the shadow build dirs, deleted 
> the .pro.user file,
> I launched QtC from the start menu.
>
> I have no idea how to get this working again.

Some additional info:
Other projects work.
The crash is in this statement:
QGuiApplication app(argc, argv);

the stack indicates a crash starting at:
QGuiApplicationPrivate::createPlatformIntegration()


All the online help (stackexchange) seems to be about deployment, but I'm just 
trying to run it in creator.

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

[Interest] Qt permanently broke on computer

[Jason H]

I tried to port an app on a Win10 PC. That went well. Then I tried to deploy 
(windeployqt) it.

Now when I run it in creator I get:
10:26:28: Starting 
C:\Users\Admin\Projects\build-phidget-spinner-Desktop_Qt_5_15_2_MinGW_64_bit-Debug\debug\phidget-spinner.exe
 ...
qt.qpa.plugin: Could not find the Qt platform plugin "windows" in ""

I have deleted the C:\Qt dir and re-installed.
I have cleaned the app source dir and deleted the shadow build dirs, deleted 
the .pro.user file,
I launched QtC from the start menu.

I have no idea how to get this working again.

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

Re: [Interest] Guide me through the Qt offerings for GUIs

[Jason H]

I highly recommend using QHttpServer or QWebSocketServer to create a backend for your application. You can then have web clients target your logic, swap your server for some other tech Node.JS, etc) or serve local and Qt/WebGL UIs. It forces you into that paradigm. The Websocket version plays a bit better with async. updates though.

 

 

 

 




Sent: Thursday, April 22, 2021 at 11:25 AM
From: "Konstantin Shegunov" 
To: "Rui Oliveira" 
Cc: "Interests Qt" 
Subject: Re: [Interest] Guide me through the Qt offerings for GUIs



On Thu, Apr 22, 2021 at 6:10 PM Rui Oliveira  wrote:




Basically we're coupling the whole backend to the GUI framework.



You always have some coupling between the logic and the GUI, no matter what you use, but I do get the gist.  



I'd prefer to write C++ than to learn Loaders and whatever else there is... But seems that people do love QML a lot (again, shouts out to KDE).



Funny that you mentione the `Loader`, which is sort of no-op item from the C++/desktop dev perspective. What I mean by that is that the `Loader` is the archetype of the 'QML engine is really a glorified object factory', which I mentioned. The only reason it is there is to delay the creation of a QtQuick item. This would've been rather trivial to do in a C++ environment, you just create and add the object to the scene whenever it's needed, no need to wrap this in a `QObject`, but not so trivial to do if you want to leverage it in a 'declarative' (or rather JS) context. Note that the component doesn't go away too, because at some point you may want to unload said scene item, which instead of just deleting, being the obvious choice, you set the relevant property to the loader, which detaches it from the scene.



Opinions, I guess.



I don't see anything wrong with that, as long as we have a civil discussion (not a troll fest) about it.


___ 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] Guide me through the Qt offerings for GUIs

[Jason H]

> On 4/23/2021 5:00 AM, Frank Mertens wrote:
> > All the latency and texture loading concerns actually go away when using 
> > software rendering.
> > For the embedded world just make sure you have a good low-latency memory 
> > block.
> > (I had good experiences with IMX6ULs...!-)
>
> Thank you for your feedback.
>
> An IMX6 on battery?
>
> The hardware guys on the projects I've been on tend to compare IMX6
> power consumption to a V8 engine with dual quad carbs gas consumption.
> I've only ever used one on a system connected to grid power.
>
> Every other embedded system I've been on has really poor dynamic memory
> because the hardware group is trimming power consumption every place
> they can. It's no biggie. One just has to design software differently.

You really are in a different world, Roland. *g*

With love,

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

Re: [Interest] Guide me through the Qt offerings for GUIs

[Jason H]

If you are *so* resouce constrained, use LVGL. You're probably not using 15MB Qt llibraries anyway, and they would take too long load anyway.

 

 

 
 

Sent: Thursday, April 22, 2021 at 1:35 PM
From: "Roland Hughes" 
To: eric.fedosej...@gmail.com, "'Vlad Stelmahovsky'" 
Cc: "'interest'" 
Subject: Re: [Interest] Guide me through the Qt offerings for GUIs


 

On 4/22/21 8:15 AM, eric.fedosej...@gmail.com wrote:



From: Interest  On Behalf Of Volker Hilsheimer
Sent: Thursday, April 22, 2021 8:24 AM
We currently have no specific plans to make QWidget render through RHI, and neither the video nor my earlier emails suggest that this is on the roadmap. It generally makes very little sense to draw with a pen into a freshly wiped out Vulkan surface > 60 times per second.



Why are QWidgets not rendering almost everything directly from texture? Except when styles are changed, there should almost never be a need to blit a widget. There is nothing intrinsic about widgets (vs. quick controls) that requires them to be blitted onto a freshly wiped surface 60 times per second, only inertia and a lack of desire to make any improvements to the widget backend in over a decade.




Just a point of interest.

That work of art UI I posted a link to earlier had no GPU. This is common in the embedded world when people are pushing for days (not minutes) of battery life. We pre-loaded all our images, did our own caching, and blitted everything.

When this conversation talks about QML performance in the embedded world it is talking about that subset of the embedded world which splurges for GPU.

--
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
___ 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] Guide me through the Qt offerings for GUIs

[Jason H]

> Sent: Thursday, April 22, 2021 at 4:50 AM
> From: "Volker Hilsheimer" 
> To: "Bernhard Lindner" 
> Cc: "interest@qt-project.org" 
> Subject: Re: [Interest] Guide me through the Qt offerings for GUIs
>
> > On 21 Apr 2021, at 22:39, Bernhard Lindner  
> > wrote:
> > 
> > 
> >> Personally, I think the exsting QtQuick element should be scrapped and 
> >> just focus on QML
> >> versions of the existing Widget functionality. I love the QML syntax, hate 
> >> that it's not
> >> just a layer on top of widgets.
> > 
> > +100
> > 
> > Why this wasn't done from the start is one of the hardest puzzles! I ask 
> > myself this
> > question every time I read the three letters "QML" :-) 
> 
> 
> Indeed, it’s an obvious knee-jerk reaction to have when looking at Qt and 
> wondering why there are several UI frameworks.
> 
> But there are several reasons why things are as they are. Some of them:
> 
> * imperative painting
> 
> Paint-event based drawing with a “pen” is not easily reconcilable with how 
> GPUs like to work. Without a persistent scene graph that is uploaded to the 
> GPU, much of the performance you get from a GPU is lost. An animation at 
> 60fps is ideally just a draw call on the GPU with some different 
> transformations, not a completely new upload of a completely reconstructed 
> scene graph for each frame.
> 
> Widgets can draw into a framebuffer texture that can be used, and that allows 
> for some integration, but that doesn’t give you great performance.
> 
> 
> * integer coordinates and clipping
> 
> Widgets work with integer coordinates, which starts to be problematic now 
> that we have high-DPI displays. And widgets clip are clipped to their parent 
> geometry, which was the right choice for those UIs, but is very limiting and 
> requires a lot of complex code to solve conceptually simple problems. Hello 
> macOS focus ring.
> Quick items do not clip and are not clipped, which gives a lot more freedom 
> in how shapes are combined and structured.
> 

The painting problem I understand, and as I understand it, the biggest reason 
for the break?. It's different world. But Integer coordinates don't seem like 
such a big deal.

> * declarative vs imperative APIs
> 
> Many widget classes don’t have a declarative-friendly API. Plenty of widget 
> properties have side effects on other properties, so the order in which 
> properties are set matters. That doesn’t work well in a declarative world.
> 

I don't buy this. You can do declarative to imperative mapping. Isn't this what 
the QtQuick compiler does?

> * weight
> 
> Widgets are heavy, often very complex objects. They often come with all bells 
> and whistles. QPushButton always has the data structure to support 
> QPushButton::setMenu, even if probably <1% of buttons out there ever use that 
> feature. That’s ok on desktop machines, it’s not ok on embedded systems.
 

I have a hard time buying this one as well because you've added GL, which 
requires additional hardware. Sure emulate it in software if you dare, but it's 
worse than painting.

> * complexity and hard to customize
>   
> Inheritance and reimplementing are nice concepts on paper and works great if 
> you build your own custom widget from a reasonably abstract base class. But 
> if you have ever tried to subclass e.g. QTreeWidget to modify how certain 
> interactions work, then you know how hard it can be to not break the complex 
> states that the default implementations rely on.

The "inheritance" in QML is outstanding. Super simple and effective.
 
> 
> So, making widgets work in a declarative, GPU friendly world where ease of 
> customisation is more important than standard look’n'feel would have required 
> many changes to widgets. Those would have been impossible to make without 
> invalidating or breaking a lot of code out there, and still not given us the 
> UI components we would have needed.
> 
> I’m sure there are opportunities to share more code between widgets and quick 
> world esp on the UI framework classes, and with Qt 6 we have taken some steps 
> into that direction. But whether the benefits outweigh the risks and effort 
> requires a case-by-case evaluation.

I think that's a false choice. 

Anyway, I hate using QML for any kind of text input because it's so crunchy 
even today. Why do I have to set `selectByMouse: true`? 

I don't understand why the layout system, one of the best, most awesome things 
about old Qt, what make me fall in love with Qt (aside from the clean API), was 
abandoned. I don't see why traditional layouts had to be yeeted even if the 
widgets had to be replaced. The painting issue I get. Sure, thre might be Row 
and Column replacing VericalBoxLayout, HorizontalBoxLayout, etc. But working 
with the replacements (Hey, I like shorter names -less typing-) is a crunchy 
experience. Dealing with childrenRect, implcitWigth/height, etc. New concepts 
that, in a transitional time made the transition harder. QML has not been the 
ideal, it's 12 years 

Re: [Interest] Help a unix guy on windows qmake

[Jason H]

> On Wednesday, 21 April 2021 10:39:01 PDT Giuseppe D'Angelo via Interest wrote:
> > But no $X. I'm still not sure what $PROJ means.
>
> The way the example was given, the string "$PROJ" will be written literally to
> the Makefile. Make will then interpret it as $(P)ROJ, which is likely not what
> you want.
>
> $ gmake -f /dev/stdin <<<'all: ; @echo $PROJ'
> ROJ
> $ gmake -f /dev/stdin P=abc <<<'all: ; @echo $PROJ'
> abcROJ

Thanks for all the help everyone!

One thing I did notice was message($$PWD) worked fine on on one platform but 
not on windows.

I got a message like:
message() requires one argument

I was using:
message($$LIBS)

But Qt is now borke (computer locked not Qt's fault) and I'll re-install it:
Could not find the platform plugin "windows" in ""

But now message($$LIBS) works, so I have no idea what is real anymore.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Help a unix guy on windows qmake

[Jason H]

> Sent: Wednesday, April 21, 2021 at 1:14 PM
> From: "Thiago Macieira" 
> To: interest@qt-project.org
> Subject: Re: [Interest] Help a unix guy on windows qmake
>
> On Wednesday, 21 April 2021 09:54:09 PDT Jason H wrote:
> > Now, when compiling, regardless of shadow build or not, refer to the libs by
> > adding to the project: +++ project.pro
> > + mingw {
> > + INCLUDEPATH += $PROJ/libraries/win/include
> > + LIBS += -L$PROJ/libraries/win/$ARCH -lvendor
> > + }
> >
> > It seems that $PWD ${PWD} or whatever ($${PWD}?) refer to the build dir, be
> > it shadow or not. I don't want to copy the libraries to the shadow dir in
> > QMAKE_PRE_LINK because they *never* change.
>
> You're mixing environment variables and qmake variables. Qmake variables
> always start with a double dollar sign and are expanded by qmake when it
> writes the Makefile output. You can see their value with message().
>
> qmake does not expand environment variables at all.
>
> $ X=A qmake Y=b /dev/stdin -o /dev/null <<<'message(r = $X $$Y)'
> Project MESSAGE: r = $X b
>
> The environment variables are written as-is to your Makefile. It's up to you
> to write something that make will understand.
>
> $PROJ is not a valid environment variable expansion in Make.


Right. I used $PROJ for illustrative purposes. I guess the flaw in my thinking
is that when the shadow build is made, that there is some way to reference the
original location( other than ../project_name

Maybe all I need is:
PROJ=../project

Thank you for example. Very enlightening.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Help a unix guy on windows qmake

[Jason H]

> Sent: Wednesday, April 21, 2021 at 12:04 PM
> From: "Giuseppe D'Angelo via Interest" 
> To: interest@qt-project.org
> Subject: Re: [Interest] Help a unix guy on windows qmake
>
> On 21/04/2021 17:49, Jason H wrote:
> > What is the proper scope? Allegedly these are listed in 
> > C:\Qt\$ver\$compiler\mkspecs, however there are no win64 ones. I'm using 
> > mingw.
>
> mingw is the proper scope. When in doubt, look at Qt's own sources.
>
> > src/angle/src/libEGL/libEGL.pro
> > 19:mingw:equals(QT_ARCH, i386): DEF_FILE = 
> > $$ANGLE_DIR/src/libEGL/$${DEF_FILE_TARGET}_mingw32.def
> >
> > src/angle/src/libGLESv2/libGLESv2.pro
> > 9:mingw: equals(QT_ARCH, i386): DEF_FILE = 
> > $$ANGLE_DIR/src/libGLESv2/$${DEF_FILE_TARGET}_mingw32.def

MinGW is not x64? It's running on a fairly recent windows 10 machine.

> > Why is there no $PROJ variable for linking when shadow building?
> > $PWD resolves to the shadow build dir, it seems?
> > How do I properly refer LIBS to $PROJ/libraries/x64/mylib.lib?
> > How do I properly refer INCLUDEPATH to $PROJ/libraries/mylib.h?
> > You know what $PROJ means, but for some reason this concept doesn't exist 
> > in qmake yet?
>
> I... don't quite know what $PROJ means *for you*? :)
>
> Do you mean $$OUT_PWD? Do you mean $$shadowed($$PWD)?

% git clone project
% cd project
% export PROj=`pwd` # this is where I want to start the path for the .pro 
options below.
% mkdir $PROJ/libraries/win. ## developed on linux, add new platform: windows
% cp -r C:/blah/Vendor/win $PROJ/libraries/win ## copy vendor libraries
% git add .
% git commit -m "Add windows libraries"
% git push

Now, when compiling, regardless of shadow build or not, refer to the libs by 
adding to the project:
+++ project.pro
+ mingw {
+ INCLUDEPATH += $PROJ/libraries/win/include
+ LIBS += -L$PROJ/libraries/win/$ARCH -lvendor
+ }

It seems that $PWD ${PWD} or whatever ($${PWD}?) refer to the build dir, be it 
shadow or not. I don't want to copy the libraries
to the shadow dir in QMAKE_PRE_LINK because they *never* change.





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

Re: [Interest] Guide me through the Qt offerings for GUIs

[Jason H]

> On 21/04/2021 17:42, Jason H wrote:
> > Personally, I think the exsting QtQuick element should be scrapped and
> > just focus on QML versions of the existing Widget functionality. I love
> > the QML syntax, hate that it's not just a layer on top of widgets.
> > That said, I still really like both.
>
> Do you mean something like this
>
> https://github.com/KDAB/DeclarativeWidgets
>
> or actually reimplementing the widgets themselves?

There's a couple things going on here:
1. API
2. UI

Ideally the API should be widgets, the UI should be Quick.

* Making a library where QGraphicsProxyWidget seems like a right choice. (UI)
* I believe that there was some recent talk at reimplementing Qt Quick Controls 
with
  proper theming via 
https://api.kde.org/frameworks/qqc2-desktop-style/html/index.html
  also seems like a right (UI)
* The DeclarativeWidgets seems like what Qt should have done from the 
beginning. (API) (?)
  But... is not using QtQuick rendering. (Also there should be gallery!) 
"Declarative Widgets
allows you to use Qt Widgets with QML, but it does not use Qt Quick. 
Declarative Widgets is
still using the Qt Widgets rendering and wrapping platform native 
components under the hood,
whilst Qt Quick uses OpenGL for rendering (a software renderer is now 
available) and you had
to build your UI from basic components. Qt Quick Controls provide standard 
controls for Qt Quick."

And then there's https://github.com/uwerat/qskinny, kinda related but not.

It's a shame that the DeclarativeWidgets requires a supplemental commercial 
license (or GPL).
And looking up the commercial license cost is "contact sales" which means it's 
too expensive.
The motivation for use is "I rather the old API" but the interest level does 
not rise
to the level of "contacting sales". If it were transparently prices at the 
price of a
developer tool ($40-60) I could splurge. Think a Qt Marketplace offering?



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

[Interest] Help a unix guy on windows qmake

[Jason H]

I'm having a bugger of a time getting a project working under windows. I've 
been doit under mac and linux for the last many years.
What is the proper scope? Allegedly these are listed in 
C:\Qt\$ver\$compiler\mkspecs, however there are no win64 ones. I'm using mingw.

Why is there no $PROJ variable for linking when shadow building?
$PWD resolves to the shadow build dir, it seems?
How do I properly refer LIBS to $PROJ/libraries/x64/mylib.lib?
How do I properly refer INCLUDEPATH to $PROJ/libraries/mylib.h?
You know what $PROJ means, but for some reason this concept doesn't exist in 
qmake yet?







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

Re: [Interest] Guide me through the Qt offerings for GUIs

[Jason H]

You probably won't  -- it's too new. Unless you call automotive Infotainment consoles success stories.

The lack of proper QtQuick Controls (v2) held it back for a while.

 

Personally, I think the exsting QtQuick element should be scrapped and just focus on QML versions of the existing Widget functionality. I love the QML syntax, hate that it's not just a layer on top of widgets.

That said, I still really like both.

 

 




Sent: Wednesday, April 21, 2021 at 10:19 AM
From: eric.fedosej...@gmail.com
To: "'Jérôme Godbout'" , interest@qt-project.org
Subject: Re: [Interest] Guide me through the Qt offerings for GUIs




I took another look at the showcase and am still having trouble finding any substantial desktop application built with QML.

 

Desktops may now be a niche corner of the market, but they are still where most productivity occurs. Software is still being actively developed and sold for desktops and there remains a demand for a cross-platform desktop GUI solution.

 

Can QML be that solution? I am not sure because I cannot find any examples.

 



From: Jérôme Godbout 
Sent: Wednesday, April 21, 2021 9:23 AM
To: eric.fedosej...@gmail.com; interest@qt-project.org
Subject: Re: [Interest] Guide me through the Qt offerings for GUIs



 

You might want to give the showroom a look, some of them are Qml based:

https://showroom.qt.io/

 

Some use the Felgo layer:

https://felgo.com/resources/success-stories

 

http://en.esotericsoftware.com/forum/Facial-Animation-in-Qml-and-pushing-past-the-Spine-limits-3788

http://en.esotericsoftware.com/spine-runtimes#Qt%2FQML

 

 

https://opsensmedical.com/products/optomonitor/

https://www.kdab.com/development-resources/videos-webinars/demo-videos/

 

https://www.learnpyqt.com/examples/

 

Note: this is a personal point of view, strongly opinion ahead from that point

 

as for the Desktop application, the line is blurring more and more everyday (iPad and surface pro are good example that “desktop” is no more like it used to be for most people). The workstation is more for a specific corner case now a day. I would not limit myself to a few platforms, mobile and desktop are becoming a mix bag and removing platform is a bad future choice I think. I never liked the “native” look and feel, I prefer my user to be in my app feel across platform instead, they don’t get lost when using it on mobile, Mac OS or Windows… it doesn’t matter. Facebook, messenger, Google application, Apple application all tends to be this way too. The OS is just a low level tool/helper in the end, the actual work is made inside your application, the end user often care very little about the OS, as long as they can find and launch their app and do their stuff easily.

 



Jérôme Godbout, B. Ing.


Software / Firmware Team Lead
O: (418) 682-3636 ext.: 114  

C: (581) 777-0050 
godbo...@dimonoff.com



dimonoff.com

1015 Avenue Wilfrid-Pelletier, 

Québec, QC G1W 0C4, 4e étage



 

 


From: Interest  on behalf of eric.fedosej...@gmail.com 
Date: Wednesday, April 21, 2021 at 8:37 AM
To: interest@qt-project.org 
Subject: Re: [Interest] Guide me through the Qt offerings for GUIs



Where are the examples of real QML desktop applications on The Qt Co. website? I did a quick walk through the customer showcase and cannot find them.

From: Interest  On Behalf Of Giuseppe D'Angelo via Interest
Sent: Monday, April 19, 2021 8:36 AM

This is false, as a quick walk through the customer showcase on TQC's website will show.

On 18/04/2021 14:50, Roland Hughes wrote:
> I guess QML is more present in embedded? Or maybe some entreprise
> stuff we don't know about...
> Just phones and John Deere.

___
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] Guide me through the Qt offerings for GUIs

[Jason H]

I am ambidextrous when it comes to Quick and Widgets.
If you want it to look modern, use Quick. If you want more business-retro, use 
widgets. Widgets still has better UX, but it is not as bad as it used to be. 

You can do what you want in Quick, with C++ QQuickImageProvider subclass.  It's 
a little head-scratchy at first, but it works well. Using an Image, I pass the 
data in via source property URL and generate the image for that data. (My stuff 
doesn't update frequently, so I send all the data. You'll probably allocate a 
resources and update the data separately)






> Sent: Thursday, April 15, 2021 at 12:25 PM
> From: "Rui Oliveira" 
> To: "Qt Interest" 
> Subject: [Interest] Guide me through the Qt offerings for GUIs
>
> Hey,
> 
> As per the title implies, I would like some comments on the GUI 
> offerings Qt currently has.
> 
> I'll share my own assessments and needs, and I'd like very much to hear 
> your comments.
> 
> So:
> 
> I want to write a desktop application. This desktop application would 
> not involve displaying lists of things, which seems to be what all 
> tutorials/guides/courses are about, especially on the QML side. This 
> application would involve some "custom graphics", namely a FFT display, 
> and a "waterfall" display. You can google for "GQRX" and you'll know 
> what I want.
> 
> 
> And then I looked at Qt, and:
> 
> First thing I have looked at were QWidgets. I feel comfortable staying 
> in the C++ domain. To implement said custom widgets I gave a shot to a 
> class inheriting from QOpenGLWidget. And honestly, the experience wasn't 
> bad at all!
> 
> But, I feel very hesitant to start a project on QWidgets. It feels like 
> starting a project on dead tech. Although, I did watch Giuseppe 
> D’Angelo's talk in Qt Desktop Days 2020 (slides [1] 
> ), 
> and looking at slide 19, there seem to be prospects of evolution. My 
> attention goes especially to "Accelerate widget rendering & compositing 
> through RHI". Will QWidgets really have a RHI backend? And a QRhiWidget 
> option? Or maybe just QWidget and everything HW accelerated? I can dream...
> 
> I know QWidgets are no longer "interesting". Even KDE moved on from 
> them... And I understand that's not where the money is for now... Still, 
> I'd like some comments.
> 
> Now, QML.
> 
> Slide 25 of the same talk mentions native desktop styling for QQC2. I 
> can't find documentations on this. Are they already available yet? Also, 
> in the previous slide, "Planned in Qt 6.x: C++ API for Qt Quick 
> elements". Does this mean Qt Quick *without* QML?
> 
> Also, in QML it seems to be very hard to have anything native-looking. I 
> looked at Qt Labs Platform [2] 
>  and things like the 
> right click menu aren't available on Windows, for example. Are there 
> plans to expand this?
> 
> 
> Either way, I'm quite divided. I'd like to hear your thoughts and 
> recommendations.
> 
> In summary, it would seem that my options for the desktop with Qt are 
> two self-competing technologies: one "half-dead", one "3/4-baked"... I'd 
> really love to be wrong.
> 
> 
> Thank you for your time,
> Rui
> 
> 
> For those reading in plain text:
> [1] https://www.qtdesktopdays.com/wp-content/uploads/2020/09/keynote.pdf
> [2] https://doc.qt.io/qt-6/qtlabsplatform-index.html
> 
> ___
> 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] the path forward

[Jason H]

I've called Qt "top secret rockstar tech" multiple times and I plan on calling it that for a bit more. I've had 5 companies buy licenses since 2005.  Qt has delivered on getting my products to market in record time, even if that was a process frought with far more native code than it should have been. At the very least having a cross-platform UI saved some effort, and provided consistency, rather than having to target Android's stacks AND AVFoundation seperately.

 

What I don't like is the erosion of the LGPL that Nokia set in place. I think it's shortsighted, and contributes to the decline of Qt overall. I feel that while Qt stock has done well, volume is thin, and something as technical as having BSD or LGPL could be beneficial for the volume. Qt is a project of declining hobbiest popularity, even when there are big companies buying into it. Compare it with say, ReactJS/Electron. Everyone knows about that, Qt not so much... Maybe the big player interest will circle back around as it comes up on job postings... I'd personally launch a head on WebGL offensive if I could I think there's a lot of untapped potential there!

 

Also, I think Qt should be on a US stock market, but I am biased. ;-) There's some pink sheets version of Qt stock which is even thinner volume. 

 


 

Sent: Thursday, April 01, 2021 at 9:25 AM
From: "Nuno Santos" 
To: "Turtle Creek Software" 
Cc: interest@qt-project.org
Subject: Re: [Interest] the path forward


I don’t see Roland's emails anymore because I’ve blocked him. He is a kind of hater and lover of Qt at the same time. He loves when someone gives him a spark to set this email list on fire and then write long emails full of bullshit that only someone that has nothing to do has time to read.
 

I use Qt for more than 10 years now. I’ve started my company alone in 2014. Since then I’ve been building 7 products with Qt that I deploy for Windows, Mac, iOS and Android. 

 

I’ve had issues, bugs, but most of them were not show stoppers. When a show stopper bug appears I report it and it usually gets fixed. Some faster, some slower, but every single one had a fix. The last one was fixed in less than a month.

 

My experience with Qt is very good. It has been keeping stability over all this years and I’ve only mostly focused in building products.

 

Has issues? Has! But Apple has issues, Microsoft has issues as every single software company has issues, because software is constantly evolving. 

 

If it wasn’t Qt, I would be here giving this testimonial. It really helped me to do more with less. 

 

Big shout to the Qt Team, keep the awesome work!!!

 

Best regards,





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

Re: [Interest] Software architecture style options

[Jason H]

Last time I tried, it worked, or could work, however concurrency management is left as an excercise to the coder.

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

 





The WebGL doesn’t allow multiple users as far as I known to render the GUI into WebGL (correct me if I’m wrong here I haven’t used it yet, so take this with a grain of salt), but I don’t see that as a solution for multiple simultaneous user into different usage context. I always saw this option as a good configuration view for a device, a config page for a router for example. I’m speculating on this, I haven’t play with it, but my understanding so far: If you would need multiple user you would need to spawn a webgl process per user connected (CGI script or something?!?). And having the business logic into a single process that the webgl GUI process access.




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

Re: [Interest] Software architecture style options

[Jason H]

If not an appropriate question for this list.

But Qt can help with the QML local UI and remote browser WebGL plugin, the 
experimental Qt HTTP server (though I prefer web sockets these days)



> Sent: Wednesday, March 31, 2021 at 8:21 AM
> From: "Megidd Git" 
> To: interest@qt-project.org
> Subject: [Interest] Software architecture style options
>
> Hi everyone,
> 
> Maybe someone can help:
> 
> https://softwareengineering.stackexchange.com/q/424966/176220
> 
> I just need some pointers to guide me in the right direction to explore
> architecture style options.
> 
> Thanks,
> 
> ___
> 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] the path forward - that 7 year thing - was, , willy-nilly

[Jason H]

Tukka, 

I'm open to being wrong, but I just spoke with them. One of us three is 
obviously in error, but I pushed back on the lack of the perpetuity clause, (it 
was present at my last company) and sales was clear, it was removed...

What would really help, is to get this documented out in the open... None of 
this "contact sales for pricing"



> Sent: Sunday, March 28, 2021 at 7:53 PM
> From: "Tuukka Turunen" 
> To: "Jason H" 
> Cc: "Roland Hughes" , "interest@qt-project.org" 
> , "mike.jack...@bluequartz.net" 
> 
> Subject: Re: [Interest] the path forward - that 7 year thing - was, , 
> willy-nilly
>
> 
> Hi Jason,
> 
> Please contact our sales to discuss commercial licensing. Based on the email 
> below you seem to misunderstand the commercial development and distribution 
> licensing at least partially.
> 
> Yours,
> 
> Tuukka
> 
> 
> Lähettäjä: Jason H 
> Lähetetty: sunnuntaina, maaliskuuta 28, 2021 4:52 ip.
> Vastaanottaja: Tuukka Turunen
> Kopio: Roland Hughes; interest@qt-project.org; mike.jack...@bluequartz.net
> Aihe: Re: [Interest] the path forward - that 7 year thing - was, , willy-nilly
> 
> Tukka, you (Digia, aka "QtCo") no longer offer the perpetuity clause of the 
> license. Which is absolutely insane for a commercial customer.  If we are no 
> longer developing that code, we should still be able to "distribute" that 
> code. The revocation of the perpetuity clause in new licenses means we can no 
> longer do that. We aren't even asking for support in perpetuity, just the 
> ability to distribute what we had been...
> 
> The developers at Qt Co need to push back and tell Digia "that's not how this 
> works" before we get to the points of users revolting in threads on the 
> forums / lists. It's a bad look. Anyone investigating Qt would be throughly 
> turned off by now, and I can't say I would blame them.
> 
> It's really sad it's gotten this far. I've been licensing Qt off and on since 
> 2005 and watching it erode this whole time. I still think it's the greatest 
> tech, but the licensing is quickly becoming the limiting factor.  So much so, 
> that I have Qt in consideration at another company, and I am about to pull 
> the plug because the licensing has changed so much.
> 
> At some point the business people have to realize that they are selling to 
> engineers, and this is a much more nuanced field, and this license erosion is 
> noticed.
> 
> Yeah, we noticed when QtPdf license changed:
> https://www.qt.io/blog/2017/01/30/new-qtpdf-qtlabs-module (LGPLv3)
> https://www.qt.io/blog/change-in-open-source-licensing-of-qt-wayland-compositor-qt-application-manager-and-qt-pdf
>  (Tukka's own post)
> https://lists.qt-project.org/pipermail/development/2019-October/037698.html 
> (Not everyone was on board with the license change)
> But it's now under the marketplace license?
> https://marketplace.qt.io/collections/most-popular/products/qtpdf ($49/ 
> Marketplace license)
> 
> 
> Shenannigans. I declare shenannigans.
> 
> Sent: Saturday, March 27, 2021 at 4:23 AM
> From: "Tuukka Turunen" 
> To: "Roland Hughes" , "interest@qt-project.org" 
> , "mike.jack...@bluequartz.net" 
> 
> Subject: Re: [Interest] the path forward - that 7 year thing - was, , 
> willy-nilly
> 
> “When Qt chased these markets it knew what the lifetimes would be. Now it has 
> abandoned them.”
> 
> I would like to point out that this is not a true statement. We do offer long 
> term support and also extended support for those customers who need it. There 
> are some who every now and then still need something related to Qt 3. 
> Somewhere Qt 2 is still in use. Perhaps Qt 1 even, but personally not certain 
> about that. Qt 4 based systems of course and majority of customers are with 
> Qt 5 currently.
> 
> Each of these versions has changed API and we have tried our best to make the 
> transition from Qt 5 to Qt 6 smooth. We are happy to get suggestions and 
> feedback to it still and help in the transition.
> 
> Yours,
> 
> Tuukka
> 
> 
> Lähettäjä: Interest  käyttäjän Roland Hughes 
>  puolesta
> Lähetetty: Friday, March 26, 2021 10:47:34 PM
> Vastaanottaja: interest@qt-project.org ; 
> mike.jack...@bluequartz.net 
> Aihe: Re: [Interest] the path forward - that 7 year thing - was, , willy-nilly
> 
> 
> On 3/26/21 1:39 PM, Michael Jackson wrote:
> >  I'll start off by acknowledging your points, but we will just agree to 
> > disagree. I acknowledge that you have a*lot*  of years making/maintaining 
> > software f

Re: [Interest] the path forward - that 7 year thing - was, , willy-nilly

[Jason H]

I was just in contact with them, and shocked that the perpetual nature was 
removed...

I don't think I'm mistaken. 

> Sent: Sunday, March 28, 2021 at 7:53 PM
> From: "Tuukka Turunen" 
> To: "Jason H" 
> Cc: "Roland Hughes" , "interest@qt-project.org" 
> , "mike.jack...@bluequartz.net" 
> 
> Subject: Re: [Interest] the path forward - that 7 year thing - was, , 
> willy-nilly
>
> 
> Hi Jason,
> 
> Please contact our sales to discuss commercial licensing. Based on the email 
> below you seem to misunderstand the commercial development and distribution 
> licensing at least partially.
> 
> Yours,
> 
> Tuukka
> 
> 
> Lähettäjä: Jason H 
> Lähetetty: sunnuntaina, maaliskuuta 28, 2021 4:52 ip.
> Vastaanottaja: Tuukka Turunen
> Kopio: Roland Hughes; interest@qt-project.org; mike.jack...@bluequartz.net
> Aihe: Re: [Interest] the path forward - that 7 year thing - was, , willy-nilly
> 
> Tukka, you (Digia, aka "QtCo") no longer offer the perpetuity clause of the 
> license. Which is absolutely insane for a commercial customer.  If we are no 
> longer developing that code, we should still be able to "distribute" that 
> code. The revocation of the perpetuity clause in new licenses means we can no 
> longer do that. We aren't even asking for support in perpetuity, just the 
> ability to distribute what we had been...
> 
> The developers at Qt Co need to push back and tell Digia "that's not how this 
> works" before we get to the points of users revolting in threads on the 
> forums / lists. It's a bad look. Anyone investigating Qt would be throughly 
> turned off by now, and I can't say I would blame them.
> 
> It's really sad it's gotten this far. I've been licensing Qt off and on since 
> 2005 and watching it erode this whole time. I still think it's the greatest 
> tech, but the licensing is quickly becoming the limiting factor.  So much so, 
> that I have Qt in consideration at another company, and I am about to pull 
> the plug because the licensing has changed so much.
> 
> At some point the business people have to realize that they are selling to 
> engineers, and this is a much more nuanced field, and this license erosion is 
> noticed.
> 
> Yeah, we noticed when QtPdf license changed:
> https://www.qt.io/blog/2017/01/30/new-qtpdf-qtlabs-module (LGPLv3)
> https://www.qt.io/blog/change-in-open-source-licensing-of-qt-wayland-compositor-qt-application-manager-and-qt-pdf
>  (Tukka's own post)
> https://lists.qt-project.org/pipermail/development/2019-October/037698.html 
> (Not everyone was on board with the license change)
> But it's now under the marketplace license?
> https://marketplace.qt.io/collections/most-popular/products/qtpdf ($49/ 
> Marketplace license)
> 
> 
> Shenannigans. I declare shenannigans.
> 
> Sent: Saturday, March 27, 2021 at 4:23 AM
> From: "Tuukka Turunen" 
> To: "Roland Hughes" , "interest@qt-project.org" 
> , "mike.jack...@bluequartz.net" 
> 
> Subject: Re: [Interest] the path forward - that 7 year thing - was, , 
> willy-nilly
> 
> “When Qt chased these markets it knew what the lifetimes would be. Now it has 
> abandoned them.”
> 
> I would like to point out that this is not a true statement. We do offer long 
> term support and also extended support for those customers who need it. There 
> are some who every now and then still need something related to Qt 3. 
> Somewhere Qt 2 is still in use. Perhaps Qt 1 even, but personally not certain 
> about that. Qt 4 based systems of course and majority of customers are with 
> Qt 5 currently.
> 
> Each of these versions has changed API and we have tried our best to make the 
> transition from Qt 5 to Qt 6 smooth. We are happy to get suggestions and 
> feedback to it still and help in the transition.
> 
> Yours,
> 
> Tuukka
> 
> 
> Lähettäjä: Interest  käyttäjän Roland Hughes 
>  puolesta
> Lähetetty: Friday, March 26, 2021 10:47:34 PM
> Vastaanottaja: interest@qt-project.org ; 
> mike.jack...@bluequartz.net 
> Aihe: Re: [Interest] the path forward - that 7 year thing - was, , willy-nilly
> 
> 
> On 3/26/21 1:39 PM, Michael Jackson wrote:
> >  I'll start off by acknowledging your points, but we will just agree to 
> > disagree. I acknowledge that you have a*lot*  of years making/maintaining 
> > software for medical devices. But I'm with Hamish on this. I don't 
> > understand.
> >
> > What you are saying is that Qt was designed "perfectly" from day one with 
> > no extra API, not one bad API implementation and no 

Re: [Interest] the path forward - that 7 year thing - was, , willy-nilly

[Jason H]

Tukka, you (Digia, aka "QtCo") no longer offer the perpetuity clause of the license. Which is absolutely insane for a commercial customer.  If we are no longer developing that code, we should still be able to "distribute" that code. The revocation of the perpetuity clause in new licenses means we can no longer do that. We aren't even asking for support in perpetuity, just the ability to distribute what we had been...

 

The developers at Qt Co need to push back and tell Digia "that's not how this works" before we get to the points of users revolting in threads on the forums / lists. It's a bad look. Anyone investigating Qt would be throughly turned off by now, and I can't say I would blame them.

 

It's really sad it's gotten this far. I've been licensing Qt off and on since 2005 and watching it erode this whole time. I still think it's the greatest tech, but the licensing is quickly becoming the limiting factor.  So much so, that I have Qt in consideration at another company, and I am about to pull the plug because the licensing has changed so much.

 

At some point the business people have to realize that they are selling to engineers, and this is a much more nuanced field, and this license erosion is noticed.

 

Yeah, we noticed when QtPdf license changed:

https://www.qt.io/blog/2017/01/30/new-qtpdf-qtlabs-module (LGPLv3)

https://www.qt.io/blog/change-in-open-source-licensing-of-qt-wayland-compositor-qt-application-manager-and-qt-pdf (Tukka's own post)

https://lists.qt-project.org/pipermail/development/2019-October/037698.html (Not everyone was on board with the license change)

But it's now under the marketplace license?

https://marketplace.qt.io/collections/most-popular/products/qtpdf ($49/ Marketplace license)


 

 

Shenannigans. I declare shenannigans. 

 

Sent: Saturday, March 27, 2021 at 4:23 AM
From: "Tuukka Turunen" 
To: "Roland Hughes" , "interest@qt-project.org" , "mike.jack...@bluequartz.net" 
Subject: Re: [Interest] the path forward - that 7 year thing - was, , willy-nilly



 


“When Qt chased these markets it knew what the lifetimes would be. Now it has abandoned them.”

 

I would like to point out that this is not a true statement. We do offer long term support and also extended support for those customers who need it. There are some who every now and then still need something related to Qt 3. Somewhere Qt 2 is still in use. Perhaps Qt 1 even, but personally not certain about that. Qt 4 based systems of course and majority of customers are with Qt 5 currently. 

 

Each of these versions has changed API and we have tried our best to make the transition from Qt 5 to Qt 6 smooth. We are happy to get suggestions and feedback to it still and help in the transition. 


 

Yours,

 

Tuukka

 





Lähettäjä: Interest  käyttäjän Roland Hughes  puolesta
Lähetetty: Friday, March 26, 2021 10:47:34 PM
Vastaanottaja: interest@qt-project.org ; mike.jack...@bluequartz.net 
Aihe: Re: [Interest] the path forward - that 7 year thing - was, , willy-nilly

 




On 3/26/21 1:39 PM, Michael Jackson wrote:
>  I'll start off by acknowledging your points, but we will just agree to disagree. I acknowledge that you have a*lot*  of years making/maintaining software for medical devices. But I'm with Hamish on this. I don't understand.
>
> What you are saying is that Qt was designed "perfectly" from day one with no extra API, not one bad API implementation and no cruft. Qt should never be updated to run on modern compilers against modern C++ specifications. Updated to run on modern operating systems. Qt should not explore adding APIs/Toolkits to the Qt ecosystem to allow Qt to be used on the billions of devices that we use every day. Qt should just stick with its technology from 20 years ago. TQtC shouldn't go after paying customers in order to, you know, pay its developers. TQtC should rely solely on an industry that, by your own writings, have a 15 year horizon. Not much of a business case for that. (For the record, I don't particularly agree with TQtC current licensing or LTS strategy.)

No. Not what I'm saying at all. I have no idea how you got there from
what I've said.

Stable API.  Nothing ever gets deleted until it has a direct or mostly
replacement *within* the existing product.

When Qt chased these markets it knew what the lifetimes would be. Now it
has abandoned them.

> I also don't understand your argument that you want to update a medical device from 20 years ago with the latest and greatest toolkits. I can't imagine anything electronic from 20 years ago being able to actually load and run anything like Qt? How is the hardware even powerful enough to do this? You can't convince me that the medical hardware device manufacturers were thinking 15 years into the future for the next upgrade, 15 years ago.
The surgical robots being sold today will require 20 year support
lifespans. Many of the devices sold over the past decade were sold with
a minimum 10 year support and maintenance 

Re: [Interest] the path forward - that 7 year thing - was, willy-nilly

[Jason H]

> On 3/26/21 1:39 PM, Jason H wrote:
> > Thiago, apparently, even with a commercial license, we no longer have rights
> > to use whatever versions were current when we had the license. Previously, 
> > we could use
> > it in perpetuity. This is probably a deal breaker at my new organization. 
> > It is my
> > understanding that after our software development is done, we have to 
> > maintain
> > commercial licenses even when we are not_developing_  software in Qt. I 
> > think the previous
> > perpetuity licensing was appropriate.
>
> **Seriously**
>
> They are trying to end a 5.x perpetuity license that was already bought
> and paid for? Nah. Can't be. I know a customer that paid north of $600K
> for such a license and the device isn't yet out the door. They happen to
> have a lot of lawyers too. I can't believe they would take that lying down.


They can't just change your contract/license.

> What I "thought" was said was you could no longer obtain such a license.
> I don't agree with that, but that policy doesn't place QtC in legal
> jepordy because the license change only impacts new product.

This is correct, there is no more perpetuity license. This will likely
be a sticking point for the company I am currently at.

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

Re: [Interest] the path forward - that 7 year thing - was willy-nilly

[Jason H]

> Sent: Thursday, March 25, 2021 at 9:41 PM
> From: "Thiago Macieira" 
> To: interest@qt-project.org
> Subject: Re: [Interest] the path forward - that 7 year thing - was willy-nilly
>
> On Thursday, 25 March 2021 12:38:56 PDT Roland Hughes wrote:
> > > Qt's horizon is about 7 years.
> >
> > That's 8 years too short.
>
> For this industry, sure. But it's not Qt's promise. The fact that some
> industries require a higher standard of support or coding practices or
> stability does not immediately mean that it must be done in all software.
>
> It doesn't make economical sense for Qt to provide support for 15 years. If
> you need Qt for that long, you should engage a consultancy that will sell you
> that contract, the same way that Red Hat sells support for RHEL 6 for 14 years
> total (2010-2024).


Thiago, apparently, even with a commercial license, we no longer have rights
to use whatever versions were current when we had the license. Previously, we 
could use
it in perpetuity. This is probably a deal breaker at my new organization. It is 
my
understanding that after our software development is done, we have to maintain
commercial licenses even when we are not _developing_ software in Qt. I think 
the previous
perpetuity licensing was appropriate.





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

Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

[Jason H]

> >
> >> * I've got a square peg (a QList) and a round hole (an function I made
> >> that takes a QSet), so I need conversions to call it.
> > And what, exactly, is the solution here? Probably "ranges", but those
> > aren't available yet.
>
> Not an easy answer, but maybe start not to have functions take/return
> specific containers.

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

Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

[Jason H]

>
> Probably. There's only so much space for the message in them. I'm trying
> to point out that the specific motivation here isn't even remotely
> _technical_ (e.g. is this hard to implement correctly; as you've shown,
> it's super easy), but a _design_ one (is this API *good*?).
>
> And anyways these methods are still fully supported within Qt 5.

I want to "code less, create more". And manually writing these over and over
for every project I use Qt in is not coding less. They should be part of
the library.

> This is calling for a more generic toX() API. Which isn't easy to
> provide within the quality constraints of QtCore. If it were, don't you
> think Yours Truly would already have provided it? Do I sound *that* evil
> that I enjoy crippling for the sake of it? :-(

I'd rather an ANPI where you have to call toX() a minimal number of times.
See below.

> Miscellanea examples from Qt itself,
>
> * I need to remove duplicates from my list, let me do:
>
> > list = list.toSet().toList();

This should just be toSet() and generic iteration after that. No need
to convert it to a list if you can iterate over QSets the same as QLists.

> * I need to keep the list, process it in order, but avoid processing
> duplicate elements; 99% of the time the list is a handful of elements;
> let me do
>
> > QSet s; for (elem : list) { if (!s.contains(elem)) { s.insert(elem); 
> > process(elem); } }
> * I've got a square peg (a QList) and a round hole (an function I made
> that takes a QSet), so I need conversions to call it.

The elephant in the room is that Qt5 QList an QVector can have majorly different
impacts on memory. A QList is more tolerant of memory fragmentation
than QVector as you need o reallocate a contiguous chunk of
memory successfully. Where as Qt6 QList would allow LargeClass objects to be 
scattered.
This is no longer the case in Qt6. You'll be forcing everything into contiguous 
memory.
Which also has impacts on performance for systems with virtual memory.
Please tell me I'm wrong about this?

I wanted a generic iterator.  Typdefing QList to QVector does not solve that.
But even so, how do I generically iterate over QVector/QSet?

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

Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

[Jason H]

> Sent: Wednesday, March 24, 2021 at 8:49 AM
> From: "Matthew Woehlke" 
> To: "Giuseppe D'Angelo" , interest@qt-project.org
> Subject: Re: [Interest] The willy-nilly deletion of convenience methods (was: 
> Mixing Commercial and Open...)
>
> On 24/03/2021 07.17, Giuseppe D'Angelo via Interest wrote:
> > On 22/03/2021 17:19, Thiago Macieira wrote:
> >> I thought we'd fixed that and reverted them. Or didn't we add
> >> toContainer?
> >>
> >> Peppe, what was our final conclusion here?
> >
> > There was no conclusion reached, unfortunately, and didn't manage to
> > provide a replacement in time. I was (and still am) afraid at simply
> > reintroducing .to() functions.
> >
> > One reason is purely API quality: implementing them "correctly" in
> > C++14/17 without ranges/concepts is not exactly funny (just look at the
> > ranges::to proposal for how many corner cases are there to consider),
> > and there's indeed already ranges-v3::to as the ready-made solution (so
> > why spending time redoing it).
>
> Huh?
>
> Let's take e.g. QList::toSet as an example. The deprecation message says
> to use `QSet(list.begin(), list.end())` instead. How, then, is the
> correct implementation *not*:
>
>QSet QList::toSet() { return QSet{begin(), end()}; }

+1024

I also think that this is also made a problem because of lack of a general
collection interface. QVector, QList, QSet, I don't want to care what is passed
into my function. I just want to take multiple of some thing. Let my API user
determine what the best storage mechanism is.

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

Re: [Interest] The willy-nilly deletion of convenience, methods

[Jason H]

> Now, the "commercial license" simply could be the Boot2Qt stuff with all
> of Qt being 100% OpenSource. This would provide additional incentive to
> rip QML out so it isn't bastardizing the rest of the product and QML
> could then be its own commercial thing, just for phones. I have lost
> track of other little things that Digia might have spun up for
> additional cash.

QML is a binding environment, and a handy one at that. It is not just GUI.
I have Websocket servers that interact with non-visual classes with bindings
provided in QML. It's great. Yeah the QtQuick controls 1 were terrible and 2
are pretty bad, but I think things are getting better.


> > I'm not actually convinced that paying Qt customers aren't getting the
> > support they paid for; that information is generally not going to be
> > publicly available.
>
> Pull down a couple years worth of the interest archives and unzip them
> into a directory. Let grep search for bug or customer.

As a multiple-time commercial customer the bug/issue support has been great,
but the meta-narrative (previously Mobile in nature) was very lacking.
Lars/Digia is going to to do what they want, and Open Governance is a joke.

> https://lists.qt-project.org/pipermail/interest/
>
> The complete information will never be publicly available but many
> paying customers have come here to bitch about bugs open for over a year.

Not just a year, try 3. I usually was able to come up with a work-around
so that I was not blocked for 3 years though. The more critical stuff did
get fixed timely.

> > What *is* broken is the alimony licensing model and all the
> > fear-mongering around the licensing terms.
> +12
> > *Proper* commercial support for open source products lets you try
> > before you buy with no punishment afterward, no penalties if you want
> > to drop support later, or drop it and pick it up again. You pay, you
> > get support, *period*.
> +24
> >
> > For that matter, it seems like Qt's commercial model is working just
> > fine *for them*, at least at the moment. Ironically, the arguments you
> > are making probably are *why* it's working. The problem is that
> > they're busy killing the community and doing severe, possibly
> > irreparable damage to Qt's reputation.
> It is irreparable at this point. Whatever Qt becomes, it cannot have any
> current or former Digia people involved. Deep pocket customers won't
> come back. The Digia crew is 0 for 2.

It's reparable. Such things can be fixed with a stroke of a pen, like
when Nokia LGPLd it. It's just that Digia/QtCo/Weyland-Yutani corp is
running Qt as an open source project into the ground. They (IMO) don't see
opensource as a way cultivate an ecosystem that pumps the sales pipeline.
And they won't question it until the big customers dry up, look to the
community and realize they turned everyone off from it and they already
went to HTML5, where HTML/JS people are cheap and plentiful. Meanwhile
their C++ tooklit gets them a steady decline:
https://www.tiobe.com/tiobe-index/cplusplus/ that peaked 20 years ago.

I liked QML as a way to get those JS devs into Qt. They are familiar
with JS bindings, be them React, Angular, Knockout, Vue, etc.
PySide seems to be well-informed because that's the only language
(Python) that is steadily increasing.

They do seem to know HTML5 is a threat (they have whitepapers on it)
but have yet to really take it on meaningfully.

> >> It's highly doubtful that any company could pull in the staff to
> >> maintain all of the markets and eliminate all of the bugs, but that
> >> would have to be the starting point for such a venture.
> >
> > Right, which is why we *need* a community, or a consortium, or
> > something of that nature. We need everyone that cares about what Qt
> > *could* be, without Digia's efforts to break it, to pool their resources.
> >
> > I believe that if we could pull that off, Qt can still have a bright
> > future.
>
> We can't.
>
> The thing has to fork and split.

I really hate fragmentation. I'd rather convince Digia that their
licensing decisions are ultimately hurting the community and sales.

> I like Jason. He's a nice guy, but he wants to use Qt on phones and to
> have QML. He's not alone. That's how this got so busted in the first
> place. That write-once-run-anywhere myth surrounding Java back in the day.

As someone who has done it, it's not myth*
*for parts that Qt supports, but not nearly enough is supported on mobile.

> The OpenSource community was blind, deaf, and dumb when they railed
> against Tivo locking down their devices and came up with all of these
> poisoned pills in OpenSource licenses mandating users be able to modify
> the software.
>
> In medical devices, that's illegal.
>
> In industrial control systems where SAFETY is mandated, that's illegal.

Not exactly. To use it comply with the license and you would have to
provide configuration management and source to generate the same binary.
However it would be a huge risk on their part to 

[Interest] Missing QMap Algebra?

[Jason H]

I've been in the python world lately and python has a dict.update() 
https://python-reference.readthedocs.io/en/latest/docs/dict/update.html
It seems that QMap has no such function anymore, but it also never did? unite() 
would make a QMultiMap, so there would be multiple entries rather than one. 
Which has me asking the question, do I have to provide this myself? Seems a 
pretty trivial thing to have to provide?

QVariantMap map_a, map_b;
...
auto combined_map = map_a;
for (const QString& key: map_b.keys()) {
combined_map[key] = map_b[key];
}

Additionally there is no + operator for it, which is actually what I want:

combined_map = map_a + map_b;

But I would be happy with:

   combined_map.update(map_b);


Additionally if we're trying to provide as much algebra as possible:

map_a = combined_map - map_b.keys() // remove by matching key
map_a = combined_map - map_b;   // remove by matching key-value pairs

In Python, these are doable in a 1-line list/dict comprehension.

Thoughts?

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

Re: [Interest] Qt Creator is so buggy and so slow...

[Jason H]

I have never had this experience.

> Sent: Tuesday, March 23, 2021 at 8:12 AM
> From: "Alexander Dyagilev" 
> To: interest@qt-project.org
> Subject: Re: [Interest] Qt Creator is so buggy and so slow...
>
> When I press F2 it takes 5 seconds for it to go to symbol definition...
> Constantly using 100% of CPU. Such a low quality code...
>
> On 3/18/2021 8:38 PM, Alexander Dyagilev wrote:
> > Hello,
> >
> > Often it just stops to suggest code, syntax highlighted stops working
> > (at least for a part of the code) for no apparent reason.
> >
> > It takes apporx. 10 seconds to parse c++ file for c++ tools to start
> > working. If you open/close/open same c++ it can stop parsing it until
> > app restart.
> >
> > App restart often helps to fix these bugs, but they do return in a
> > small amount of time...
> >
> > Any suggestions?
> >
> ___
> 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] The willy-nilly deletion of convenience methods

[Jason H]

Surprisingly, I had a good experience with Wt, (webtoolkit.eu) the "web version 
of Qt" (uses boost). Maybe chromium plus Wt is the way to go? It's commercial, 
but not as bad as Qt licensing. (GPL2 or commercial)

If you don't constantly fracture the code base of humanity every couple years 
with some new toolkit how would the companies make any money? We're basically 
only ever putting rectangles and text on the screen. Yet we've had win32API, 
MFC,  WPF, Java, spring,  cocoa, windows forms, html, I've lost count. Qt 
seemed to be the stand out, but invented QtQuick.

One thing I muse about is geriatric computing, and got old people start 
relevant in a constantly changing UI landscape. Never I did think about the 
programmers churning away and needlessly updating style sheets, to make the 
retirement community less comfortable with using websites and apps.

Anyway I feel like things have gotten kind of off topic. Qt needs to go back to 
LGPL, or risk getting abandoned/replaced. Seems like some of the long time 
users here on this list have come to a similar conclusion. Oh and better 
support on mobile. Good luck with that. Hahahaha. Too interested in tweaking 
QHash performance in a GUI library than your use case using a mobile feature 
that's been around for 5 years but still isn't implemented in Qt.

Also, after reviewing the Qt company management, it's just Digia management, 
which might explain a lot.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] FW: The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)

[Jason H]

> Sent: Monday, March 22, 2021 at 6:54 PM
> From: eric.fedosej...@gmail.com
> To: interest@qt-project.org
> Subject: [Interest] FW:  The willy-nilly deletion of convenience, methods 
> (was: Mixing Commercial and Open...)
>
> Thank you for your informative reply Roland. I am curious whether any 
> companies that you know of have considered switching to a cross-platform 
> windowing library like SDL plus a lean immediate mode GUI (e.g. Dear ImGUI, 
> Nuklear, Nanogui, or whatever else is current)? I really like the idea of 
> doing this, since it eliminates all external dependencies, doesn't require 
> any non-permissive licenses, and should work mostly unchanged until the end 
> of time, as long as native GPU contexts are available.
> 
> I dabble in open-source desktop bioinformatics software. I'm currently using 
> Qt5.15, but I can't see myself ever moving to Qt6 given the license situation 
> and loss of Qt3D binaries. It was bad enough in Qt5 with the moribund desktop 
> widgets and half-finished Qt3D. No interest in adopting a vendor-locked 
> scripting language like QML, and I don’t want to use anything bloated or 
> mobile-centric.
> 
> I guess I'll have to switch to something else over the next year or two once 
> Qt5.15 starts to break with the loss of non-commercial LTS. I am trying to 
> decide between switching to CopperSpice or SDL + ImGUI. The latter would be 
> handy, since I can take a gradual approach, slowly moving functionality over 
> to embedded SDL + ImGUI widgets in my existing Qt GUI until no more Qt is 
> left. My main concern with doing so is that it will be a PITA to rebuild a 
> large GUI with an immediate mode approach. I'll basically be building my own 
> crappy retained-mode containers around ImGUI. It's too bad that there is no 
> existing project that I'm aware of to create standard retained-mode wrappers 
> around ImGUI etc.

I'm not so worried about QML being vendor specific. It should only be a binding 
language.  

At my new place, our product is on LVGL, a MIT licensed library. It's C, but 
there are C++ and Python bindings as well. It is every bit as verbose as you 
imagine C code would be, :-( but it runs on anything down to PIC/Arduino. 

It's amazing all the competition Qt is _enabling_ rather than capturing... And 
it's all because of license issues.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)

[Jason H]

> Sent: Monday, March 22, 2021 at 5:18 PM
> From: "Roland Hughes" 
> To: "Jean-Michaël Celerier" , "Jason H" 
> 
> Cc: "interest" 
> Subject: Re: [Interest] The willy-nilly deletion of convenience, methods 
> (was: Mixing Commercial and Open...)
>
> 
> On 3/22/21 10:39 AM, Jean-Michaël Celerier wrote:
> > > A debian package would go along way to introduce people to Qt there 
> > in the hobbyist sector, but it's a compile-it-for-yourself situation
> >
> > ?? 
> > http://archive.raspbian.org/raspbian/pool/main/q/qtbase-opensource-src/ 
> > <http://archive.raspbian.org/raspbian/pool/main/q/qtbase-opensource-src/>
> >
> > kind regards,
> > jm
> >
> >
> I __believe__ what Jason was talking about was a package for cross 
> compilation so that 12 year old kids could plug in a serial/usb cable 
> and assign a target for deploy. So people didn't have to endure stuff 
> like this:
> 
> https://www.logikalsolutions.com/wordpress/information-technology/how-far-weve-come-pt-18/
> 
> and this
> 
> https://www.logikalsolutions.com/wordpress/raspberry-pi/raspberry-qt-part-8/

Pretty much.. or a 40 year old kid.  I searched all over and found one guy 
publishing builds on GitHub.. That's what I use.  Also, linuxdeployqt isn't 
official Qt, so I just always installed QtCreator (also packaged) and re built 
when moving an app to a new pi...
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)

[Jason H]

>
> Even Jason's company, you remember Jason right? QML's biggest, and
> possibly __only__, fan. Even his company dumped Qt. The medical device
> clients I've worked for have also dumped Qt.
>
> It isn't the FUD that is obsolete, just the management of Qt.

I'm apparently Qt's biggest fan boy? Yes, I still think Qt (and yes, QML) is 
rockstar technology. My problems aren't with the API. It's that QtCorp has 
chipped away at the LGPL license from Nokia. And the stuff I wanted Qt to do, 
it didn't, even when under a commercial license.

Qt completely delivered is promise in us getting something to market, but when 
it was finally feature complete,  that something had more native code in it 
than Qt, because we were using using Qt just for the UI. Taking that and 
writing a UI abstraction to native was not that hard.

Qt *could have* made that port away so much harder, but because it's mobile 
support was so lacking, it was actually quite easy once we put our heads in it.

I'm also at a new company and I've suggested Qt up for evaluation, to replace 
the patchwork of libraries they are currently using.  We will see how the talks 
go... I doubt we will be using Qt6, regardless. Roland, what did those 
companies move to?

The problems I want fixed aren't technical. It's with the project's direction 
and management. "Open Governance" has not manifest the way I thought it would. 
Filling bugs and voting for them got my issues neglected. The constant 
relicensing to, of what was LGPL, to be under GPL 3. But these are issues that 
can be fixed with the stroke of a pen, or banging on a keyboard for a bit.

Some other inexplicable decisions are why there isn't Qt for Raspberry Pi as a 
supported platform? A debian package would go along way to introduce people to 
Qt there in the hobbyist sector, but it's a compile-it-for-yourself situation. 
Qt continues to get beat by HTML5, but it shouldn't. Especially giving the 
WebGL plugin. But there just isn't that effort to enable that segment. There is 
no grass roots support for Qt as a result. And with the licensing issues of 
late, they've ensured that there won't be. This means that they have to rely on 
and cater to the big spenders boys in the market.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

[Jason H]

>
> > Licensing FUD + death-of-perpetual-license + death-of-OpenSource-LTS +
> > Qt-6-rolling-out-incomplete + deleted-convenience-methods =
> > customers-leaving
>
> I wonder if the loss of confidence in the current Qt owners can ever be 
> compensated.
>
> Even if TQC took back their critical decisions, I can't imagine that people 
> would ever
> trust them again. This could cause fatal damage to Qt in the long run if they 
> don't sell
> it to someone more responsible.

Is there anything we can do to maybe block the release of new Qt versions, so 
that the BSD poison pill clause is triggered? Then we can start over from a BSD 
license, and maybe get other custodians of the code base?

Qt is currently catering to automotive companies, and those sales allow them to 
neglect other markets. I hope they circle back and get there market segments 
they have been neglecting.

My company abandoned commercial use of Qt as we were in a neglected market 
segment... Rewrote the app native on each platform. It was painful, but 
stuffiness routing the band-aid off quickly is the way to go.  I've been 
lurking hoping to hear good things about QT6 but it looks like The decision to 
go native was the right one.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

[Jason H]

> Sent: Friday, March 19, 2021 at 4:07 PM
> From: "Roland Hughes" 

> Licensing FUD + death-of-perpetual-license + death-of-OpenSource-LTS +
> Qt-6-rolling-out-incomplete + deleted-convenience-methods =
> customers-leaving
>

I find myself agreeing with Roland here. The rollout of the core modules if KDE 
without the rest was a disaster and I was shocked, disappointed, and perplexed 
as to why anyone would do it.  So there is Qt6? No one I know is targeting it. 
Way to make all that work irrelevant, or at least less relevant than a Qt 5.16 
release would have been. (Binary/API promises aside)

I'm really dismayed and confused as anyone would repeat the rollout of KDE. 
Xfce and GNOME are crushing KDE, and I attribute that to the way they rolled it 
out. In this day to not have multimedia a part of that... Just wow... The older 
and stable modules I could understand, QtSQL? Sure. But it creates an idea of 
"it's not ready yet" so no one targets it.  I anticipate that 5.15 will require 
a doubly long LTS period as a result.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Creator is so buggy and so slow...

[Jason H]

...
>
> On Thursday, 18 March 2021 10:38:41 PDT Alexander Dyagilev wrote:
> > Hello,
> >
> > Often it just stops to suggest code, syntax highlighted stops w.
>
> I cannot reproduce your problem of open/close/open.

Same problem here. The problem is real. I'm on a 2019 macbook pro.
The key is to just close the file and reopen it, it doesn't take restarting the 
entire IDE. It happens on small files, < 1000 lines of code, not that 
complicated. It's my most frequent problem.

The other anything problem is when the QtCreator pane insists on showsing 
issues for an old version if the file, even though it's been fixed and compiled 
successfully. This one is more rare though.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Rebuilding cmake project (in Qt Creator) fails - build directories write-protected?

[Jason H]

I don't have any specific knowlege, but if it were me, I would check Sysinternals diskmon and see where/whow/who is setting the read-only flag. (Asuming I checked and the flad is actually set)

 

Also likely - there is a process in that directory that is preventing deletion and windows is not reporting it accurately. I've not used windows in a while but I remember it being picky about such things.

 

 

 
 

Sent: Wednesday, December 30, 2020 at 6:33 AM
From: "Till Oliver Knoll" 
To: "Qt Project" 
Subject: [Interest] Rebuilding cmake project (in Qt Creator) fails - build directories write-protected?


Dear all,

It's been a while since I asked my last question here - or posted anything meaningful, for that matter - so first of all "Hello!" and "Merry Christmas / Holidays" :)

I have started a new Qt 5.15.2 (open source) project on Windows 10 (due to a dependency on Flight Simulator 2020, specifically SimConnect.dll ;)), and since Qt 6 will default to cmake (as I understand) I also chose cmake in the Qt Creator 4.14.0.

The problem: "rebuilding" (QtCreator: "Build/Rebuild All Projects") the project fails when trying to generate the translation *.ts files respectively the correspoding "list" (?) file:


FAILED: C:/dev/Qt/MainWindow/MainWindow_de_DE.ts CMakeFiles/MainWindow_de_DE.ts_lst_file
cmd.exe /C "cd /D C:\dev\Qt\build-MainWindow-Desktop_Qt_5_15_2_MinGW_64_bit-Debug && C:\Qt\5.15.2\mingw81_64\bin\lupdate.exe @C:/dev/Qt/build-MainWindow-Desktop_Qt_5_15_2_MinGW_64_bit-Debug/CMakeFiles/MainWindow_de_DE.ts_lst_file -ts C:/dev/Qt/MainWindow/MainWindow_de_DE.ts"
lupdate error: List file 'C:/dev/Qt/build-MainWindow-Desktop_Qt_5_15_2_MinGW_64_bit-Debug/CMakeFiles/MainWindow_de_DE.ts_lst_file' is not readable.
ninja: build stopped: subcommand failed.

Initially I thought that this is yet another issue with whitespace in the build path, but that's not the case (I now moved it from c:/Users/Oliver Knoll/work/... to c:/dev/Qt/work/... - that is, no spaces in path anymore).

 

However I noticed that some directories in the "build" directory (c:/dev/Qt/build-MainWindow-Desktop_...) have the "Write Protected" flag set:

.cmake
CMakeFiles
MainWindow_autogen

The Windows 10 "Properties" dialog says: "Write-Protected (only concerns files in the directory)" (or similar, in German: "Schreibgeschützt (betrifft nur Dateien im Ordner).

So when trying to manually delete those folders a dialog pops up asking me for administrator rights, and when I click on Continue (with admin rights) then another dialog tells me that I need the corresponding access rights from user "Oliver Knoll" - well, that's exactly my user (with admin rights).

However I can "cd" into the remaining directories and delete all files without problems, and after that I can delete the entire build folder at last.

Back in Qt Creator a CTRL + B (Build Project "MainWindow") then re-builds the project again.

 

Another - proper? - solution, in Qt Creator (all in "Build" menu):

* Clean Project "MainWindow"
* Clear CMake Configuration (at that point the subdirectory .cmake/api/v1/query (and reply) still remains, plus 3 "ninja" related files and cmake_install.cmake)
* Run CMake
* Rebuild Project "MainWindow"

It works, but... really? 4 steps instead of just one? Is that the proper "CMake way" (I am totally new to CMake) to rebuild a project from scratch?

The above example refers to a simple "MainWindow" project setup in Qt Creator as follows:

* New File Or Project
* Qt Widgets Application
* Name: MainWindow (any name)
* Build System: CMake
* Default classes/files, including Generate form
* Add any translation language
* Default Qt Kit: Qt 5.15.2 MinGW 64-bit
* No version control

The above experiments were done with the default generated CMakeLists.txt.

 

Development environment:

* Qt 5.15.2 Open Source
* QtCreator 4.14.0
* CMake 3.19.0 (installed via Qt Installer)
* Windows 10 2004 (all updates installed)
* Except the MS FS2020 SDK (SimConnect.dll) there are no other developer tools installed (specifically no other CMake, no Visual Studio, no other compilers etc.)
* "Default Windows Home installation" (one user - Oliver Knoll - with admin rights; yes, it's a "gaming machine" ;))


Other:

* Most likely not relevant, but: it is a "Windows To Go" installation (created/installed via tool "WinToUSB"), installed on an external SSD (which is connected to a Mac ;))

The full compilation error during a "Rebuild" (without clearing the CMake configuration):

12:02:08: Running steps for project MainWindow...
12:02:08: Starting: "C:\Qt\Tools\CMake_64\bin\cmake.exe" --build . --target clean
[1/2 54.3/sec] Cleaning additional files...
[2/2 83.6/sec] Cleaning all built files...
Cleaning... 0 files.
12:02:08: The process "C:\Qt\Tools\CMake_64\bin\cmake.exe" exited normally.
12:02:08: Starting: "C:\Qt\Tools\CMake_64\bin\cmake.exe" --build . --target all
[1/6 2.7/sec] Automatic MOC and UIC for target MainWindow
[2/6 5.1/sec] Generating 

Re: [Interest] QtPdf from Qt open source online installer

[Jason H]

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

> Sent: Tuesday, October 20, 2020 at 12:22 PM
> From: "Giuseppe D'Angelo via Interest" 
> To: interest@qt-project.org
> Subject: Re: [Interest] QtPdf from Qt open source online installer
>
> Il 20/10/20 17:28, Jason H ha scritto:
> > Then we should probably include the marketplace email address in this
> > thread.
>
> Open a bug report instead.
>
> Thanks,
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
>
> ___
> 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] QtPdf from Qt open source online installer

[Jason H]

> Sent: Tuesday, October 20, 2020 at 11:54 AM
> From: "Konstantin Tokarev" 
> To: "Benjamin TERRIER" , "Jason H" , "qt 
> qt" 
> Subject: Re: [Interest] QtPdf from Qt open source online installer
>
> 
> 
> 20.10.2020, 18:12, "Benjamin TERRIER" :
> > On Mon, 19 Oct 2020 at 20:54, Jason H  wrote:
> >> There's some license shenanegans going on.
> >> https://www.qt.io/blog/change-in-open-source-licensing-of-qt-wayland-compositor-qt-application-manager-and-qt-pdf
> >> However there was a later update:
> >> https://lists.qt-project.org/pipermail/development/2020-January/038457.html
> >>
> >> So I don't know why it was not included.
> >> It seems that some people (myself included) objected to commericalizing a 
> >> module that was based on a open source engine to start with.
> >
> > Yes, I've seen the discussions about the license, but I thought it was 
> > solved.
> >
> > Given that The Qt Company is selling the QtPdf module under a commercial 
> > license on the marketplace I was thinking that
> > they remove the QtPdf artefacts from the QtWebEngine packages. That would 
> > make sense for commercial users.
> >
> > However, for open source users it looks like a bug in the installer.
> 
> Isn't this done intentionally to promote commercial licenses among open 
> source users?

Never attribute to malice what can be attributed to human stupidity. -Hanlon's 
razor.

For me, because there was confusion over this module's license, I attribute it 
to that.  Which also would be the same result as applying Occam's razor.


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

Re: [Interest] QtPdf from Qt open source online installer

[Jason H]

 


Then we should probably include the marketplace email address in this thread.

 

 

Sent: Tuesday, October 20, 2020 at 11:09 AM
From: "Benjamin TERRIER" 
To: "Jason H" , "qt qt" 
Subject: Re: [Interest] QtPdf from Qt open source online installer



 
 


On Mon, 19 Oct 2020 at 20:54, Jason H <jh...@gmx.com> wrote:




There's some license shenanegans going on.

https://www.qt.io/blog/change-in-open-source-licensing-of-qt-wayland-compositor-qt-application-manager-and-qt-pdf

However there was a later update:

https://lists.qt-project.org/pipermail/development/2020-January/038457.html

 

So I don't know why it was not included. 

It seems that some people (myself included) objected to commericalizing a module that was based on a open source engine to start with. 
 





 

Yes, I've seen the discussions about the license, but I thought it was solved.

Given that The Qt Company is selling the QtPdf module under a commercial license on the marketplace I was thinking that

they remove the QtPdf artefacts from the QtWebEngine packages. That would make sense for commercial users.

 

However, for open source users it looks like a bug in the installer.






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

Re: [Interest] QtPdf from Qt open source online installer

[Jason H]

There's some license shenanegans going on.

https://www.qt.io/blog/change-in-open-source-licensing-of-qt-wayland-compositor-qt-application-manager-and-qt-pdf

However there was a later update:

https://lists.qt-project.org/pipermail/development/2020-January/038457.html

 

So I don't know why it was not included. 

It seems that some people (myself included) objected to commericalizing a module that was based on a open source engine to start with. 
 

Sent: Saturday, October 10, 2020 at 7:28 PM
From: "Philip Schuchardt" 
To: "Benjamin TERRIER" 
Cc: "qt qt" 
Subject: Re: [Interest] QtPdf from Qt open source online installer


Oops missed typed the link, cavewhere.com
 


On Sat, Oct 10, 2020 at 7:27 PM Philip Schuchardt  wrote:


I used QtPdf for mac and windows for my open source project (cavehere.com). 

 

I have to build QtPdf from source and install it for each platform and Qt version. Although it's not too bad, it isn't as automatic as all the other Qt modules. It would be great if it was supported directly.

 

 


On Sat, Oct 10, 2020 at 5:04 PM Benjamin TERRIER  wrote:



Hi,
 

I've noticed that QtPdf is missing when using open source Qt with the online installer.

I was wondering what's the reason  for this?

 

As QtPDF is sold under a commercial license on the Qt marketplace I understand it cannot be distributed as part of Qt WebEngine for commercial users.

But for open source users?

 

Also it seems that QtPDF was indeed built when the release packages were build, but got partially removed. For instance on Windows the DLLs are still there, and on Linux the debug symbols are still there.


 

That means that open source users have to build Qt PDF themselves, it is a bit cumbersome.
 

Regards,

 

Benjamin

 


___
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] iOS 14 little green dot

[Jason H]

The problem is the camera stack takes some time to load and even longer to adjust exposure, white balance, etc,  for the best user experience, we load it, but don't start acquiring media immediately. We find that when we do it this way, the white balance and exposure is already settled, and the transition in the UI is smooth.

 

You are technically correct though, if the problem was just the dot, Unloaded would be fine. I'm just trying to have my cake and eat it too.


 

Sent: Thursday, October 08, 2020 at 11:20 AM
From: "Pierre-Yves Siret" 
To: "Jason H" 
Cc: "interestqt-project.org" 
Subject: Re: [Interest] iOS 14 little green dot


The indicator is meant to tell if an app is using the camera, it appears you are in fact using it ("In our app, we start the Qt camera stack") so the green dot showing is normal.
Can't you delay the Camera instantiation until you actually need it? If you can't, have you tried setting the cameraState to Camera.UnloadedState? 
 


Le jeu. 8 oct. 2020 à 15:19, Jason H <jh...@gmx.com> a écrit :

I filed https://bugreports.qt.io/browse/QTBUG-87296
but I'm wondering what other people's experiences are?

iOS 14 displays a dot when "recording" though this seems to be activated when the camera stack is loaded with Qt, and not when we are actually capturing multimedia.
___
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] iOS 14 little green dot

[Jason H]

I filed https://bugreports.qt.io/browse/QTBUG-87296
but I'm wondering what other people's experiences are?

iOS 14 displays a dot when "recording" though this seems to be activated when 
the camera stack is loaded with Qt, and not when we are actually capturing 
multimedia.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Help with maintenance tool

[Jason H]

> Sent: Tuesday, September 22, 2020 at 12:46 PM
> From: "Tino Pyssysalo" 
> To: "Jason H" , "giuseppe.dang...@kdab.com" 
> 
> Cc: "interest@qt-project.org" 
> Subject: Re: [Interest] Help with maintenance tool
>
> On 22.9.2020, 16.19, "Interest on behalf of Jason H" 
>  wrote:
>
> > Thanks, I'll give that a shot.
> >
> > I think the bigger problem is that if you're used an email for 
> evaluation there is no way to select the Open Source version, it just forces 
> you into a commercial or no license scenario. There seeds to be a license
> > selection screen with lawyer appoved verbiage tot he effect of "I chose 
> o use Qt in accordance with the various OpenSource Licenses including GPL2-3, 
> LGL 2-3. In addiytion the following modules are not available
> > under any open source license:
> > 1 ??
> > 2. ???
> >...
> > "
> >
> >  I can't e the only person who has previously evaluated before this 
> whole sign-up process was made mandatory?
>
> This is fully intentional. We have business requirements, which have resulted 
> to sub-optimal user experience.
>
> Commercial license agreement denies mixing open-source Qt with commercial Qt. 
> In installation, this is handled in such a trivial way
> that Maintenance Tool does not allow changing the login credentials from the 
> ones, which were used in the installation - were
> they used for evaluation, open-source or commercial usage.
>
> The simple work-around is to re-run Online Installer login page. The 
> installer can be closed after the login with open-source credentials
> and no actual re-installation is required.

I was able to fix the problem by re-running the installer with the credentials. 
I also then removed the existing Qt and got the latest which should have made 
the install fully opensoourced.
Thanks for the hint!

> NOTE however that after this the commercial installation has been converted 
> to an open-source installation and all open-source
> obligations apply. The better way would be to have two separate open-source 
> and commercial installations in the first place.
> The only use case where this conversion makes sense, if you want to continue 
> with open-source Qt after evaluation.

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

Re: [Interest] Help with maintenance tool

[Jason H]

Thanks, I'll give that a shot.

I think the bigger problem is that if you're used an email for evaluation there 
is no way to select the Open Source version, it just forces you into a 
commercial or no license scenario. There seeds to be a license selection screen 
with lawyer appoved verbiage tot he effect of "I chose o use Qt in accordance 
with the various OpenSource Licenses including GPL2-3, LGL 2-3. In addiytion 
the following modules are not available under any open source license:
1 ??
2. ???
...
"

I can't e the only person who has previously evaluated before this whole 
sign-up process was made mandatory?


> Sent: Monday, September 21, 2020 at 12:17 PM
> From: "Giuseppe D'Angelo via Interest" 
> To: interest@qt-project.org
> Subject: Re: [Interest] Help with maintenance tool
>
> Il 21/09/20 17:19, Jason H ha scritto:
> > How do I use the open source version?
> >
> > "No valid license available in your Qt Account for this host platform.
> > Please renew your license(s) from Qt Account."
> >
> > How am I supposed to elect the open source version when there is no option 
> > at account.qt.io
> > Can someone fix this for me?
>
> I literally fixed this by going back and forth in quick succession
> inside the tool while clicking around (basically doing a "monkey test")
> until it goes past that screen and you get to select if to add/remove or
> uninstall.
>
> HTH,
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
>
> ___
> 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] Help with maintenance tool

[Jason H]

ARG. I am stuck in maintenance tool hell.

How do I use the open source version?

"No valid license available in your Qt Account for this host platform.
Please renew your license(s) from Qt Account."

How am I supposed to elect the open source version when there is no option at 
account.qt.io
Can someone fix this for me?


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

Re: [Interest] wss:// on localhost

[Jason H]

> 4) It's also a shame how the Internet has become - I still have a mindset of 
> the year 2000 where the web was not really a significant resource of criminal 
> intent. I understand this can lead to misunderstanding ;-)

If you open up port 80 or 443 on a AWS-hosted instance with a public IP, within 
minutes you'll get scanned by bots looking for unsecured servers. - That's just 
the script kiddies.
Then you have to worry about those adversarial nation states (or those working 
on their behalf), who probably don't even care who you are, or what you are 
doing, but just want to know discover potentially actionable intel.
You can no longer hide as a random entry in 4 billion addresses. It was never 
smart, but now you have to assume the attacker is at your front door trying to 
look in within seconds of mashing the "create instance" button.


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

Re: [Interest] wss:// on localhost

[Jason H]

IANAL, and this dives into legal issues, but if the creature function took a 
path to a binary, and some options (assuming openssl options?) and allow the 
developer/user to specify the binary, I think the legal issues would be 
avoided. If the user wanted to use some other mechanism, they would just 
provide a script as the binary and map the openssl options to the custom binary.

Just my 0.02.


> Sent: Wednesday, July 29, 2020 at 5:08 PM
> From: "Thiago Macieira" 
> To: interest@qt-project.org
> Subject: Re: [Interest] wss:// on localhost
>
> On Wednesday, 29 July 2020 07:46:36 PDT Jason H wrote:
> > Kinda sounds like there should be a QSslCertificate::create() method?
>
> Yes, but we may not be able to have that in Qt without running into export
> controls. Qt cryptographic code is only approved for sockets.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel DPG Cloud Engineering
>
>
>
> ___
> 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] wss:// on localhost

[Jason H]

Kinda sounds like there should be a QSslCertificate::create() method?


> Sent: Tuesday, July 28, 2020 at 4:18 AM
> From: "Alexander Carôt" 
> To: "Alexander Carôt" 
> Cc: "Thiago Macieira" , "Paul Pfützenreuter" 
> , "interest@qt-project.org" 
> 
> Subject: Re: [Interest] wss:// on localhost
>
> > but for now the localhost wss failed again. If you have another hint please 
> > let me know - I won't give up ;-)
> 
> Eventually I succeeded with this tool:
> 
> https://github.com/FiloSottile/mkcert
> 
> After certificate generation and installation I was able connecting to 
> localhost - very good !
> 
> Now I need to figure how to automize this process on any client's machine.
> 
> Further inspiration appreciated - thanks for your help !
> 
> Best
> 
> Alex
> 
> 
> --
> http://www.carot.de
> Email : alexan...@carot.de
> Tel.: +49 (0)177 5719797
> 
> 
> > Gesendet: Dienstag, 28. Juli 2020 um 08:05 Uhr
> > Von: "Alexander Carôt" 
> > An: "Mårten Nordheim" 
> > Cc: "Thiago Macieira" , "Paul Pfützenreuter" 
> > , "interest@qt-project.org" 
> > 
> > Betreff: Re: [Interest] wss:// on localhost
> >
> > Hallo Marten,
> > 
> > thanks for your additionl reply !
> > 
> > There are two reasons why I have to use a secure websocket:
> > 
> > 1.) In some cases our website connects to our app not on localhost but some 
> > other place on the LAN.
> > 
> > 2.) Our site is part of a CMS-based project which per default runs with 
> > SSL. Changing the specific sites to no-SSL (http) and the corresponding ws 
> > leades to mixed content often ignored by the browser.
> > 
> > In fact in our current workaroud we redirect to http and run a non-secure 
> > ws but this fails for some browsers and especially in context with 1) it 
> > fails completely - so I believe there is no other choice than using 
> > SSL-Websockets and I am happy that theoretically there is a way to do 
> > achieve this is a user-friendly way. However, I am still struggeling. So 
> > far this tutorial looked promising:
> > 
> > https://www.freecodecamp.org/news/how-to-get-https-working-on-your-local-development-environment-in-5-minutes-7af615770eec/
> > 
> > but for now the localhost wss failed again. If you have another hint please 
> > let me know - I won't give up ;-)
> > 
> > Best
> > 
> > Alex
> > 
> > 
> > --
> > http://www.carot.de
> > Email : alexan...@carot.de
> > Tel.: +49 (0)177 5719797
> > 
> > 
> > > Gesendet: Montag, 27. Juli 2020 um 15:45 Uhr
> > > Von: "Mårten Nordheim" 
> > > An: "Alexander Carôt" , "Thiago Macieira" 
> > > 
> > > Cc: "Paul Pfützenreuter" , 
> > > "interest@qt-project.org" 
> > > Betreff: Re: [Interest] wss:// on localhost
> > >
> > > Hello Alexander,
> > > 
> > > I don't know (or recall) what your setup is like. The following answer 
> > > assumes the website you refer to also runs on the local machine:
> > > 
> > > Somewhat going in the other direction I'd say wss/https is not necessary 
> > > if your application actually only listens to localhost (127.0.0.1/[::1]).
> > > It won't travel across the network at that point, and if the local 
> > > machine is compromised encryption doesn't matter much.
> > > 
> > > If you are listening to other addresses as well though (to let other 
> > > clients in the network connect as well) then you need to generate 
> > > certificates
> > > that includes the hostname or IP of the machine running the server since 
> > > "localhost" is no longer enough/correct for that.
> > > 
> > > However if the website is remote and you run attempt to connect to a 
> > > websocket on the local machine then it needs to be encrypted and Thiago's
> > > suggestion will get you most of the way. You will also need to get the OS 
> > > to trust the certificate for the browser to accept it as well. Usually 
> > > with
> > > untrusted certificates browsers will show a warning and let you ignore 
> > > it, but that doesn't happen in most browsers when opening a websocket
> > > connection in the background!
> > > 
> > > Mårten
> > > 
> > > 
> > > From: Interest  on behalf of Alexander 
> > > Carôt 
> > > Sent: Tuesday, July 21, 2020 19:32
> > > To: Thiago Macieira
> > > Cc: Paul Pfützenreuter; interest@qt-project.org
> > > Subject: Re: [Interest] wss:// on localhost
> > > 
> > > Hej Thiago,
> > > 
> > > > Whether they work or not is irrelevant, since you shouldn't be shipping 
> > > > the
> > > > same certificate to all users. You'd have to make it extremely 
> > > > long-lived
> > > > (expiry 20 years from now). Generating a short-lived one (3 months) 
> > > > limits the
> > > > damage if it somehow gets misused.
> > > 
> > > 
> > > just to avoid misunderstandings: The goal is not sending existing 
> > > certificates as part of the application download but rather generate the 
> > > certificte automatically upon launching the app ?
> > > 
> > > 
> > > > There are lots of examples on the Internet on how to do this with the 
> > > > openssl
> > > > command. You'll have to find 

Re: [Interest] wss:// on localhost

[Jason H]

I could never get wss: working on the mobile platforms, despite being able to 
get https working. 

a) you need these for SSL to work. You could generate them and set peer verify 
to off,  but I don't know how to do it without a certificate.

b) You can't (generally speaking) do ws and wss at the same time. It follows 
http/https semantics, as it starts as HTTP and negotiates the protocol change 
to WebSocket. The encruption happens even before that - it is already assumed 
to be encrypted or not, though it is possible to have a plaintext http socket 
upgrade to a https socket (mixed mode), but no one does that. Instead the 
protocol/port combo gives the client the information on how to start talking to 
the server in the right way. I will speculate that this is done rather than 
have a mixed-mode socket so if you come in with the intent of being encrypted 
and are not, that is considered a hard fail.  Same applies for unencrypted. 
Mixed mode only gives you additional ambiguity, potential leakage of data 
intended to be secure but isn't. So there isn't a large reason to support both 
on the same socket, and ports to bind to are not in short supply.

> Sent: Sunday, July 19, 2020 at 12:50 PM
> From: "Alexander Carôt" 
> To: "qt qt" 
> Subject: [Interest] wss:// on localhost
>
> Hello all,
> 
> after having fixed my QWebsocketServer issue I ran into another problem:
> 
> Beside my properly working SSL websocket I have another websocket which 
> serves as the technical interface between my website and a Qt application 
> required for the service.
> 
> This websocket used to work insecure (ws://) and now I am as well trying to 
> run it in secure mode (ws://), however, I wonder if also in this case I need 
> an extra certificate. Furthermore, I wonder if afer deployment this implies 
> that users would also need a dedicated certificate (which would be be 
> acceptable in terms of usability).
> 
> Alternatively I could run the application websocket insecure (ws://) but it 
> semms that some web browsers dislike the mixture of ws:// and wss:// for some 
> reason although the main site is run via https:// and ws:// the downgrade 
> should not be a problem.
> 
> Can anyone tell if
> 
> a) there is way to get rid of certificates on localhost despite using wss://
> b) there is a reliable way of having ws:// and wss:// at the same time
> 
> Thanks a lot in advance,
> best
> 
> Alex
> 
> 
> --
> http://www.carot.de
> Email : alexan...@carot.de
> Tel.: +49 (0)177 5719797
> 
> ___
> 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 is this list all about anyway?

[Jason H]

> Sent: Thursday, July 16, 2020 at 6:29 AM
> From: "Sérgio Martins" 
> To: "Julien Cugnière" 
> Cc: "interestqt-project.org" 
> Subject: Re: [Interest] What is this list all about anyway?
>
> On Thu, Jul 16, 2020 at 9:05 AM Julien Cugnière
>  wrote:
> >
> > Le jeu. 16 juil. 2020 à 08:08, Nuno Santos  a 
> > écrit :
> > > I believe that this individual brings nothing but noise to this table and 
> > > should be removed from the list. How many people here think the same?
> > >
> > > If the community doesn’t want to be politically incorrect then I’ll do 
> > > myself and a favour and leave the list myself.
> >
> > You're not alone, but he has a right to his opinions, and people have
> > a right to reply to him if they want to.
> 
> He has the right to an opinion, but not to hijack every thread to talk
> about QML/CopperSpice, specially threads which weren't about QML in
> the first place.
> 
> For someone claiming to be in this industry since 40+ years it's time
> to learn a bit about netiquette and how mailing lists work.

Perhaps what we need is an [Offtopic] list?
A community united by their love/use/hatred of Qt, but not functionally 
relevant to the purpose of the interest mailing list. I regard the interest 
list as strictly about Qt, specific questions, concerns, etc. It seems that 
Roland is only tangentially talking about Qt and using the interest list more 
as a soapbox. I would suggest that content would be appropriate for [Offtopic] 
but not for [Interest]. And rather than kick Roland out, just suggest he use 
offtopic for the historical/opinionated content. 

Additionally, I don't know where, who or how anyone was entitled to decide to 
change the list to be moderated. That seems it should be a community decision. 
There was no consideration given to the proposal I just made because there was 
no discussion.

While Roland's comments are not the normal kind for this list, we don't really 
have a good description of what this list is for. The mailman page says "List 
for developers who _use_ Qt" Obviously, Roland meets that description. If we 
want to tighten down the content of this list, then it needs to be done 
_with_notice_ and community agreement. 
 





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

Re: [Interest] Interest Digest, Vol 106, Issue 14

[Jason H]

> Sent: Wednesday, July 15, 2020 at 7:51 AM
> From: "Giuseppe D'Angelo via Interest" 
> To: "Roland Hughes" , interest@qt-project.org
> Subject: Re: [Interest] Interest Digest, Vol 106, Issue 14
>
> On 15/07/2020 13:01, Roland Hughes wrote:
> > What I'm saying is Tweedle-Dee and Tweedle-Dum (I don't remember their
> > real names now, just the darting nick names; they tagged the trio I was
> > with Moe, Larry, and Curly; it's a darting thing) developers working at
> > Nokia who threw darts with me months on end every weekend Two Rivers and
> > even showed up a few times for Tuesday night dart league at Pockets
> > talked shop while we were drinking and darting and socializing. They
> > said repeatedly it was exactly what they were working on.
>
> This is the *definition* of hearsay.

If there is no git commit, you must acquit

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

[Interest] I love QML

[Jason H]

I know I spend a lot of time talking about inadequacies of Qt, but it's out of 
love. Since discovering Qt back in oh, 2001 when I was writing MFC apps, I have 
come to love the toolkit despite its rough edges. I have been assigned to port 
our Qt/QML app to Swift. And let me say what a joy it is working with Qt/QML.
- The ability to use JSON inline, and as a proper JavaScript Object is a huge 
feature that I did not appreciate previously.
- The property bindings system eliminates so much code and the automatic 
evaluation of bindings is phenomenal.
- The lack of a separated view and view controller makes reusable components 
even easier.
- The fact that I don't need to use UI machinations in a UI builder to build an 
app (I'm looking at you, @IBOutlet) is another joy
- The fact that Qt types don't seemingly duplicate each other in quirky ways 
(UIColor, CGColor)
- I could go on...

I know Qt is going to offer an alternative to JS, but unless it has all those 
features (mainly the in-line JSON in actual JSON) I am likely to stay with the 
JavaScript version.

A big big Thank You to the Qt team!


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

Re: [Interest] Qt 6.0 and the future of QWebSockets module

[Jason H]

+1 I've moved to QtWebSockets for all IP communication, and it's made everything so much easier, even easier thant he QtHttpServer, which is what I was using and is still being developed.

 

 

 

 
 

Sent: Saturday, June 27, 2020 at 4:01 PM
From: "Narolewski Jakub" 
To: "Lars Knoll" 
Cc: "interest@qt-project.org Interest" 
Subject: Re: [Interest] Qt 6.0 and the future of QWebSockets module





That's great to hear. Thank you :]

 

Jakub Narolewski


 



On Fri, 26 Jun 2020, 15:11 Lars Knoll,  wrote:




Hi,


 



The plan is to bring those modules back after Qt 6.0. This is mainly a prioritisation question right now, where the choice was to focus most development efforts on the Qt Essentials to make them as good as possible for Qt 6.



 



So I expect that we’ll have a fully supported web sockets module available for Qt 6 by the time 6.1 or latest 6.2 is being released.



 



Cheers,



Lars



 



On 26 Jun 2020, at 14:23, Narolewski Jakub  wrote:


 



Hello :]

Lurking yesterday on a dev mailing list I accidentally stumbled upon topic that mentioned this wiki site: https://wiki.qt.io/Checklist_for_Qt_6.0_inclusion
As I understand it, it is a listing of Qt modules and their their 'cmake porting progress' and I quote:

"Given the deadline for the Qt 6.0 release at the end of 2020, it is likely that not all Qt modules will be ready for the deadline set by the 6.0 release schedule."

Enter the QWebSocket module. As it currently stands QSW is in some kind of a development limbo.
On wiki: https://wiki.qt.io/Maintainers Kurt Pattyn is still listed as module's maintainer but I believe he is currently inactive in development.
On JIRA there is a task that specifies improvements for the module: https://bugreports.qt.io/browse/QTBUG-42749
But under connected ticket: https://bugreports.qt.io/browse/QTBUG-75638
There is ominous: "unify QtWebSocket with other networking classes (out of scope)"

Does this mean that QWS will be removed as an available module in Qt 6.0?
Will it be unsupported after Qt5.x releases?
If I use it currently, would it be wise to start using something different if I would like to later jump to the Qt 6.X releases?

Yours Truly 2095,
Jakub Narolewski


___
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] Qt scripting with JavaScript

[Jason H]

> Sent: Thursday, June 18, 2020 at 5:35 AM
> From: "Filippo Rusconi via Interest" 
> To: interest@qt-project.org
> Subject: [Interest] Qt scripting with JavaScript
>
> Greetings, Fellow Developers,
...
> Can I use the Qt QML module-contained QJSEngine for a classical QWidgets-based
> program ? If so, is the JS programming in this setting very different than 
> what
> I am used to with Qt Script ?
>
> Script-wise, how about using Python to make my program scriptable? Is PySide
> something that would match the requirement? Has anybody tried both Qt Script 
> and
> Python ? If so, what lessons were learnt ?

The problem with Python is the threading, as it still suffers from the GIL, but 
this can be avoided with care.

I used QtScript a long time ago, I did like it. I have used QML and I have to 
say that I love it.
I also used Riverbank's PyQt to make a scriptable widgets program by 
embedding/extending. I've only experimented with PySide and for what I was 
attempting, it did not cover all the classes I needed. This seems to be true 
quite a bit, that PySide lags PyQt.

That said, I would recommend QML first, PyQt second, and PySide third. If a 
detailed class analysis indicated that PySide covers the classes you need (and 
they work as they should), then you could skip PyQt. I do need to note that 
they are different products with different capabilities and licenses.


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

Re: [Interest] QtQuick: weird fonts problem

[Jason H]

From what I've seen, it's a combination of poor font hinting, a bad cleartype 
implementation, it some combination there of. You can change the way Qt handles 
the font hinting, by turning off antialiased text. It'll good the issue, but 
then the text won't appear smooth.


> Sent: Tuesday, June 09, 2020 at 8:51 AM
> From: "Alexander Dyagilev" 
> To: interest@qt-project.org
> Subject: [Interest] QtQuick: weird fonts problem
>
> Hello,
>
> One of our users reported that text drawing is broken. It's PNG, it
> seems image is not blurred and this is how app looks really on his PC.
>
> Why can this happen?
>
> https://i.imgur.com/GG9hXPQ.png
>
> ___
> 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] How to send an arbitrary file over sockets

[Jason H]

How do you know how Big the file is? You assume to get it all in a single 
operation. You should use qdatastream which will properly serialize the byte 
array including a length. I've recently taken to using the experimental q HTTP 
server to provide a web interface, or more recently using qwebsocket to send a 
file over a websocket.

the only reason why your codeworks right now is because you're a text file is 
small and it can all be done in one write call. You're going to get many 
readyReads. The network can break your packets apart so you cannot rely on 
everything coming on one read.


> Sent: Saturday, May 30, 2020 at 1:29 AM
> From: "Ghobad Zarrinchian" 
> To: interest@qt-project.org
> Subject: [Interest] How to send an arbitrary file over sockets
>
> Dear all,
> I'm writing a client/server application in which the client can send a file
> to the server. At the client side, my code is something like below:
>
> QFile fl(file_name);
>
> fl.open(QIODevice::ReadOnly);
>
> QByteArray fileBytes = fl.readAll();
>
> socket->write(fileBytes);
>
> fl.close();
>
> And at the server side, the code that receives the file is something like 
> this:
>
> QByteArray data = client_socket->readAll();
> QFile fl(file_name);fl.open(QIODevice::WriteOnly);fl.write(data);fl.close();
>
> While the code above works well with text files, it does not work for
> other file types (like JPG and PDF files). What is the problem? How
> should i modify the code so that it works for all kinds of files?
>
> Thanks.
> ___
> 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